1. Back to Origin - Being an Object Model Environment

Get sticked to an object oriented language, like, C++, Python, C# to the core. One that assembly really fast applications/binaries
Reimplement GLib with a strong object oriented paradigm in mind, all becomes objects, handlers and factories
Reimplement GTK+ with a strong object oriented paradigm in mind, all becomes objects, handlers and factories
- Delegates do GTK+ only the implementation of the widgets, event handling and so on
- Even the ones that Nautilus uses to render file icons, Evolution uses to render e-maisl, and gtkhtml to render HTML, Planner to rend Gantt graphics...
Implement an Object Model Environment, for GNOME:
- A collection of objects (like a GNOME fauna), handlers and factories wich in fact deals with GNOME look and feel, where GNOME standards arise
  - A GNOME Panel Object
  - A GNOME Desktop Object (detaching desktop handling from Nautilus)
  - A GNOME Applet Object (embedable on all sort of GNOME Objects)
  - A GNOME Object: keep a KISS object oriented paradigm for all pieces of GNOME
- Componentes like window manager handling, libnotify, dbus and so on, all with one planified (sort of wrapped) object oriented interface
  - Create a collection of objects that used together makes GNOME TOPAZ what it is
- Standardization of terms, methods names and variables names for all desktop, becoming more developer friendly
Strong maintenance of documentation: elaborate a policy that documentation are so important as good code, becoming more developr friendly
- New GNOME releases comes with a complete documentation revision
- End user documentation (last version refer GNOME 2.10, we are in 2.14)
- Adminitrator documentation (last version refer GNOME 2.6! We are in 2.14)
- Accessiblity documentation (last version refer GNOME 2.10, we are in 2.14)
- Developer documentation (it seems to be the same since 2.0, 2.2, 2.4 release!)
  - API guides
  - Tutorials
  - Code snippets (examples from real life) inside the documentation
- NOTE: better documentation policy is all great, but doesn't need Topaz to happen -- it should happen sooner! -- JoachimNoreiko
GNOME's web site revamp
- GNOME's web site lacks uniformity, organization and standards
- Elaborate a policy that the website MUST be update at each new release, with all new references
More to come later!

RuiMatos: I generally like these recomendations. Actually, at the danger of sounding like Steve Ballmer :-), I think GNOME could really use some developer oriented love to further spread its wings. GNOME needs to be more 'usable' for the average developer to boost contributions and independent/new applications. This should indeed be a focus for TOPAZ release. About the languages (and ripping the idea from Apple, who ripped it first from NeXT...) why not move to Objective-C instead? It is pretty much compatible with C and we have all the standard GNU tools to support it. I don't think C is much of an hindrance to GNOME though.

JohnNilsson: One way to be usable for developers is to design a highlevel programming layer for cut'n'paste development. Much like javascript did for the web. When features and experiments matures then would be the time to engineer it into a proper gnome component using some lower level development stack.

BobVanDam: This sounds very good, it raises some very important points. It would matter a lot when people can create more and better applications faster and more easy. Many of us do this in our spare time, and that time is very presious to us. I think that when it becomes easier for people to develop new applications, extensions and libraries the desktop will flurish alot better and faster. However, though i agree that a language like java, python or C# (i prefer C#) looks like it is the way to go.. i'm afraid it will rule out a lot of developers because of ethical/religous reasons. It will also not happen because you will have to change the complete architecture.. glib/gtk and other libs etc (for who needs to be created wrapper libraries as well). Other things then come into question like portabilaty etc.. Mono for example doesn't run well on non Windows/Linux systems. A rewrite like this is a hidious task that can take years to get to the level that we are now. In other words, using high level languages are good for the desktop, but to rely the entire framework upon it.. will hurts alot of toes. The way i see it, c/c++ with maybe python for the core, anything u want for the apps.

MichaelLawrence: Instead of trying to decide on X language or X, Y, and Z languages, perhaps a focus of Topaz should be achieving language independence, for both the apps and the core. This lets people choose the best tool for the job, and doesn't force relatively pointless and time-consuming reimplementation of existing components.

[UPDATED @ 18/07/2006] - Long text ahead. Take a cup of coffee.

RuiMatos, I don't know that much about Objective-C, I just saw some examples of code, never coded with it. But if that is the choice it is OK. What we must hurry to improve, IMHO, is the object oriented paradigm that is implemented by GDK/GTK+ and related base libraries. Give rid of those noisy use of type-cast macros, deprecated code and classes/widgets that GTK+ carries. We need a more clean implementation of the OO paradigm.

I'm don't selling that GTK+ is a mess (even believing that), but it is hard to stay close to its core. Take a look at GObject and the huge effort to implement a brand new class, or even a descendent one.

C++, C#, Objective-C, Python, and others, all have a native and standard method to do that. That would be a huge step forward. Make it easier to grab and extends GTK+ basic classes. We must run to make developing with the GNOME core libs far more easier. Otherwise, other spin out libs will arise and make standardization harder. That's why the hurry. In fact, the talks about that are arising, take a look at 2006-July Talks for a start point, I'll come back to this topic later.

So if I would have the power to do any choices about the directions to TOPAZ, those would be:

Reimplement Glib, Pango, ATK, GDK and GTK+ all with pure ANSI-C++, with no use of any other external dependencies (where possible, of course, but chase it as hard as we can). With that we close our base widget-toolkit, lets call it GTK3 (this is an herculean work);
- JohnNilsson: Why C++, how about D?
Definition of some official documentation system, like doxygen, within source code. Enforcing its use like law. No doc, no commits, no glory. With that we give to developers the minimum resources for adoption (current documentation are poor and/or obsolete);
Delegate to GNOME only the implementation of desktop classes, right on top of the GTK3 toolkit. No applications at all (like I said before). Defining what could be named a 'desktop-toolkit'. All with pure ANSI-C++ plus GTK3. Lets call it GNOME3;
Definition of the GNOME Projects'n'Apps, like Nautilus, Evolution, Gedit, GConf, Epiphany, Panel, Applets, NetworkManagement, and so on. All of them making use og GTK3, GNOME3 and ANSI-C++. So the GNOME Desktop would be defined by a set of the projects and apps, all of them making use of a new set of toolkits.

So, my point is, to remove from the core of the question the applications by them selves, and focus on a better development framework, a more powerful one, easily extensible, and a far better documented one. Application set are in essence a personal/distribution choice. There is no win-loose point in it. So, lets move downward, were the hard decisions lay.

With an easily extensible framework, a rich documented one, a standardized start point, develop new applications, and better ones, will become easier and less costly. It will be appealing for old and new developers. Developer appealing, that is one of the keywords.

Being developer appealing, we have more developers. Having mero developers, more are the chances that, among them, there are good ones. With good developers, we have better applications and more appeal to improve the framework. That's the virtuous circle that I see. A perpetuous one, I think.

The developer's website would have projects and apps' code snipets, all them explained, serving as a real world examples tutorial (tag-comment source code for automatic snipets extraction? -- flying...).

AndrewCoulam: Vala might be a good way to address this idea. Right now Vala compiles to C GObject as an intermediate language; so, the development would be in a higher level language but be available in the neutral and portable C version that everyone is used to. As Vala is very similar to C# and Java, you would get the advantages of a modern object-oriented, strong, statically typed language with features like exceptions and garbage collection. (Vala will have all these things, right?)

If you were to implement the next generation Gnome foundation libraries in Vala/Gobject, perhaps a first step would be to translate as best as possible the current generation libraries into Vala and then modify the libraries from there to make them more friendly. If valac compiles Vala into C, perhaps someone could reverse the process in something called c2vala. So, e.g., GLib2 --> c2vala --> GLib2.vala--> [refactor to fit the ideas expressed here] --> GLib3.vala --> valac--> GLib3.

CostinChirvasuta: I used to say C is good enough for anything, pretty much disliked C++ but now i finally found an OO language that is incredible. Smalltalk was one of the first and best OO programming languages. It was developed at Xerox PARC by some really smart people. After I started working with it i really wanted a compiled version of the language (not virtual machine based), maybe mixed with C. Then I found out it already existed NeXT (and then Apple ) knew what they were doing when they chose Objective C. Take a look at GNUStep. Maybe not the features and all that but the development model and application framework are really great. I'm not the first to say this but it would be great if GNUStep and GNOME merged