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:
[EMAIL PROTECTED]:~/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.
signature.asc
Description: Ceci est une partie de message numériquement signée
-- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
