Re: How nautilus manage drive icons

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)" *
(GnomeVFSDeviceType type)
src/nautilus-places-sidebar.c:eject_for_type (GnomeVFSDeviceType type)
src/file-manager/fm-directory-view.c:eject_for_type (GnomeVFSDeviceType
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:///,

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?=

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]