Re: about adding pop menu in treeview

[Fabio Gomes de Souza <bugtraq gs2 com br>]

> While technically possible I think it would be quite confusing, because
> there is little visual indication of which view has the focus, and the
> tree doesn't really have a normal selection, it just constantly
> highlights the current directory. I don't think people will understand
> what gets copied when they select file->copy.

Windows Explorer does this with no confusion.

> Can you tell me exactly what part you want detatched?
> real_update_menus()? That function is quite dependent on the "view one
> directory" concept, and an implementation for e.g. the tree view would
> look quite different.

I was thinking about a simple way for applications to use the popup menu 
for some file. I am talking about a stupid 
show_popup_for_file("/home/foo/foo.txt") or some more clever method to 
get the _same_ popup that nautilus shows but with the ability to add 
more items.

For example, if I create a text editor that has a tree pane or some kind 
of "project management"

> > Nautilus should export to the other GNOME applications its ability to:
> > - Manage files (move/copy/trash, etc)
> gnome_vfs_xfer()
I mean moving/copying/deleting files with those nice Nautilus progress 
dialog boxes that pop up after N seconds giving the user ability to 
cancel, with confirmations for overwriting, deleting, etc.

I also mean moving/copying/deleting entire directory structures, like 
nautilus does promptly and gracefully, asking for overwriting, etc. It 
is hard to implement such a thing in a reliable manner in an 
application. Nautilus already has the code and it has been tested and 
proven to work. It would be nice if applications were able to use this code.


> > - Show a popup menu for a file
> Most of this is in gtk and bonoboui. You of course have to do some work
> to specify exactly what this menu should contain.
Like I mentioned above, apps should be able to use Nautilus popup menu, 
optionally adding some functionality.


> > - Decide which program should be run to open a file
> The gnome vfs mime system has this
Apps should be able to do this _exactly_ the same way as Nautilus does. 
I mean, if Nautilus adds any functionality to this, then this added 
functionality must be moved to the GNOME API for consistency.

> > - Fetching properties of a file
> > - Changing properties of files
>
>
> gnome_vfs_get_file_info () and gnome_vfs_set_file_info ().
> Or do you mean the properties dialog?
Yes. I mean the properties dialogs. :-)

> > - Show a FMDirectoryView
> > - Show a tree
> I don't think embedding part of the file manager anywhere else would be
> good. However, I think most of the core code of the view/tree should be
> availible to developers in the sense of easy to use tree and icon
> container widgets. Currently we're a bit weak on the icon container
> part.
IDEs for example. Embedding parts of the file manager is essential to 
them. Or am I being stupid? :-P

> > Nautilus-the-program would be a simple shell/frontend to this library.
> >
> > This big change would:
> > 1. Enrich the GNOME framework
> > 2. Improve application interoperability
> > 3. Increase consistency between GNOME applications by code sharing
>
>
> I think we do these pretty well already.
And we could do even better. :-)

> > 4. Promote the innovation of file management in GNOME, since people 
> > would be able to implement Nautilus-the-library frontends without 
> > needing to reimplement the GREAT nautilus core functions.
>
>
> Innovation by duplication of filemanagers? I'd rather spend my time
> making the current filemanager better.
Specialized file managing thingies will always be around, regardless of 
nautilus being soon the best file manager in the world. I mean, Nautilus 
will never be a better picture manager than gThumb. Because Nautilus is 
not intended to be a picture manager. It's a generic file manager. Now 
imagine how easy it would be to write a "music manager" like Rhythmbox, 
but importing lots of functionality from Nautilus. Hmm.. :-)

> > Imagine if gThumb, for instance, was able to use same Tree as nautilus, 
> > the same popup menus, the same code for moving/copying/deleting files, etc.
>
>
> Personally I think it would suck pretty badly if gThumb was forced to
> have an identical popup menu to Nautilus. The second one wants to add
> *anything* to that menu you couldn't  use the nautilus menu anymore.
> What makes sense is to export the underlying functions, and we do that
> pretty well already.

Well, the nautilus popup menu on gThumb does not make any sense if you 
right-clicked the thumbnail of an image, but think about right-clicking 
a folder in the tree (which was imported from nautilus too).

While I was writing this reply, I realized that I'm proposing ripping 
nautilus into some kind of gnome-vfs-ui. :-)

Sorry if I am wasting your time.

Best regards,

--
Fabio Gomes de Souza <fabio gs2 com br> (+55 81 9127-0597)

.- GS2 TECNOLOGIA DA INFORMACAO LTDA :: www.gs2.com.br
|- IT Infrastructure :: Security :: Embedded systems :: Linux
`- Olinda, Brazil - +55 81 3492-7777 - negocios gs2 com br