diff options
Diffstat (limited to 'docs/gnomad-notes.txt')
| -rw-r--r-- | docs/gnomad-notes.txt | 125 |
1 files changed, 0 insertions, 125 deletions
diff --git a/docs/gnomad-notes.txt b/docs/gnomad-notes.txt deleted file mode 100644 index 23cd0dece..000000000 --- a/docs/gnomad-notes.txt +++ /dev/null @@ -1,125 +0,0 @@ -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. Misc suggestions - -"One thing I like in windows is how you can select a file, and it views it on the side as -a preview (for picture files and html files)". (Easy to implement.) - -5. Nautilus scenarios - -irc://irc.gnome.org/#gnome - Shows xchat as the content view, and a list of 'Recently Displayed URLs' as a - meta view. -ghelp: - Displays the help intro page as the content view, and the table of contents, - help search, and help index as meta views. -file://localhost/ - Displays icon list of files as content view, and directory tree and file - properties as meta views. -http://www.gnome.org/ - Displays the web page as the content view, and web search and what's related - as meta views. -mailto:sopwith@gnome.org - Displays mail composer as content view, and address book as meta view. - -6. 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). |