Identity within Compliancy Levels

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

This is a good start on a topic I've been planning to go into
more detail on.  I'd like to open a discussion about what the
different compliance levels should _mean_, and to a lesser
extent, the types of styles they should contain.

Gleef wrote:

> I have a suggestion, although I am merely rephrasing and
> elaborating on
> stuff that John Sheets said a while back.  We currently have
> GNOME-compliant applications being those who meet all points in
> both
> C1 and C2.  We should have an official "GNOME-friendly" level,
> for
> applications meeting just C1 level.

I like this idea.  I've been hemming and hawing over just how to
describe it.  "GNOME-friendly" is perfect.  I don't think this
first level (G1) should require any core GNOME features.  Its
main purpose should be to lay down the law about how GNOME thinks
all UI's (GNOME and non-GNOME alike) should behave and present
themselves.  Things like overall menu layout, feature
consistency, and well-behaved error-handling.  A G1 app should
not (intrinsically) require the GNOME libraries to run.  But,
like Gleef said, it should run & behave reliably inside the GNOME
environment.  G1 would be concerned more with universal UI
guidelines than with GNOME-specific guidelines.  A more-generic
first level will make it easier for existing apps to leap quickly
into the GNOME compliance game, and once they're in the GNOME
arena, they'll naturally tend to stay there.

[ I kind of like the idea of calling this the G0 level, since it
doesn't imply any actual GNOME functionality, and is really more
of a baseline than anything.  I could go either way, though, and
for now, I'll continue to refer to it as G1. ]

> The look and feel requirements would mostly be under C2.  All
> official
> GNOME applications should meet this level.  An GNOME-compliant
> label would
> tell the user that this program works like a GNOME program, and
> they will
> know exactly what to expect about user interface, learning
> curve, etc.

"Look and Feel" would be a good way to characterize a level.
Does this work best for G2?  I kind of see G2 as the "Entry-level
GNOME" (or "Core GNOME") compliance level.  An app that satisfies
the _core_ characteristics of GNOME qualifies for G2.  Examples
could be using the standard GNOME dialogs; having the
Program/foot menu; having a (carefully-defined) minimum of online
help; having a fully-decked-out GNOME About box; proper GNOME
registration...stuff like that.

After that, G3 would kind of be the "Integrated GNOME" level (I
hesitate to use "fully GNOME" because that might imply that
developers should stop at G3).  This level would include deeper
integration into the GNOME environment, like session management,
internationalization, etc.  Things that can be added on to
existing apps without mandating a total reworking of their code.
A full-fledged online help document (bigger than the G2-required
one) would also fit here.

The more earth-shaking (or code-shaking) features would go in G4,
"Advanced GNOME".  This would include the upcoming GNOME Object
Model (called Baboon), which may require deeper changes in the
organization of an app.  Also, menu themes, advanced CORBA
encapsulation (for possible macro scripting),  etc.  These are
features a GNOME app may not necessarily need, but are
potentially very useful.

And finally, there's G5, "Extended GNOME".  This level holds all
the groovy high-tech fluff features that really aren't needed by
an app, but which make it cooler, prettier, and easier to use.
By the time an app reaches this point, it is already a solid,
full-featured GNOME app.  It has come a long way, and is now
ready to play.  Examples are animations, tear-off menus,
color-reactiveness, sound themes, icon themes, etc.

I think the transition from G4 to G5 is the most critical
transition of all.  The problem is that levels G1-3 all hold
feature sets that all apps would require.  At level G4, however,
we (by definition) depart from that.  For example, not every app
will need to use the GNOME Object Model.  Nor should we require
it to.  Thus, G4 will be the first (and only) case-by-case
judgement-call compliancy level.  If it can be proven that a G4
app does not fit with a G4 feature, it can safely ignore that
feature and proceed on to G5.  But only in G4.

Unfortunately, this seems to put a heavier burden on certain
types of apps, e.g. word processors.  They must suffer much
broader certification than, say, a mixer app, where a document
model wouldn't make much sense.  I think it would be better to
make exceptions here, than to force all apps into all these
features.  If there's a better way to handle this, please speak
up.

Anyway, those are my thoughts for now.  I'll have plenty more in
the future.  Let the games begin....  (c:

John