diff options
author | Elliot Lee <sopwith@src.gnome.org> | 1999-12-07 17:46:29 +0000 |
---|---|---|
committer | Elliot Lee <sopwith@src.gnome.org> | 1999-12-07 17:46:29 +0000 |
commit | 685753b110ed487f68cee6b0d9029f8b2a4b231b (patch) | |
tree | 4baab6d446622afab46630cbf5315047f71769d5 /docs | |
parent | 1d23907d45a168e45dc65b89b36f30bb094c37ff (diff) | |
download | nautilus-685753b110ed487f68cee6b0d9029f8b2a4b231b.tar.gz |
Add notes.
Add notes.
Pass the content view along with a location-changed message.
Diffstat (limited to 'docs')
-rw-r--r-- | docs/gnomad-notes.txt | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/docs/gnomad-notes.txt b/docs/gnomad-notes.txt new file mode 100644 index 000000000..114e8ab45 --- /dev/null +++ b/docs/gnomad-notes.txt @@ -0,0 +1,103 @@ +1. A definite improvement over the previous version I saw. +2. Contains some interesting ideas: + Features: + > Multiple content views + > Display of an XML file as a frame floating in the content view + > Customizability + I like the ability to drag colors from the color selector to a window. + > Interface + . Much attention paid to producing a user-friendly result here. + . "Everything Windows explorer is and more" + . Simplicity of available operations + . Providing as much useful information as possible from a given screen, without + overloading the user (e.g. thumbnails). + . I like the (debated) user levels, but wish their differences were known. + Design: + Implementation: + > Code is survivably good - not wonderful, but not procmail + > Using XML allows easy integration of web data sources, etc. + +3. Has some drawbacks: + Features: + > Interface + . Value of the panel is questionable + . Double-click vs. single click needs explanation/exploration + . More information on what the new user + . The "file operations" area of the interface is not explored very well and + is very vague. + Design: + > Is basically a collection of intertwined widgets, rather than + a data-oriented class hierarchy. + > No abstraction of common patterns + > Extensibility virtually non-existent + > Generally poor. + + Example - instead of instantiating the a certain class with a well-known + interface when a particular view is requested, MultiView is used + with a number of set_*_view() functions that are hardcoded to display + certain views. + Example - The iconview has special cases for the vault in its metadata-reading code. + Example - There is only one application-level class that is ever derived from (IconView), + out of the thirty or fourty such classes present. + Implementation: + > Performance is poor (possibly due to use of AA canvas) + "It has to be faster if you are going to get people to use this" + > Uses Gtk-- + . In constant flux + . Relatively high resource demands + > Somewhat buggy + > Using XML - may not always be appropriate, has performance implications in the + current usage situations, what about gnome_metadata. + > Doesn't use gnome-vfs + +4. My conclusions + +gnomad is very focused on the user interface, and looks promising for producing a good +user experience. + +The patterns that pieces of gnomad fit would allow for easy integration into Nautilus. + +I recommend that that an assessment be made of features still needed from Nautilus, and +that we turn the various views of Gnomad into Bonobo controls for use in Nautilus. + + +Appendix A: What Nautilus is + +The generic pattern of content view/meta views/available operations occurs in a wide +variety of situations. The Windows web-browser interface uses the basics of this, but +does not exploit it to its full potential. + +Nautilus is a data shell that uses Bonobo components to present the best possible user +interface for a given piece of data. When navigation to a particular URL is requested by +a view (either the main content view or one of the meta views), Nautilus determines what +content view and meta views should be displayed, based on the requested URL, the +referring URL, the content type of the requested URL, and application configuration. + +This allows a standard yet appropriate interface to be provided for an infinite variety +of data types. + +http://people.redhat.com/sopwith/h3.gif contains a screenshot of the help browser +prototype that produced the idea for Nautilus. This window follows the content +view+meta views pattern that Nautilus supports. + +Based on analysis of gnomad, features that Nautilus design still needs: + More thorough examination of what data-related elements the user interface + should incorporate (especially in the areas of toolbars/menus). + + Ways of displaying meta views besides as tabs in a notebook. + + Multiple content views. + + Passing RDF-like tree from content to meta views, instead of just the URL. + +Other features that I had been planning to add: + Ability for displayed views to modify menus/toolbars + (just need to make use of GnomeUIHandler, I think). + + Finish implementation of the whole URL -> set of views code. + + Finish implementation period. :) + +Appendix B: Bugs + +Remove semicolon from end of music_view.cpp:115 (still doesn't work, oh well). |