Re: So what's the plan?

[Tom Tromey <tromey creche cygnus com>]

>>>>> "cls" == Christopher Seawood <cls@seawood.org> writes:

cls> Is there a "white-paper" of sorts that explains exactly what the
cls> planned "released" gnome desktop will be and include?

Not that I know of.

cls> When will a stable end-user version projected to be out, ie 1.0?
cls>    (6 mons? 1yr?)

I doubt there is any sort of timetable.  Free sw projects usually
don't have them.  Some, like most FSF projects, never give them as a
matter of policy.

cls> What will this release contain? 

I doubt there is an (existing) answer for this, either.

My feeling is that 1.0 should happen when the core code is stable
enough that we aren't afraid to have anybody use it.

The core code is the gnome-libs module (gnome libraries), the
gnome-core module (help browser, panel, session manager, and property
configurators), and mc (the file manager).


Maybe a window manager should be thrown in there.  This depends on
somebody doing it.


Of course, this is just an arbitrary reaction on my part.  But then,
your question really needs an answer to the real question: "What is
Gnome?".


cls> The impression I have is that you want to give a standard
cls> look-n-feel for any current (and future) applications.

Sure.  But of course both the look and the feel will evolve over time.
For instance, right now there isn't a good way to handle the whole key
binding issue.  When that is solved, it will result in a change to the
feel of all apps...

And look-n-feel isn't the only issue.  The deeper ones have to do with
interoperation: using CORBA when appropriate, talking to the wm the
right way, talking to the session manager, supporting drag-n-drop.

These are the things that will tend to exclude random Gtk (or Motif,
or Qt, or Tk) programs from "full Gnome compliance".  Getting the L&F
right is pretty easy, I'd bet, since we're more or less just following
Motif (+ some Windows stuff) at the buttons-n-menus level.


cls> Does this mean that there will be at least one GNOME version of
cls> each type of application available?

I hope so.  But of course this won't happen in the first release.  And
of course it depends on volunteer interest.


Of course, what it means to be a Gnome application is (I hope!)
somewhat nebulous.  Clearly anything that uses the Gnome libraries,
etc, is one.  But ultimately I'm more interested in interoperability
via CORBA... I personally think that forcing a particular
implementation technology isn't the greatest thing.

Still, that view probably isn't shared by all Gnome developers.  And
in the short term I'd expect to see a very narrow definition of what
"Gnome" means.  And in the long term I'd expect to find that it will
always be easier to write a "Gnome-compliant" (whatever that means)
application using the standard Gnome implementation technology: Gnome
libs, Gtk, MICO, etc.


cls> Can anyone just throw together a gtk app making it conform to the
cls> Style guide with all of the proper gnome specific features and be
cls> expected to be included as part of the GNOME desktop?

Sure, why not?

You'll find it easier to do some things if you use the Gnome
libraries.  These are in a separate gnome-libs module precisely so
people can use them without having to check out and build all of
Gnome.  Some of the things that are easier with these libraries:
proper argument parsing, session management, help interaction (maybe
not now, but certainly later on), standard dialogs and buttons.


cls> There is already a list of things that people are currently
cls> working on and a couple of hints of projects to come (GPresent?),
cls> but what are the _required_ applications that need to be
cls> available before GNOME will be considered "successful"?
cls> Successful in this context meaning that it includes all of the
cls> applications needed for a standard end-user desktop.

I wonder about this, too.  Where does the desktop end?  Maybe nowhere
-- and this is a question without an answer.  Pragmatically, we'll be
done when the to-do list is empty.  I.e., never.

Put another way, I don't think we'll ever reach a "success" point.
Success is an ongoing process.  For instance, if gcc development were
to stop today, then in a year or two gcc would be a "failure" in an
important sense.

So instead I think we should just look at questions we can answer
(although not always in advance).  "When should we do the next
release?".  "Is <whatever> a good idea?"  "Do we need program <quux>?"


The above is all IMHO, natch.  I have no idea what the other Gnomers
think about this stuff.

Tom