Re: And now, for something completely different.
- From: Frederick I Gleef <gleef capital net>
- To: Bowie Poag <bjp primenet com>
- cc: gnome-gui-list gnome org
- Subject: Re: And now, for something completely different.
- Date: Wed, 29 Jul 1998 10:22:20 -0400 (EDT)
On Tue, 28 Jul 1998, Bowie Poag wrote:
>
> Now that we've all happily on the road to Flameville (yeesh) and as
> enjoyful as the search for whether Maciej has a clue or not may be,
> lets go on to a few slightly more important issues:
Personal attacks like this are unwarranted
> Any comments are welcome. Just fill in the blank.
>
> o In developing the style guide, how many individuals should be
> responsible for penning the original document, before it will
> be given to the public to dissect, and suggest changes to?
There shouldn't be a set numerical limit. Those who subscribe to the
gnome-gui-list should be actively participating in "penning" the original
document, before it is given to the public to disect.
> o In your opinion, what should the final product cover? Where
> should the line be drawn between "guideline" and "suggestion"?
A style guide should cover:
A) How the program interacts with the user
B) How the program interacts with other GNOME programs
There should be three categories of entries in the style guide
1) Items that are so important, that violation should be considered
to be a bug (eg, the program must be usable on an 800x600 screen,
the program must work with Session Management).
2) Items that are important to maintain the GNOME look and feel, but
can be played with by the developer if they need to (Eg. Menu Layout,
Usage of progress bars)
3) Items that are suggestions of how to do things, that the developer
can take or leave as they see fit (Eg. Using the About Widget for the
Help->About menu item).
It should be made clear which items fall into which category.
> o Should deadlines be established to ensure a smooth course of
> development?
Not as a matter of course, but deadlines used judiciously can keep a long
argument from dragging on for weeks.
> o Should the style guide address the use of sound within apps?
> Why or why not?
Yes. Sound is one of the ways which the application interacts with the
users. For example, it would be considered a bug if a GNOME app were to
disable or break the ESound daemon. It would be important for a program
to not require sound for proper operation. It would be a suggestion that
the program do whatever sound it needs through ESound.
-Gleef
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]