Re: How nautilus manage drive icons

[Alexander Larsson <alexl redhat com>]

On Tue, 2006-05-09 at 19:59 +0200, Xavier Claessens wrote:
> 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.

I don't think the internal representation of these objects are all that
interesting. The reason they are different is that they have to. One is
implemented as a gnome-vfs backend, and that can only communicate by
generating (possibly fake) files, whereas the other one is an in-memory
object that was done to avoid writing crap files in the desktop folder
on disk.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an oversexed neurotic messiah from a doomed world. She's a disco-crazy 
wisecracking Valkyrie who inherited a spooky stately manor from her late 
maiden aunt. They fight crime!