Re: spatial stuff detail

My only concern is that there will be a gap between the usual file handling (like moving files from one place to the other) and opening files from an application (File->Open).

Any idea how the object-oriented idea could be applied to the new file picker? Else, users will still have the location-based based file management around.

I like the idea though. I'm really curious how it "feels" like.


Dave Camp wrote:

I just committed the start of the spatial UI stuff to the
nautilus-spatial-playground branch.  It'd be nice if people could
pound on it for a little bit.

What has changed from a UI perspective:

* Object windows are created by default from the desktop.  Navigation
 windows can be opened from the menus.  Right now all that is
 implemented is Open With -> Navigation Window, but a "New Navigation
 Window" entry in the desktop context menu could pretty easily be

* Object windows are one-window-per-location.  They do not have the
 following UI:
 - Search UI
 - Back and Forward
 - Bookmarks menu
 - Toolbars
 - Side pane

* Navigation windows are basically the same as they used to be, but
 they don't save their geometry anymore.

* The default window size is much smaller.  This was to make the
default object window size sane, and I just haven't gotten to fixing it for nav windows.

Unfinished UI:

* I didn't finish porting the view as combo in the location bar.

* The "New Window" stuff isn't in the desktop context menu or the
 file menu.

* Lots of little bits - these things all need to be collected.

Some open UI questions:

* I moved "Open in New Window" to "Open With -> Navigation Window". I thought that this might reinforce the idea of the browser as a separate app. Any thoughts?

* Some ideas for differentiating the navigation window:
  - give it a constant, special icon rather than the icon of the
  - put a "- Nautilus" (or whatever) string after the current
    directory (or whatever the hig suggests for this sort of thing).

Implementation Notes:

* Unfinished parts are tagged with #if NEW_UI_COMPLETE.

* NautilusWindow has been split into a NautilusWindow base class, a NautilusObjectWindow subclass, and a NautilusNavigationWindow
 subclass.  NautilusDesktopWindow now derives from

* NautilusNavigationMenu merges a new xml file into the same ui
 component.  This lets us keep separate files that use the same

* I sort of abused the open_location_* functions in the idl. open_location_in_this_window -> "open location according to the current window (new object window or this navigation window"
 open_location_prefer_existing -> "open location in new object
open_location_in_new_window -> "open location in new navigation window".

* nautilus-window-menus is pretty well separated between the different
 subclasses, but nautilus-window-manage-views is still very tied
 together - a lot of the nav stuff needs to be built in there.

* Some stuff is blocking on the views being able to find out what kind
 window they're sitting in.

Some open implementation questions:

* How do we want to change the idl?  Should we just stick with
 abusing the open_location_* rather than trying to change things?
 (it's worth noting that the old semantics of those functions
 don't make much sense now).

* How do we want views to figure out what kind of window they're in? Ambient property for the control? idl extension?

* Is it worth the bother of trying to cleanly subclass the navigation
 parts of manage-views?

desktop-devel-list mailing list
desktop-devel-list gnome org

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