Le jeudi 01 juin 2006 à 10:19 +0200, Alexander Larsson a écrit : > On Wed, 2006-05-31 at 18:36 -0400, David Zeuthen wrote: > > Hi, > > > > Any reason this is not on the list? Also, please use my david fubar dk > > email address since that's what I'm using for GNOME stuff. > > I dunno, it got removed at some point. I'm adding it back. > > > On Mon, 2006-05-29 at 14:04 +0200, Alexander Larsson wrote: > > > On Wed, 2006-05-24 at 21:38 +0200, Xavier Claessens wrote: > > > > Le mercredi 24 mai 2006 à 17:59 +0200, Alexander Larsson a écrit : > > > > > Here is the thing. I don't expect there to be a GnomeVFSDrive for > > > > > the /home volume (which i assume is a normal mountpoint on another > > > > > partition). We should only have drive objects for real removable media > > > > > mountpoints. > > > > > > > > I join a simple program I made which lists all your drives and volumes > > > > and says if they are user visible. It's what helped me understand how > > > > GnomeVFS works :-) > > > > > > This seems to be a bug in the hal version of the monitoring. We're not > > > supposed to be creating drive objects for all harddrives in the system. > > > A Drive is supposed to be something you can insert a removable volume > > > in, like a cdrom reader, a floppy reader, or a usb card reader. On my > > > system hal creates a drive for e.g. /mnt/hdb1 which is a normal ext3 > > > filesystem mounted at roottime and not user-mountable. This shouldn't > > > only exist in the volume monitor as a non-user_visible volume, not as a > > > drive. This used to be papered over in computer:// since the volumes for > > > the drives were always mounted and not user-visible, so they got > > > hidden. > > > > > > David, I don't really know the hal stuff. Could you look into this? > > > > So I'm not really sure why we want this difference you are describing. > > In fact I'd argue that we indeed want to show volumes from e.g. the > > internal hard disk for e.g. your Windows and OS X partitions. > > > > And this indeed requires a GnomeVFSDrive because the partition may not > > be mounted and we only have a GnomeVFSVolume for a GnomeVFSDrive when > > the partition the GnomeVFSDrive represents is actually mounted (that's > > my understanding of the how Gnome VFS works). > > The initial design for drives was to represent devices that use > removable media (such as cdrom drives, floppy drives, usb card readers, > etc). For these devices the operations on the device are "natural" to > the user. Its true that one can also view them as just "possible > mountpoints for volumes", which means you could have a drive for your > OSX or windows partition. However, when you expose this in the UI you > suddenly turn a very explicit obvious hardware mapping into a way to > expose the much more vague and complicated unix operation of "mounting a > filesystem". I.E. you remove the mapping from icons in the UI to > hardware units you can put stuff into. > > If you take the view of a non-unix person (i.e. one unaware of the > details of mountpoints etc) using a Gnome desktop with a separate HD > you have basically three cases. Either the partition is mounted, the > user is allowed to mount the partition, or the user isn't allowed to > mount the partition. In the first case we clearly should show a volume > icon, and in the last case i argue that we should never show a drive > icon (it would do nothing but confuse people). > > The question is what to in the second case. In an ideal desktop system I > don't think that state really is very useful. What non-sysadmin-related > use would you have for not mounting that volume if you are allowed to > mount it anyway? In the case on a non-ideal unix system the question > gets complicated and turns into a question about whether the mountpoint > is an "internal implementation detail" of the filesystem mount tree or > not, and this becomes very similar to the question whether to expand > symlinks or not (don't expand /home to /mnt/hdb/home, but expand > ~/Desktop/music to ~/Documents/MyMusic). Some cases are simple, you > never want to display /, /proc, /sys, /dev/pts, /boot, etc. However, for > others things are not so easy. I have for instance /mnt/hdb1 on my > system where i have symlinks like /opt -> /mnt/hdb1/opt. I wouldn't want > to display this. > > Whether to show such drives or not is clearly a complicated, > system-dependent issue and should be solved in the lower layers, and not > solved in each app using gnome-vfs. > > The change that resulted in this being an acute problem was that we > decided to hide drives that support auto-mount in all places but > computer:// by using the is_user_visible flag of the drive. Doing this > means that flag is used for that and can't also be used to flag whether > a drive is "internal" or not. I think just not having drive objects for > internal mountpoints is the easiest solution to this. > > > So I think what you want is to hide is exactly volumes that are mounted > > on traditional FHS mount points, e.g. /, /usr. I can't see why we should > > enforce this policy in Gnome VFS when the bits above (e.g. Nautilus, > > Filechooser) can handle this much better? > > I don't understand how you think nautilus can handle this better? > I think we can't do everything with only an user_visible flag. There is 2 different concepts: first the user_visible itself which should be used to hide partition's drives and other useless drives, second the auto-mountable property. I suggest to make something like: gboolean gnome_vfs_drive_is_auto_mountable (GnomeVFSDrive*); Like that we display all user_visible drives in computer:/// (including unmounted cdroms) but we only show user_visible && !auto_moutable drive in nautilus's place sidebar. I don't know how will GtkFileChooser work with that, because it should so see the auto_mount flag and hide automountable drives... Currently it seems that it follows the user_visible flag, at least when using gnomeVFS backend. I you are OK with this idea I can make patches for GnomeVFS/Nautilus 2.15.x For the other problem, which is computer:/// doesn't handle multi-volume drives, what about just updating the drive's icon when the first volume comes (like now in most cases) and if we get more volumes we add files like I did in my first patch. What do you think about that ? Xavier Claessens.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=