Le mardi 09 mai 2006 à 19:59 +0200, Xavier Claessens a écrit : > Le mardi 09 mai 2006 à 18:59 +0200, Christian Neumair a écrit : > > Am Dienstag, den 09.05.2006, 10:25 +0200 schrieb Xavier Claessens: > > > Le mardi 09 mai 2006 à 10:01 +0200, Christian Neumair a écrit : > > > > > For volume icons from the desktop, is it possible to make it work like > > > > > in computer:/// ? nautilus should generate on-the-fly same .drive files. > > > > > Like that we are sure that at least icons from desktop and from > > > > > computer:/// react the same way. > > > > > > > > Passing around on-the-fly generated files (which would have to be put > > > > into file:///tmp) isn't a good idea IMHO, because it requires sniffing > > > > foreach passed-in URI. My proposal tried to address the fact that some > > > > applications are interested in volumes or drives but not in their > > > > corresponding files, since the actual volume/drive data can be queried > > > > from the volume monitor. > > > > > > Ok. So computer:/// should works like x-nautilus-desktop:/// and > > > nautilus should never use the on-the-fly generated .drive files. Like > > > that most problems are solved because icons from desktop aren't accepted > > > for dropping anywhere. > > > > No, it doesn't solve the problem, because - as you pointed out - not > > doing anything isn't really user-friendly either. IMHO it would be the > > best to operate on the drive's activation URI when dropping a volume or > > drive file to another folder. > > As I understand we have currently 2 representations possible for a > drive/volume icon in nautilus. One for computer:/// and another for > x-nautilus-desktop:///. So I think the first step is to have only one > representation. We should only use the first or the second or maybe > another system which will replace the two. > > So my question is: we should use computer:/// representation for > x-nautilus-desktop:/// ? Or the reverse ? or something else ? > > When we have one single representation we should patch other > applications (including gnome-panel and nautilus itself) to accept in > one way or another DnD of this representation. > > Xavier Claessens. > So what can we do now for GNOME 2.15 ? I think nautilus should really have a common way handling drives/volumes files. Here is an example of *really* bad design: zdra zdra-desktop:~/programmation/gnome/nautilus$ grep -r "eject_for_type (GnomeVFSDeviceType type)" * libnautilus-private/nautilus-desktop-link-monitor.c:eject_for_type (GnomeVFSDeviceType type) src/nautilus-places-sidebar.c:eject_for_type (GnomeVFSDeviceType type) src/file-manager/fm-directory-view.c:eject_for_type (GnomeVFSDeviceType type) src/file-manager/fm-tree-view.c:eject_for_type (GnomeVFSDeviceType type) Yes this basic function is defined 4 times in different files ! There is also functions like the one which says if an GnomeVFSDrive should have a "eject", "unmount", "format",etc popup menu option which is copy/pasted everywhere in nautilus. So what I propose is adding some objects to libnautilus-private to have a common way handling Drive and Volume files. In the same way of nautilus_destkop_* we can make something like nautilus_volume_file and nautilus_drive_file which would be used to computer:///, x-nautilus-desktop:///,etc. On this objects we can have methods like gboolean nautilus_drive_file_can_eject (NautilusDriveFile*); to replace the eject_for_type(). And void nautilus_volume_file_get_options (NautilusDriveFile*, gboolean *show_mount, gboolean *show_unmount, gboolean *show_eject, gboolean *show_format); To know which options we can show for this file. I don't know exactly how all that can work and if that's a good idea but I can work on it this summer. I'll experiment some patches as soon as my exams finishes. I would be happy to have comments on this. Xavier Claessens.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=