Re: RGSG




-----Original Message-----
From: Gleef <gleef@capital.net>
To: Tom Vogt <tom@lemuria.org>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Sunday, August 02, 1998 12:34 PM
Subject: Re: RGSG


>> Rebel Gnome StyleGuide
>> ======================
>
>- Gnome
>+ GNOME
>
>GNOME is an acronym, and should be referred to in all caps.  I'll
>shorthand this and all other nits with no explanation needed in one line
>(eg. -Gnome+GNOME).


There's an interesting nature in english speakers to use three letters
spoken out, or four+ phonetically mixed.  So "Eff-Bee-Eye" but "Scuh-Zee".
Five letters written out in all caps looks like shouting, so we have Defcon
and...hurm, it's hard to find +4 letter acronyms, ain't it...

>Prog, I like the sound of it.  Remember, however that all the required
>menu headings will have to be translated.  Using a real word might make
>this task easier.


Very good point.  And there's the research I just did a few minutes ago :-)

>The discussion of the "File" menu needs to be a separate item (or items).
>Personally, I think calling such a menu "File" should be a C3, perhaps a
>C2, but not a C1.


Users EXPECT File.  Do we gain enough by breaking this expectation?  File
and Edit are needed.

>Also, the items in the Prog menu are likely to be very high use, common
>items.  I have never seen someone bother with the About window unless
>they: A) Need information about the program to get help or figure out a
>problem, or B) Are bored.  This usage would argue far more for being in
>the Help menu than in prime real estate in Prog.


They would only be high usage if they use the stuff from File, but if they
use the stuff from File there's no need for File, but if there's no need for
File then we remove File, and if we do that we piss users off for the only
reason that "that's the right thing to do".

Anyway, I'm not really sure why File is all that "right thing do doish".
Lets see, what kind of stuff goes into file...

New:  Make a new file
Open:  Open a new file
Close:  Close the presently open file
Save:  Save the present contents into a new file.
Print:  Print the presently open file
Exit:  Quit dealing with all these files and get out of here.
Send:  Send the present file.
Settings:  Change the settings of this specific file(any other usage is
inappropriate).
Import:  Import the contents of another file into this file.
Export:  Export the contents of this file into something another file can
use.

Am I missing something here?

>I think that user generated lists that are empty should have a standard
>"-(No Entries)-" item in it.  This, like those "This Page Intentionally
>Left Blank" pages in some manuals, will reasure the user that they aren't
>missing something (and be the source of jokes :-).


This response intentionally left blank.

[Agreed, btw.  One line only though.]

>
>> C2 - The "About" button will display a dialog with information
>> containing at least the name and email address of the author,
>> copyright information, version, and a link to the application
>> repository information. Please use the gnome_about widget.
>
>We might want to separate out Style issues (such as what information is
>supplied in an About window) from Coding issues (such as what widget to
>use).  I think coding issues should be addressed, just separately, so it's
>easier to update as the coding issues change.  Also, by this entry,
>Electric Eyes would not be a GNOME app, since it doesn't meet the C2
>requirement of using the gnome_about widget.


Well...suppose gnome_dev tells us that, yup, all applications can now have a
slick CORBA interface into any kind of file saver the user wants to use.  We
can, if we choose, C2 or C1 that.

>> 3.6  LOOK & FEEL
>> ----------------
>> C1 - [Use GTK+ widgets]


Wrong place to respond, but this is *bad*.  Use enough GTK widgets to be
compliant, maybe.  But if compliancy can be reached with FLTK, more power to
the programmer.

This reminds me of the ICCMM(sp) requirement that all keycombos be passed to
the app.  B'had.

>> 3.8  THEMES
>> -----------
>> C3 - [Color-reactiveness]
>>
>> C? - [Appearance Guidelines (Graphics, etc.)]
>>
>> C? - [Sound Guidelines]
>
>As far as I know, this entire section is C5.


Sadly, agreed.  We can't tell how great Color Reactiveness is going to be
'till it's done.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]