Re: about adding pop menu in treeview

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)
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
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)

|- IT Infrastructure :: Security :: Embedded systems :: Linux
`- Olinda, Brazil - +55 81 3492-7777 - negocios gs2 com br

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