Re: about adding pop menu in treeview

On Mon, 2003-11-10 at 13:16, Fabio Gomes de Souza wrote:
> > 
> > I'm not sure what sort of things we want in the tree context menu. Do we
> > want all the normal ones like cut, make link and rename? If we do, we
> > might actually want that these are in the main menus too, even if the
> > main view doesn't show a directory. However, that causes lots of trouble
> > for the menu operations, I mean, which selection does Edit -> Rename
> > affect, the one in the tree or the one in the main view. 
> This depends on the focus. If the focus is on the tree, the action 
> regards the currently selected item in the tree. Don't know if this is 
> possible. Maybe it would be necessary to track the focus in some way. I 
> am not sure.

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.
> > I think the right way is for the tree view to have its own BonoboUI file
> > defining its own context menu, and then a few generic functions need to
> > be extracted from fm-directory view, for handling things like file
> > activation and file cut and paste.
> I still second the other people's opinion of reusing the popup menu 
> code. IMHO it should be detached from FMDirectoryView. Actually, a lot 
> of stuff should be detached from nautilus and moved to a library with a 
> stable API.

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.

> Nautilus should export to the other GNOME applications its ability to:
> - Manage files (move/copy/trash, etc)


> - Discover file icons

gnome_icon_lookup ()

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

> - Decide which program should be run to open a file

The gnome vfs mime system has this

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

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

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

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

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

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an immortal albino librarian who dotes on his loving old ma. She's a 
violent paranoid socialite who can talk to animals. They fight crime! 

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