Hello
My name is Nickolay Vladimirovich Shmyrev
Email: nshmyrev at yandex dot ru
Principles of GNOME development
I believe that wiki discussion is more productive in getting correct result, because it allows you to concentrace to statements, so here is the text.
It seems that everybody around wants to have a perfect desktop but we still don't know how can we create one. Current effort certainly fails for many reasons - not enough time, not enough planning, not enough QA, not enough agreement, not perfect technology.
The goal is simple - we must have rich and high quality software in a limited period of time.
- We must have planning policy. The feature set for end-users product should be defined in the early development stage. Please not that it should be complete definition, not the current one.
- We must have perfect technology. We do need high-level language, modern way of doing things. We certainly need a metadata system, we certainly need a collaboration system, we need a perfect configuration system (state saving is not about gconf and gnome session, it should be done through serialization). We must have testing framework and performance monitoring framework.
- We should only target our domain - perfect desktop, no need to worry about cross-platform applications. We don't want to write Windows apps and spend our time for cross-platorm layers. Currently, cross platform efforts fail - gtk doesn't work on windows because nobody actually trying it with serious apps, gtk doesn't work on solaris because of 8-bit problems, gtk doesn't work on embedded because of cairo, gtk doesn't work on fb because it's just unfinished, gtk doesn't work on Mac for the same reason. Certainly, Linux kernel and glibc/Xlib aren't perfect, we'll probably replace them in the future. But currently it's fine to depend on glibc/Xlib only. We had bad experience with freedesktop libraries, just because they are failed to provide enough quality, that's why we should drop them. Without underlying stack stability we won't get our goals.
- We must have more polices and guidelines HIG is perfect examle but we need testing policy, coding policy, documentation policy (no change is accepted without documentation), translation policy.
Comments. Policies restricts development and usually developer is not so good in writing documentation and design. Probably we should work in team.
Behaviour guideline
Although HIG nicely specifies, how GNOME application should look, it's says nothing about how application should behave. It's strange that our usability guys don't take such important thing into account. Even small difference in program execution makes user very unhappy. For example, Open dialog saves location in one applications but makes me browse to the same directory every time in another. The main problem we are talking in that section is:
Programs should behave consistently, not only look consistently
And few consequences
It's impossible to get consistent behaviour without sharing codebase. One can make application written in Qt or with Mozilla suite look like Gtk application, but user easily see the difference way such applications do things. Once you open settings dialog, mirage of consistensy dissapear. HIG should not be recomendations everyone is trying to follow, but documentation to hardcoded rules, that anyone using library is automatically following.
Integration with other toolkits doesn't have any sense, as supporting software on different platform. If application uses another codebase it would behave differently. Take, for example, gecko or gtk-mozembedd applications. They all have problems with keyboard focus and accessibility. It's impossible to make them work like GNOME user expected. Even if no, it's impossible to maintain such consistensy every time something changes in gtk.
Set of applications will never be a consistent desktop. We don't need applications to handle mp3 but we need desktop component to play music. For example, there is a number of music players, but none of them is integrated into nautilus. There are lot's of applications in gnomefiles.org, but very few of them are fully gnome-compiliant. Most of them just use gtk2, you know, how they look and how they are configured. Gnomefiles.org is very good and useful site, lots of thanks for Euginea for doing it, but we probably need gnomeparts.org. Don't start to develop new application, look at desktop and improve it's components instead.
To help with it, let me give overview of GNOME development in common and give some proposal for inclusion into HIG
Objects and tasks
Modern systems are trying to live in object world, althogh there are some disadvantages of such view on life, this way is very promising. So let's state:
User should live in world of objects and tasks
It's quite clear how we can do it in object-oriented program, but not so clear, how make user feel like this. Years of development in unix environment make user think about files and commands. It's time to break such world presentations. Thinking about desktop we should consider tasks user needs to perform and objects he can work on. That should be the main idea of any program.
Partially, such way is stated in nautilus with new spatial behaviour. But it raised some problems, since others still lives on older world of files. First you should do is to think, does your application let user think about data as an object or does it perform some task. If not, you should rethink it or fix some bugs. Here is small checklist for applications that works with data:
- Does if fully save state (If user closes window and then opens it again he should see the same picture)
- Does it allow to revert changes.
- Does it provide data conversion to other object types
All we are going to do in the future is - provide user with world view where he can work on data as objects, convert them from one type to another, move and organize them. And perform every task he need, with ability to plan tasks, share tasks, remember last task and even revert task changes.
The very common objection is that the idea is clear but it hard to implement it, I think it's still possible.
Overview of GNOME development Problems
Development language
There are a number of languages you can develop GNOME with. There is C, c++, python, java, C# and a few not so widely used. Now almost every library has bindings, as the result there a number of problems with performing such a boring task on syncing them. It would be optimal to have _one_ high-level language such as C# or java and performance-critical code implemented in C. But it seems that mono guys are dropping C from their code (as with monodevelop 0.7), so it's questionable if it is possible to live so.
Number of problems we should solve here:
- Find language with high-level object capabilities like introspection and serialization and garbage collection
- Decrease number of cross-dependencies by resolving them in runtime (using IPC). In the begining that was the main idea, now it somehow dissappeared and we have 100 libraries with unclear dependencies. That's why I don't like DBUS, since it tries to expose implementation language details to IPC, instead of hiding them like CORBA. DBUS won't be able to solve hell with dependencies.
Build tools
Autotools and CVS is quite satisfactory. Following fashion shows one can consider SCons and subversion or even arch, but in general it's not needed.
Development environment
Most of developers are happy with gdb and emacs, but there is still need in testing and profiling and other tools. Also there is anjuta but I wonder if it's widely used by GNOME hackers.
Graphics library
There was gtk and libgnomeui. Now libgnomeui is gone and this have rised a number of problems. The most imprortant is that some UI requires high-level things, like vfs or configuration. It's impossible to reimplement them in low-level library. Either gtk should depend on vfs, gconf and so on or there should be libgnomeui. Otherwise, we'll have a lot of duplicated and confusing code like FileChooser (nautilus in miniature) and GtkBookmarks (what intgration are we talking about if it's just a file) or EggRecent (another file). So the problems of gtk are:
- It attempts to do high-level things without high-level libraries
- It needs more widgets like dock, toolbar editor and so on. There are a number of widgets in eel, libegg and other libraries. But it's really hard to include something new into gtk
- It becomes quite big (10 Mb)
Application interface building
There are some problems here. Originally, there is something now called libbonoboui, it's specifies application window look as tree of menus and embedded components. Now there are number of libraries and all of them provides way to construct interface. There is libglade (only static building, no runtime handling), GtkUIManager (runtime building, but only menus/toolbars no way to construct widgets) EggToolbar (Editable toolbar schemes) and libbonoboui (not so popular). Definitely, something goes wrong, you can see.
Multimeda
There is rhythmbox for playing music, quite nice application, but the problem is that it's not maintained since January 2005. Probably, it needs some fresh look. Others are muine, beep, but they are just players and aren't going to provide music framework.
IPC
There is dbus and libbonobo. I start with note that I don't like dbus. To my opinion, all they do is just reimplementing libbonobo once again. They already have python bindings with run-time introspection (like pyorbit) but bonobo still has better activation code (bonobo-activation query language and component specification is much more advanced). What bonobo needs is standard and usable interfaces and implementation of some CORBA services, like transactions one.
Database
We need fast common high-technology and lightweight user-running database. With it we can solve a number of problems like we have with GConf performance and rhythmdb and address-book and so on.
There is gnomedb project, althogh I don't know about plans of it's usage in desktop.
Configuration
We have GConf, it's pretty good, althogh it's performance optimizations made it a bit slow :). But in view of current goals there is need per-object configuration, and system-wide configuration, so there is definitely many ways of extension. Althogh I don't know if any patches would be successful.
Window manager
We need code for widgets grouping we need more advanced ways of widget placement. In would be just nice if we can drop ICCWM and use our own window management protocol to do cool things like applet placement or managing nautilus windows. But don't do anything in this area, your patch will be rejected with high probability.
Messaging
I wonder why mail and calendar is collected in the same application like evolution. Mail should be definitely part of gaim so as telephony. But calendar and tasks are part of productivity suite.
Also see: GnomeArchitecture/Overview
