thinking outside the box (or, stealing the _really_ good ideas)

[sun <as387 yfn ysu edu>]

i screwed up fetchmail and downloaded seventy-some messages as one long
text file so i can't reply to each idea individually as they were
posted, but i have quite a few ideas about user interface specifications
that are a bit new and different so i'll just reply to each of the
individual topics here. also, i'm still trying to figure out how to get
sendmail to masquerade the domain _and_ username of my mail-forwarding
service, so if my "from" or "reply-to" is incorrect, i apologize... it
should be as387@yfn.ysu.edu and i'll be able to receive any replies
posted to the list. onward:

i was the one who suggested putting "preferences" (and yes, i do think
"options" would be a better term now) in the edit menu, and the fact
that gnomines only contains a "game" menu has brought to my attention
that we may be getting a bit _too_ restrictive with our guidelines.
therefore i'd like to propose the following:

remember the gimp, the program that started it all? i love that
interface. i've gotten completely hooked on it, and in fact for those
rare occasions when i need to do some work in photoshop i really miss
having all the commands at most an inch away from my mouse pointer just
by right-clicking. i think all gnome applications should have an option
to turn the menubar _off_ and make all the commands accessible from a
right-clickable "root menu" instead. it's just a spin for the better on
the "contextual menu" ideas so popular in win32 and mac os 8. see the
gimp and electriceyes for an example of this.

further, i'd like to propose that all the menus we're so used to seeing
be limited to their _original_ usage: for instance, the "file" menu
should only contain commands that deal directly with files on a drive,
open, save, save as, etc. "edit" should only contain commands that deal
directly with shaping _content_ of the main window: cut, copy, paste,
spell-check, whatever.

the right-clickable "root menu" should also contain choices that _are
not_ menus themselves, especially those that have been "kicked out" of
the file and edit menus: quit, options, and "show menu bar" (if you just
can't live without them) for starters.

of course, there is still the question of what to do with the "bastard"
root menu choices (like "quit," "options," and "hide menu bar" when the
menu bar is shown normally. an idea i had was to create a new menu
remeniscent of the apple menu in the mac os or the atari menu in tos
which, instead of containing os-wide options like desk accessories,
would contain those "bastard" or miscellaneous menu choices that deal
with the program itself. we could use the program's default icon rather
than a text label, too, to differentiate it from the other menus which
are more dedicated to getting the actual work of the program done.

ermmm, let me try to rephrase that: for example, all the menus in, say,
a text-editor should deal directly with the text: file containing
choices about where to save, open, and delete text files, edit
containing the standard editing tools, view containing choices about how
to display the text on screen, and so forth. then we could use the
"application" menu (labeled with the editor's icon rather than text) to
house all the commands that _do not_ deal directly with text, but with
the way the application itself works and looks: "menubar" (show or
hide), "options", and "quit".  the options in this latter menu, when the
menubar is hidden, would appear in the root popup menu itself rather
than in a submenu. "file" "edit" and "view" would appear as submenus in
this root menu as well.

did that make sense?

too, the root menu would give us something useful to map those annoying
win32 contextual-menu keys to. :)

and regarding keyboard shortcuts: i further propose that user-settable
keyboard shortcuts in the style of the gimp (again) be standard, but
that the defaults be as follows:

ctrl-z: undo
ctrl-x: cut
ctrl-c: copy
ctrl-v: paste
ctrl-r: redo
ctrl-o: open file
ctrl-w: close [window] (for programs with multiple windows or documents)
ctrl-q: quit (we should call it "quit" not "exit" since new computer
users may not understand what they're exiting... the current edit mode,
window, application, x session?)

i propose these because they seem to be a de facto standard among
windows and mac os apps alike, and it's from these two platforms that we
seem to be intent on evangelizing new gnome users. :) so how do we
finalize these? i've seen most of those defaults suggested earlier; do
we vote or something, or just hope somebody with technical writing
skills notices them and hashes out a chapter for the style guide? :)

further: there's been some talk of setting environment defaults for all
gnome applications; if you all would be so kind as to right-click a
blank spot on your panel i think you will see a perfect place for
putting these: "global properties" is the intuitive choice. (the window
that comes up when you select it is called "global _panel_ properties;
does anyone disagree that this should be changed?)

so whaddya think?
--
"Whoever saves one life saves the whole world in time." --Talmud