Add notes.

Add notes.

Pass the content view along with a location-changed message.

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