Re: spatial stuff detail

[Raphael Bosshard <whistler bluewin ch>]

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.

Raphael

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
>  created.
>
> * 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
>     contents
>   - 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
>  NautilusObjectWindow.
>
> * NautilusNavigationMenu merges a new xml file into the same ui
>  component.  This lets us keep separate files that use the same
>  verbs.
>
> * 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
>    window"
>  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
> of
>  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
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>