Skip navigation

After reading this:

I just wrote down some of my thoughts.


Although I do not wish to speak for Johannes, when developers are talking about libraries and in *that* context speak of users they usually mean other developers, not end users. The *user* of a library is an API-consumer, ie. another dev/project which will be using the functionality of the new API. Any time a new version of a library comes out which significantly changes it’s API each and every dev/project making use of this library has to rewrite their code to adapt to the changes. A lot of what was in GNOME prior to GTK+-2.0 took a long time to get ported to the 2.0 API, some code never did. New features which are appealing, offering concrete benefits to the *users* of the API, ease the transition, make it easier to justify the time and labor.Ā  If the new features trigger the “oh now I could finally do X with my app, which I couldn’t do before without great effort” then people rally around the new version and are want to rapidly port their software-this translates to concrete benefits for us end users-our applications make use of the newest features present in the API.

Personally I hope the devs take their time when it comes to GTk+-3.0. With time and patience 3.0 could be really amazing. Heres is a couple of things I would like to see:
1) Prior to 3.0 release their should be 100% coverage of the new API in all of the GTK bindings (Python, Ruby, Java, etc.)
2) Vala should reach 1.0 with complete stable bindings for GNOME platform-make sure Adjunta is ready to be *the* IDE for new GNOME apps using Vala.
3) Finish gobject-introspection, GTK bindings should autogenerated with each iteration of the new API-no more pygtk <=2.12, rubygtk >=2.14 etc.
4) finish the transition of GTK to Cairo, give our new desktops resolution independence.
5) get the mono/GTK# guys to sync with the new API.
6) document, document, document

If the time was taken to ensure the completion of these things prior to releasing 3.0- a) there would be enough time to smoothly integrate some significant chunk of Clutter into GTK proper b) devs would have a really mature, well documented and easy platform to create GNOME-3.0. If the bar is not set high many of the things listed here will be pushed to the side and get side-lined in the lure of playing with new tech, recreating much of the malaise currently existing. And I still wonder if Clutter will ever offer what a GTK-evas would(there is already a QT-evas port).

Further off I wonder if Tamarin/tracemonkey could provide GNOME with a way to offer javascript as *the* scripting language of the GNOME desktop(ie. create javascript D-Bus bindings, ensure that all GNOME apps expose their functionality via D-BUS and provide a nice jitting sandboxed environment to give end users a powerful scripting language to really take control of their desktop.


I would love to see something like this in a future version of GNOME. A couple of points I see:
1) object persistence- If I plug in a USB stick HAL/gnome-volume-mount should assign a persistent name to that USB stick. When I move the icon on my desktop for it, the next time I insert that USB stick it’s icon should appear exactly where I last placed it’s icon, and it’s name should be persisent- not disk/disk-/disk-2 depending on if it’s sunday, raining, or the wind is blowing.
2) a region of the desktop could be reserved for newly created/downloaded documents. But then again we have directories for this kind of organization. I personally would prefer to have the virtual desktops functionally utilized for this purpose-ie. each virtual desktop can have it’s own background and it’s own regions and allow users to configure which regions and which desktops are used for displaying which objects. Some regions could be defined to be present on all desktops, others for specific ones. Maybe something along the lines asiego talked about here could be inspirational: are all tech’s which lead in the direction of contextualization- “presence”)
3. Perhaps some of these regions could be embedded Nautilus windows( I use devilspie to create windowless embedded gnome-terminals on my desktop). If Nautilus was embedded in a region of the desktop without(hidden-accessible via key combo) menus and without window borders but with a scrollbar these regions could correspond to actual directories.
4. What I really would love would be a region for previewing files: ie. drag a file onto the region and preview the file there- drop a PDF there and let Evince show the contents of the PDF(without opening an Evince window)., drop a song there and have Totem play the file(without opening a Totem window), drag a DOC file there and let Abiword display it’s contents(again without opening Abiword)- expose a tiny subset of functionality-it 2 buttons appear above the displayed DOC file- Print and Edit, or for the song, Add to Playlist, or for the PDF simply Print. Can you tell how much I miss bonobo šŸ˜‰

Keep up the good work-sorry if this is too long šŸ˜‰


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: