And what about having 3D widgets? For sure, it would be a nightmare to design them.

Currently, the focus is that the developer chooses the actual user-interface. We gain consistency using conventions and the HIG. When we update these conventions we have to recreate the interfaces. But even as of yet the consistency isn’t anywhere near perfect. Preferences are not always found at the same place, or even using the same name. Toolbars are not always located at the same place. Confirmation questions are not always asked for the same stuff and handled in the same way. The list goes on and on. Seconldy its a burden on the programmer, because they need to implement the HIG over and over again for each APP. A lot of duplicated work goes into this.

Why not define a completely new API based upon SEMANTIC interfaces. Let a programmer describe ‘what’ the type of interaction would be, instead of defining ‘how’ the interaction should take place. So instead of talking about Windows, Buttons, Grids talk about Dialogs, Actions, Browsers, Tasks, Forms, Questions, etc..

At first this API would translate the Semantic UI defintion of a program based on HIG using the normal GTK+ toolkit. Lets call this higher-level library GSI (gnome-semantic-interface). So it would work like this:

Program -> GSI -> GTK+

Example program: Rhythmbox
Rhythmbox defines a ‘browser’ that selects a current ‘playlist’ which selects a current ‘song’. The GSI knows not about playlists, nor songs. But it knows about Browsers (tree-based selection) and Lists. The programmer would then define actions that can be done with a browser-node (a media-source in this case), a list-node (the play-list in this case).

These actions also have some sort of priority. Based on all this information the GSI creates a user-interface, with high-priority actions as buttons, lower priority actions as right-click options offering all the options as menu-options as well in a structured way. The program throws events of different types. Some are informational messages, some are progress-related, etc. The GSI decides what to put in the status bar, what to popup with a notification message and what to tell the user using a modal message-box.

At first we should just try to get as close as possible with the current gnome-desktop. However, people can then also experiment by creating their own GSI engine implementing the same API. This way they test HIG-improvements. They want single-window for every task, they can create that. They want big monolithic applications, they can create that. Not just for one app, but for the whole desktop.

There could also be a GSI that creates a native windows or qt app using conventions found in their environments. GNOME isn’t about GTK+ anymore, its about HIG. That its strength. Unfortunately, we put all the burden on the programmer.

This would also help a lot for making a gnome desktop work with accesibility or on a mobile-platform where there is less space. Currently we need to redesign the interface of programs to work with this.

Off course I understand, that it won’t be easy to come up with a good semantic API that really does cover most use-cases (if not all). Do we want to abstract stuff like undo&redo? typical file-operations such as open/save/close/exit? stuff like help&about? typical game stuff (start game, exit, highscores, etc.)?

At least currently I think its best if it only deals with the layout though. It should offer all these typical use-cases of interfaces, but not implement except creating a default UI and sending/receiving semantic events about it. So programs might define they want to use the default file-operations, and receive events about them, but the program itself should still take of opening, saving and closing the file.

Then, even if we are able to define an API, there is still the implementation issue. Is it a library like implementation, or a server-like implementation using DBUS-messaging? Or perhaps have the semantic ui in some sort of XML file, that you can just load into a program? I would actually vote for the DBus type of communication because its so programming-language neutral. But I can imagine some issues with it.

All right, that was a long rant. I hope i did not bore you all But this has been playing in my head for some time now.

Its the bazaar. He is giving it a try. If its a good improvement, it will be adopted. If not, then it will stay what it was, an attempt.

Secondly, lack of experience, can also help solve the tunnel-vision syndrome commonly found in API’s created by experienced users. Good programming practices change, use-cases evolve and priorities may switch. Too much familiarity with a subject is not always a good thing. For each design-mistake an experienced developer will not make, there is a design-mistake he will copy.

So perhaps he can create a good start. Then an experienced developer comes along and sanitizes it.

At least give him a chance. In the worst case scenario, he just learns a lot. In the best case, we have a new and improved GTK toolkit.

I have had almost _exactly_ the same idea in my mind for a while. It seems to me that graphical toolkits still haven’t experienced the presentation separated from content that CSS brought to HTML. When people write modern websites they describe the content using the right semantics rather than worry about presentation. Presentation (and more importantly – _changing_ presentation) is then a formality.

I kind of like: libhig

However it would happen, I really really like this idea.

I’m glad to hear i’m not the only one

But I would like to emphasize something. I am not just talking about layout. I’m talking about behaviour as well.

CSS is not the best example because of this. CSS doesn’t control how the URL is formed, nor wether to just display icons, a list or grid of patterns. It doesn’t control any part of the behaviour (client-side or server-side). It only controls the visual aspects of it.

This is also why I think it has never been done. The only exception I can think of is zenith, but it deals with the simpelest types of interface: dialogs. But zenith dialogs can be terminal-gui, command-line and GTK.

It is going to be a lot harder to do the same for the type of interfaces found on the gnome-desktop. Esspecially if it should be flexible enough to create a consistent and useable terminal and voice-controlled interface as well. How do we get the rhythmbox-gnome-interface and an equally usable command-line interface from the same semantic definition?

I’m not even worried about the browser-type-of-programs (webbrowser, filebrowser, musicbrowser, photobrowser, etc.). But what about graphical programs like the GIMP? Or music creating tools like ‘Jokosher’? Or an spreadsheet? Hell, what about the calculator? Its going to be difficult to come up with a semantic api that actually creates the calculator interface we are all used to. On the other hand, it should be general enough that it doesn’t require a use-case for each type of application that exists out there, or it would not really serve a purpose anymore.

That said, I think having this engineered by an inexperienced summer student is absurd. We should have our very best people on it! Let the summer student take over the current version maintenance tasks, freeing up the maintainers to experiment.