Re: Different vision for the GNOME Desktop?

[Patrick <pabos glypsube org>]

On Sun, 2003-06-01 at 20:15, Jeff Waugh wrote:
> <quote who="Jeff Waugh">
> 
> > <quote who="Jeff Waugh">
> > 
> > > Rather than debate these ideas in terms of the status quo, what is your
> > > vision for how GNOME should handle these software releases, and the issues
> > > raised in this thread?
> > 
> > Dude?
> 
> [ So, a couple of people have mentioned that they thought I was being unfair
> or a bastardo for 'challenging' Iain on this. It wasn't really clear in my
> email that I'm genuinely interested in finding out what's wrong with the
> process, how we can make it better, if there's "too much process", etc. It's
> kinda hard to pick out the problems with the status quo when you're part of
> the machinery. :-) That's why we always ask for suggestions to the release
> team list, etc. If anyone else has comments on this, how we structure our
> releases, where we've gone south since the 2.0 success, *please* mail us -
> we *are* keen to get the process right, whatever it takes. Thanks! ]
> 
> - Jeff

Since nobody has responded to this request yet, and I think this could
be a valuable discussion, I'll chime in here, albeit a few steps back
from just discussing the application release process. I have 5 main
points (AKA layers 0-4) and then a summary if you want to skim read.


(0) GNOME people should be working on defining what should be lower than
GNOME and shared system-wide (eg. including console) and desktop-wide
(eg. across X11 or KDE).
	- eg. hardware abstraction layer with meta-data
		- what hardware do i have and what can it do?
	- system abstraction layer (ie. gnome system tools)
		- what is a system?
			- how does it relate to: handhelds? desktops? tablets? mobile
notebooks? mobile phones? set-top boxes?
		- what is a good design over existing low-level systems?
		- what areas of the low-level system need work?
		- what areas are good but need more meta-data?
		- how can the system notify applications of changes?
		(ie. d-bus, hotplug, fam, magicdev)
	- input methods & language input (in the most general sense)
		- ie. input methods should be working already down at the console
		- ie. voice input, writing recognition input


(1) GNOME should be a set of pluggable mini-frameworks:
	- typography
	- imaging (eg. librarified gimp 1.3)
	- audio/video (ie. gstreamer)
	- structured data access
	- file access
	- higher-level file layer (?)
	- user layer
	- authentication layer (?)
	- input
	- printing

(2) GNOME could have a default interface
	- eg. menus, panel, applets, theme, etc ...
	- no applications yet
	
(3) GNOME could choose a default set of applications through which
people who agree to such things can coordinate their effort on
improving. these applications should be worked on within the context of
all possible applications and be done small, similarly focused groups
with independent (but possibly synchronized release schedules). Some
examples of groups which should coordinate their efforts:
	- office
		- word processor
		- spreadsheet
	- personal communications
		- instant messaging
		- e-mail
		- fax
		- voip
		- video conferencing
		- answering machine
	- data access
		- xml
		- relational database access
	- development tools
		- glade, anjuta, alleyoop, etc ...
	- games
	- organing & viewing
		- nautilus views
		- image, ps, pdf, dvi viewers

Each of these groups would consist of people and projects who are
talking and coordinating their efforts and making more libraries,
frameworks, etc. that can be dropped into the whole cabootle.
	- ie. gnumeric drops spreadsheet layer lower in a library so other
applications can begin to doing spreadsheet-manipulations without
starting gnumeric
	- ie. address book drops down to a level where it can be reused by
instant messenger, e-mail, bookmarks of people in web browser, voip
 ...

Each application group would restart the (0)-(4) list indicated here to
some degree as applicable.


(4) Suggested default environments - the big releases:
	- eg.
		- office desktop
		- personal/home desktop
		- scientific desktop
		- development desktop
	- the idea of a default desktop which will work for:
		- all users
		- all around the world
		- in all languages
		- with all their perspectives
		- with all their various interests
	is dumb

	- saying it isn't supposed to do that but instead work for the mythical
average person is also dumb.


(Summary)

This could probably be summarized by saying I'd like GNOME to be more
like lego. Small pieces with clean, simple knobs that allow you to build
cool stuff with it and tear it apart without effort.

Each number in the list is a different type of lego block that should be
replaceable fairly easily. The idea is to keep the layers simple and
avoid defining how they pieces have to fit together too simply. 

This could be helped a great deal by structuring the community resources
(ie. website, mailing lists, etc.) into more visible and more
specifically targetted areas.
 - eg. it wouldn't hurt if developer.gnome.org's (or
community.gnome.org?) navigation was structured around these same
layers:
	(0) system integration
		(a) kernel
		(b) file systems
		(b) x11/desktop
	(1) core frameworks / libraries (for all applications)
	(2) human interface
		(a) gtk+, libgnomeui, libgnomedbui, libbonoboui, gtkglarea,
libgnomecanvas, libdiacanvas, ...
		(b) desktop interfaces
			(i) default panel, everything in a menu approach
				(1) themes
			(ii) alternative interfaces
	(3) application groupings (& by implication new frameworks developed in
concert with a group of applications)
	(4) releases of particular combinations of the lower-layers
		- releases should be modular too:
			- libraries do releases
			- applications releases
			- library frameworks do releases of previously
			library releases
			- application groups do releases of previously
			released applications
			- gnome developer release
				- libraries & frameworks
			- gnome desktop release(s)
				- libraries, interface, & applications


I'll avoid giving specific, concrete examples of how this is not
currently the case for now since this is getting excessively long and
some might want to argue first that it shouldn't ever be the case.

One last concrete example: gnome meeting. In the hypothetical context of
the lego layers given above, gnome meeting would be developed within
some (one or more) application grouping such as "Personal
Communications". In the process of deciding what personal communications
means, what and how people personally communicate and what each of the
applications in personal communications is trying to achieve there might
arrive some agreement that a personal communications framework would be
useful (already hinted at by the formation of the application group).
Then some kind of reusable layer which tries to provide an interface and
implementation which other applications (outside of the "personal
communications" group) could also use could be developed; this might
include sharing information regarding people (ie. address book) and
initiating conversations/connections between people in an simple,
efficient, secure manner. Additionally, there could be a conscious
effort to shape the APIs of the various libraries in a similar manner to
develop consistency across all of the "Personal Communications"
applications.

Finally, in this process the goal is not to "get in" to the gnome
development desktop but to make a viable framework for a particular
application, and then for a particular group of applications and then
for the desktop in general. Anybody or any program which wants to use
the framework could do so. Additionally, the framework will be developed
within the context of the GNOME community.

For what its worth,
Patrick