Re: Proposal for First Draft of GNOME Style Guide 1.1

[John R Sheets <dusk smsi-roman com>]

Yes.  I agree with you on pretty much every issue.  The items from the
existing Style Guide need a lot of work in some cases.  I think Tom has
started on this in his recent posting of the RSG (although I prefer the title
"Rogue Style Guide" to "Rebel Style Guide).  (c;

Gleef wrote:

> I like these categories.  Minor point, a C5 could very well end up as a
> C1 or C2 (eg. propigation of a security issue or something).

Very true.  Don't know why I left those out.

> > ---------------
> > GNOME Guidelines
>
> This seems like an artificial distinction to me, between Universal and
> GNOME Guidelines.

Yes, after further thought, I agree with you (and Tom, who has already removed
this distinction in later versions).  I wanted to try it on for size, and
while I still think it is a good idea, it would lead to unnecessary
duplication of sections and more confusion.  Not worth it.

> > 2.1  MENUS
> > 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.
>
> This needs to be broken up.  The "About" window must (C1) have certain
> things (name, email, copyright, version).  It should (C2) have other
> things (link), and it should (C2 or C3) use the gnome_about widget.

I like this idea.  There a few other single items that should be broken up as
well.

> > C4 - [Pie Menus]
>
> From what I've seen about pie menus, they should be a C5 for now.  All
> I've seen is a lot of research about how great they are, and one really
> ugly implementation that doesn't go with the GNOME/GTK+ look and feel at
> all.  Once we have a good implmentation of pie menus, and have tried out
> various ways to use it, then it could come out of the experimental stage.
> Of course, if my information about pie menus are as dated as they likely
> are, I will happily stand corrected.

Yep, that was definitely mislabeled.

> > 2.5  NAVIGATION
> > C1 - All functions of the application should be available through
> > the default user interface.
>
> I'm not entirely sure I know what this point is trying to say.

....That you shouldn't have to go hunting through special channels to find
hidden functionality.  Or that you shouldn't have to explicitly enable any
functionality (although I suppose you should be allowed to disable stuff that
you don't need, as long as it's all enabled by default).  But I think your
point is that this should be made clearer.  Agreed.

> > 2.6  LOOK & FEEL
> > C1 - [Use GTK+ widgets]
>
> This should be a C2.  There are going to be cases where a developer feels
> that the GTK+ (or gnome-libs) widget is inadequate for the needs of the
> project, and roll his own.  We also should give detailed guides for custom
> designed widgets.

I hadn't even considered this, but you're absolutely right.  We should only
require a GTK-like interface, not specifically a GTK+ widget set.

> > 2.8  THEMES
> > C3 - [Color-reactiveness]
> >
> > C? - [Appearance Guidelines (Graphics, etc.)]
> >
> > C? - [Sound Guidelines]
>
> I think that most theme support is C5 at the moment.  Rasterman has been
> the main force behind implementing themes, and he seems caught up in
> higher priority things right now.

Yep, and color-reactiveness should really be a C5, too, because it's only
marginally coded.

> > 2.10  APPLETS
> > C3 - [Minimum CORBA interface]
>
> My understanding is that Applets (i.e. the programs designed to run inside
> the panel) should be a C2 as far as using the standard CORBA interface.

This should probably be split into multiple Cx's as CORBA applet support
improves beyond the bare essentials.

> We also should discuss other applet issues, like how much space to take up
> in a vertical or horizontal panel, required menu interface items, etc.
>
> Also, there has been talk about making the panel resizable.  If this is to
> be, resizable applets would also be a requirement.  Yes, this would be a
> serious programming burden, so I don't know if we should even be thinking
> about it.

You getting all this, Tom?...  (c:

Thanks, Gleef.

John