Goals and Organization

LuisVilla4: Two folks wiser than I, who I badly paraphrase here, had the following suggestions about ThreePointZero:

• Make GNOME a standards organization instead of a software development shop.
  • The core of the argument here is that GNOME has several, sometimes-conflicting goals: push a development platform, push a specific set of packages, and push a design 'aesthetic', where aesthetic is widely construed. The suggestion here is to focus on the aesthetic, and make GNOME a clearing and rating house. Instead of choosing one browser or one office suite, for example, and implicitly discouraging the others, this would allow this standards body to equally encourage many projects to meet 'our' standards.
  • The standards could look something like this:

    • Level 1: Widgets look like a GNOME app. You'd basically get this for free by using gtk, but we'd strive to write the standards in such a way that other widget sets could get in on the action. OpenOffice + michael's patches would probably be a Level 1 app at this point; KDE apps with a gtk/GNOME-matching theme might qualify as well.

    • Level 2: basic HIG compliance: your layout matches the 'GNOME layout', keybindings are consistent where appropriate, etc. Abi or RealPlayer might be examples here.

    • Level 3: totally a 'GNOME app'- design is user-centric, serious ease-of-use focus, etc. Gossip or NetworkManager might be examples here.

  • besides requiring very serious thinking about what goals exactly we're certifying, this would also require extremely serious documentation- exactly 'what a gtk app looks like', for example, down to each specific widget, and probably a rethinking of the HIG to merge in things like accessibility that we also consider important design criteria.
  • gtk and existing GNOME development could continue, but GNOME would not 'bless' a complete desktop- only a list of apps meeting the above standards, which others (probably usually distributors, but could be anyone) could then pick and choose from to form a complete desktop as they wished.
• Make GNOME truly-cross platform- i.e., make apps and environment work on Windows.

  • MikeHearn: That's already happening. Why does it need to wait for 3.0? I question the cost:benefit ratio of the GNOME desktop on Windows though, it might prove restrictive to maintain

  • In a full rethink of GNOME we need to analyze what we think the 'Desktop' really is. Is the desktop a panel, menu and file manager? Or is the desktop really the applications that people use to get work done. This is why we need to rethink this Linux only desktop solution we have. If GNOME actually is just a set of standards, then the 'GNOME Desktop' can be something that runs on Windows, Mac, and Linux. Keep in mind, what a desktop really is to most people (in short and using Apple terms) is this: Web, Mail, iWork, and iLife. The parts that make us Linux only (panel, file manager and the like) aren't the applications people use to actually get stuff done. - BryanClark

• Make a desktop with a rich multimedia and conectivity experience:

  • The use of music, video, IM and VoIP will shape the use of domestic enviroment. - AlbertoRuiz

  • We must talk with the world - The content that users manage with their applications, should be easy to export to the internet and easy to share with others, not only via e-mail, but with other technologies. Jabber, cherokee and RSS could be good technologies to get this achived. - AlbertoRuiz

Overall goals

ChristianSchaller: I think the dicusssion so far have been way to much about this technology or that. I think we should start by looking at a theme for GNOME 3 then based on that theme pull in technologies and set direction for our subcomponents. In my opinion there are two trends marking the desktop evolvement going forward, its making the desktop a member of transparent networks and enabling the common desktop as a multimedia hub. GNOME 3 should be about making the N in GNOME actually mean Networking in a real way and make the M mean Multimedia. Let say that the goal of GNOME 3 is to make sure that GNOME itself and its applications work as seamless as possible with other desktops and devices on the network and that support for multimedia equipment and devices is seamless too. Every component maintainer should come up with a list of items on how their component/application can tie into that theme and what they would need from other underlaying components to make this happen. Lets turn this discsussion from being 'we want Cairo because Cairo is cool' , to being ' I want to make my application/desktop component do this to fit with the Multimedia theme of GNOME3' and for that I need something like Cairo.

EudoxOs: Yes, I second to this. From my point of view the ability to deply GNOME remotely (thin clients especially) may bring it to enterprise world. GNOME does NOT work on thinclients very well now (if you login on two machines, only one gets gconf working, apps opening on the other display if already running etc. --- this is not GNOME proper, I know...) and it should be designed without neglecting networked environments like it seems now.

GabrielHurley: We'd better get working on this; KDE has already made major developments in KDE4. Check out the Appeal Project website. In particlular, they have an interesting list of concepts found here: http://appeal.kde.org/wiki/Concepts

StephenHenry: I think that instead of focusing on blue-sky ideas for GNOME3.0, the focus should be on creating a line-in-the-sand release upon which third party developments can build their applications. At the moment, the entire GNOME environment is simply too dynamic to offer a high degree of confidence to organisations looking to port existing applications to Linux. Look at, for example, the discussion with GIO. A robust and scalable IO subsystem is a core component of all modern desktops, but even after 10+ years in development, the implementation in GNOME is still in a state of flux. I think I even read somewhere about modifying the filechooser for the next release. Although this is unavoidable to a degree, due to the nature of OSS development, such a situation is simply unacceptable in this day and age. We cannot reasonnably expect companies to port to the GNOME platform if it constantly changes to adopt the latest new technology; technologies that arguably should have been set-in-stone years ago.

What I would like to see from GNOME3.0 is a firstly a consolidation of all of the major components expected in a modern desktop platform (IPC, HAL, IO, etc...) in to a relatively stable form from which third-party developers can be confident that if they build their appliation on GNOME, the platform will not change beneath their feet.

Secondly, I would like to see a rebranding of the core technologies in GNOME, so that it makes sense in the context of GNOME as a platform, and not a collection of disparate technologies from every corner of the internet. So, for example, a developer could go to developer.gnome.org, and find a number of categories of GNOME IPC (dbus based or what ever is being used), GNOME HAL (based on fd's HAL), GNOME IO (gnome-io and networking stuff). As a developer, I don't care if DBUS or something else is used for IPC. I simply want to have a common IPC mechanism from GNOME that works, and works well.

Thirdly, the GNOME platform needs documenation -badly. I don't mean a simple regurgitation of code comments, but a well laid out and centralised repository of all the key technolgies in GNOME. You wouldn't expect a company like, say Adobe, to crawl through pages of source code, or old sample programs to find out how to do trivial desktop related tasks. No company in their right mind could ever justify porting a serious application to GNOME until this is fixed.

Finally, language bindings should be incorporated and supported as first-level APIs, like the C-implementations. A developer should be able to pick a supported binding (say Python) and know that for all technolgies in the current release, (IPC, HAL, IO, etc...), a suitable library exists in the supported binding. It's simply not good enough to say that, for example, Python is supported for development, but that it supports only a subset of the current API and that for serious upto date work, the C-implementation needs to be used. Secondly, why should a developer go to an other site to learn about GNOME related bindings (pygtk for example)? They should be contained and updated on the developer.gnome.org website like the C bindings.

To summarise: GNOME3.0 should be able consolidating the technologies developed since 2.0 and package them into consistent and centralised form. It should be all about encourging serious third-party applications to be ported to the platform.

• ThiloPfennig: I dont think being that conservative would gain much. I think its ok if development in 2.x sticks to what is already there. But from 3.0 I would expect a completely new system which tries to illiminate all the errors that were made before. But instead as like KDE 4 I would suggest not to focus on the look so much, but to make things simple as well as flexible. Maybe some parts could be incorporated - but I think it would be a very bad move if GNOME woudl try to make a better GNOME, again. my fear is that GNOME will soon become simply irrelevant. Maybe this is not too bad - but what I suggest could also be done by any other new project. Since years we now have the big three KDE, GNOME, XFCE - but that doesnt mean that this situation will be like this forever. There is a need for a new common desktop standard, which is already discussed in desktop-architects list. Fact is that we we too many APIs in Open Source. So I think a new GNOME should not be a GNOME in the sense of a GNOME API with all the existing APIs, but instead create a new common base, where KDE, GNOME, OO.org and Mozilla work on. This would release a lot of energy. Many things could just work, because they were built to do so from ground up instead of having to work a lot of getting the interfaces in order with all the different agendas. I think the different energies should rather go into the different applications, etc.

What can be improved today

SebastienTricaud: Starting a pool to know stuff users like & don't like in GNOME can be a start of things we cannot change in 2.x but can afford in 3.0. We should however be careful not to waste our time with trolls. But coming up to users and ask :

• What they hate in GNOME: things that sucks
• What they don't like in GNOME: things that should be improved
• What they like in GNOME: things we should keep and match with answers we will get from things they don't like
• What they love in GNOME: things that we must not change unless we want to have enemies
• What they would like to see in GNOME
• What they want to see improved

is IMHO a good way to go.

(Update: There is now a page for this at GnomeFeedback)

HOW to go to 3.0?

ThiloPfennig: These ideas are not based so much on what technology we have but more on what strategies might be handy: ThreePointZero seems to be a long way. Watching KDE 4.0 in trouble I would suggest the following strategy:

• Make a minimal working 3.0 desktop now. This means a core that starts up, maybe build this on Gtk 3 - give this project a cool name - why not keep "ProjectTopaz". The core technologies should be defined by handful of core GNOME developers.

• This initial release may base on existing technology but should not limit the developers with constraints that where decided for GNOME2. This should be a sandbox.
• Maybe distribute this desktop with a working virtual disk image that can be used to run it on something like VMware but is also usable as a development environment. So that people wont have to download and compile all kind of dependencies.
• Add a repository where people can submit packages that are made for exactly this environment and maybe provide the possibility to install them, directly from/on that image.
• From time to time make a new release and decide what becomes an official part of that environment or how things should be done.

I think that this strategy would allow:

• Developers to download the environment and start immediately with developing and testing
• Early adopters can download and look at it, even on a Windows machine or without having to set up the environment. So even users with no developer knowledge can give feedback from the first release.

• We always have a working environment that can be tested and is real - instead of theories or development based on what has been accomplished on GNOME 2. I am nit saying that one should dump that, but often it is important to let ideas flow instead of starting with HIG and standards. This environment in the beginning would not be something serious - but it hopefully will grow to something everybody likes to work on and play with. There even could be derivates of the environment to test how different approaches feel. So this would be an experience like this: Download, load image in virtual host machine, boot & start playing and/or developing. No download and compiling needed to start. Sure, if you want to be on the edge or want to test compiling you want latest sources and then this system should be able to provide that within the image itself. So this would be something like the live image project, but the goal would not be to show the latest stable GNOME but to give people a new territory to explore. This could potentially diminish the risk on building a platform that is mainly planned in theory and is only seen by very few eyes. So it would be something similar to ["Garnome] I think.