Re: GWorkspace : mounting removable devices

[Patrick Cardona]

Hi Riccardo,
Hi All,

Well, finally I tried 'make install' in the Userspace domain to see if the 
patch about 'removable devices' was applied and what it did really. I also 
tried to see if the new behaviour was as expected from the OpenStep Desktop 
User Experience, according to the guide 'Using the OpenStep Desktop, Sept. 
1996, Chap. 8, Working with Disks', as I could understand it, which was mainly 
about floppy disks and CD-ROM at this time, but also 'any other removable disk' 
(as said in chap. 8.11).

The behaviours expected could be enumerated like this :
(1) Ater a new disk is inserted, it can be mounted by the user from a menu item 
from the 'Disk' menu of the Workspace  (i.e. now the menu 'Tools' in 
GWorkspace).
(2) After a disk/removable device has been mounted, it should be shown with a 
specific icon (not a folder one) on the shelf and from there, opened in a file 
view window...
(3) The user should be able then to unmount the device from the root 
filesystem, choosing an appropriate item in the 'Disk' menu again ('Tools' menu 
within GWorkspace).

(4) A variant should consist of using the 'Save Dialog' in which window two 
icons 'mount/unmount' are available to do so, not only with floppy disk, as the 
icons might suggest, but with any removable device. In this case, if many 
devices were mounted, the first button (mount) should mount those devices one 
after another, and the 'unmount' button should eject those in the same order.

So I closed GWorkspace from the System domain and launched the one I just made 
from source and installed in my User Domain...

 openapp ~/GNUstep/Applications/GWorkspace.app
2020-06-10 17:02:20.197 GWorkspace[9199:9199] styleoffsets ... guessing offsets
2020-06-10 17:02:20.217 GWorkspace[9199:9199] styleoffsets ... guessing offsets
2020-06-10 17:02:23.234 GWorkspace[9199:9199] duplicate module "Rôle" at 
/usr/lib/GNUstep/Bundles/Role.extinfo
2020-06-10 17:02:26.405 fswatcher[9266:9266] register client 2
2020-06-10 17:02:35.491 GWorkspace[9199:9199] Lost information converting 
decoded value to int32_t
(...) 
2020-06-10 17:02:36.410 ddbd[9267:9267] ddbd started

As You can see, duplicate conflict was minor, thought I don't know exactly 
about Role.extinfo and the severity of this warning.

And I began my test about removable devices.

A) First test : with a disk already registered in the list of 'mount points for 
removable media'  in the System Preferences...

(1) After inserting the USB drive, the 'Tools'/#E menu was not able to mount 
the disk on the filesystem, even if the mount point was registered in the 
System Preferences.
So I mounted this device as usual from a command line in the Terminal, i.e. 
udisksctl.

(2) After the device has been mounted, I chose from the menu 'Tools' : #E to 
verify the disks, and as expected, a disk icon (not a folder one) was shown on 
the top right of the Desktop. 
My thoughts : 
(a) I wonder why the disk icon was not shown on the shelf as the Workspace did 
within OpenStep. What is preventing GWorkspace to do it the same ?
(b) Obviously, the patch was applied, though the version number and the build 
were the same as the app I used from the system Domain (9.0.4, build at 07/2016)

(3) Unmounting
I made some stuff within that mounted drive and then tried to unmount it :
- Unlike the specs from the OpenStep Workspace, there was no item to do this in 
the 'Tools' menu, which is supposed to replace now the  'Disk' menu. So I 
considered these alternatives :

(a) Dragging the icon onto the Recycler icon... Which failed : though I used to 
do so with some CD-ROM on MacOS X, I did not found this described as a spec in 
the mentioned OpenStep guide.

2020-06-10 17:14:45.524 GWorkspace[9199:9199] eject failed

(b) Selecting the icon and then typing #d, which was successful :

2020-06-10 17:14:45.916 GWorkspace[9199:9199] removing: /media/pi/CLEPAT

B) Second test : with another disk, not yet registered in the list of 'mount 
points...' in the System Preferences

(1) Mounting
Same as the previous device : I had to mount it with a command line in the 
Terminal (udisksctl).

(2) Curiously, afer mounting this device, I could see it directly on the 
Desktop without the need to choose the 'Tools' / #E menu... So, it seemed that 
the registered mount point was not useful neither required with a new device... 
And maybe, in this case, a kind of 'auto-showing' was made.

2020-06-10 17:51:10.383 GWorkspace[9199:9199] new volume: /media/pi/TRAVAIL

(3) Unmounting
To eject this device, it was the same as the previous test...

C) Testing with a Save Dialog window (part 4 of the expected behaviour)

(1) Using the device known as CLEPAT (mount point registered in the System 
Preferences)
and after it has been inserted... but not yet mounted in a Terminal...

Pressing the button "mount" : I got this error message :
mount: /media/pi/CLEPAT: Aucun fichier ou dossier de ce type (i.e: there is not 
any file or any folder of that kind)

I noticed something interesting : that is the action of the button was the 
standard UNIX 'mount' command, not the new userspace command  'udisksctl' used 
now in the recent GNU/Linux systems. This may be a clue : because GWorkspace 
calls 'mount' (which needs root privileges), it could explain why the actions : 
#E from the 'Tools' menu and from the 'mount'  button in the Save Dialog are 
always failing to do the effective mounting.

So, what we can learn from this test from the user point of view ?
- GWorkspace seems to use the UNIX standard commands : mount / eject
and maybe this cannot be changed due to the other systems like BSD.
- How to take in account GNU/Linux systems where users are using now the 
udisksctl which is a frontend command for the user level ?
- How to make the user experience more OpenStep like : f.e. device icon on the 
Shelf, and maybe a Disk submenu ?

The patch applied is solving one problem : it is not necessary with it to use 
the tip 'hide/show again the Desktop' to show the icon of a mounted device, but 
the mounting process itself and the User Experience are not yet optimal.

Hope these tests could help to improve.

Regards



-- 
Bien cordialement,
Patrick CARDONA
On 2020-06-05 20:33:06 +0200 Patrick Cardona via Discussion list for the 
GNUstep programming environment <discuss-gnustep@gnu.org> wrote:

> Hi Riccardo and All,
> 
> I thought that the patches You told about removable devices were avaible yet 
> within the recent release of GWorkspace.
> So I tried and achieved  to compile  GWorkspace apps from the Github 
> repository :
> After './configure' and 'make', all succeeded fine.
> 
> Well, but before a 'make install' in my user domain, I stopped and wonder 
> what would happen with the existing GWorkspace apps already there in the 
> system domain : maybe a conflict due to duplicate apps...
> So I tried to uninstall first the oldest GWorkspace from the domain system, 
> but due to the debian dependencies, I saw that this would remove all the 
> gnustep core ans apps... Bad feeling about that...
> 
> So I renounced to uninstall...
> I prefer ask You before doing some big mistake, what is the right way to do 
> it if I want the  latest GWorkspace ?
> 
> Regards,
>