Category: gnome

GNOME Journal submission deadline

The GNOME Journal is preparing for another great new edition!

Join our We-tell-the-world-about-GNOME-and-it-rocks club, and find the
love of your life! The deadline for submitting articles is April, the 1st.

The next edition is going to appear on April, the 15th 2007. General
information about the GNOME Journal, the submission guidelines, an other stuff is available in the wiki:

   http://live.gnome.org/GnomeJournal

Don’t forget to add you article to our article submission queue! Do
this within the next 24 hours and win tickets to the moon. :-)

The GNOME Journal, March Edition

The latest issue of the GNOME Journal has just been published! It features an introduction to GTK+ cross-platform application development, an interview with Jakub Steiner and Andreas Nilsson about the Tango Project, the first article of a series about free desktop companies, and a letter from the editor. Writers in this edition are John D. Ramsdell, Alexandre Prokoudine, Sri Ramkrishna, and Jim Hodapp, respectively.

Read now: http://www.gnomejournal.org

Hildon Desktop + FreeDesktop.Org

We’ve been trying to put some effort on making Hildon Desktop more compliant with FreeDesktop.Org standards. We have some nice news on this direction.

Desktop Notifications

I added a service that implements the Desktop Notifications draft standard. It’s not complete yet, I still need do some changes on one of our widgets, but it’s working like a charm. Also, support for multiple notifications at the same time is pending. In practice, this means that applications using libnotify (or any other compliant client library) will have their notifications shown on Hildon Desktop! Here is the result:


Hildon Desktop showing a notification using libnotify.

Notification area (aka system tray)

Moises rocked our world by adding support for system tray standard in Statusbar. This means that if you use GtkIconStatus (or any other compliant implementation of the client-side) it will appear in Statusbar. Of course, still the usual Statusbar plugins can be loaded in Statusbar too. There are some pending issues with the theming of systray items (as you can see in the screenshot) but we expect to have it fixed soon. Here is a (mandatory) screenshot of Hildon Desktop running inside Scratchbox:


Statubar showing Gossip and Network Manager systray icons.

Update: Moises has just fixed the theming problem. Yay!

Hildon Desktop Scalability

So, as I posted some days ago, one of our goals for the future Hildon Desktop releases is scalability. We want to be able to easily configure/adapt the desktop to different displays with different resolutions. As a proof of concept, I made some very small code changes and some adaptations on the development theme (aka Plankton) – created by MDK and tigert – and made Hildon Desktop usable on a 1024×768 resolution on my laptop. It would rock even more if I had a tablet PC here to use finger for interaction. Here’s the result:


Hildon Desktop running on a 1024×768 resolution.

Error/Warning UI in Eog-Ng

Currently, EOG is really crappy on reporting errors/warnings to the user. Basicaly, you only get feedback about errors on image loading, nothing else. Also, it uses dialogs for this which is kind of invasive and specially annoying on a collection-based UI application like EOG. I really like the UI aproach adopted by gedit with this cute yellow message area. So, I borrowed gedit’s code to use the same aproach in eog-ng. If something goes wrong with the image loading, you can easily browse other images from the same directory without needing to close EOG. Here’s the result:


New UI for errors/warnings in EOG.

I still need to add the code for different kinds of error/warnings for cases like opening a directory with no images, opening unrecognized formats, not found files, etc. This will be piece of cake with the new code base though.

—-

Claudio pointed me to this blog post from this italian guy who seems to be really excited about eog-ng. Good to know that users are enjoying the EOG development news. :-)

—-

Update: don’t worry about the odd “Cancel” button. I’ll fix this ASAP. :-)

EOG statubar

I heard very often that there are some EXIF info that users are really interest in having easy/quick access to. EXIF presentation was really improved as I already reported before. EOG’s statusbar could be used to show really common EXIF values like date and exposure values. I wanted to do this in a way that not much noise is added to statubar. Here’s the result:


Statubar showing most common EXIF info: date and exposure values.

I haven’t commited this yet because I’d like to get some feedback first. Some additional related issues:

  • Is there a way to show exposure values in a non-photographer-friendly way? I’m thinking in adding a GConf key to optionally enable something like “exposure info in statubar”. End-users would free from those evil info then.
  • Should the time reside on statusbar?
  • Show simplified date/time (“23/12/2007, 12:48”) or a full descriptive one (“23 December 2007, 12:48”)?
  • What do you think is missing in statusbar?


Comments?

Selection bytes

Some weeks ago, I posted about how could it would be to have the GtkIconView selection looking like this. So, the first step was done: I cooked a patch. I guess when/if the patch is integrated into GTK (I’m still waiting for the feedback from the maintainers), the next step will be to do some rocking theming work in GtkIconView selection. Comments on this subject should go on bug #382544.


GtkIconView selection: first step for a potential selection eye-candiness.

Update 1: don’t pay too much atention to this checkbox in this screenshot. This is just part of GtkIconView test program with some weird layouts.
Update 2: for those interested, the rounded borders will come the theme engine, not in GTK itself.

Hildon UI Development News

As you probably (don’t) know, we, from the Hildon UI Framework team, have been working hard in the new code for the next releases of Maemo (The “don’t” is because even though the development happens in a public repository, sometimes we’re not very good in communicating about what we’re doing). Now, the heavy development work of maemo-af-desktop is taking place in a separate branch called hildon-desktop (the new name of maemo-af-desktop).

Our main goals for the next releases is flexibility, scalability, maintainability and developer-friendliness. The code of “maemo-af-desktop” received a lot of improvements for the N800 and Bora release (As you with a N800 in hands have probably noticed!) but still it has some serious problems. The layout of the UI is hardcoded (is was done for a specific display with specific resolution) and the plugin infrastructure is fragmented and (kind of) duplicated for each UI component (Home, Statusbar and Tasknavigator). Also, the plugin API is not very developer-friendly because it doesn’t take full advantage of the GNOME Platform knowlegde that developers interested in Maemo already have (this is my personal opinion). So, what are we doing to target those issues? Let’s see!

Separating the generic parts from the specific ones

We detached the “generic” parts of the UI into a library called libhildondesktop. This lib has things like different kinds of panels, a generic widget for Home, and interfaces for different kinds of desktop items that will reside in the panels and Home. The window management code has been put into a library called libhildonwm which is intented for very specific cases where the developer need some control over the windows behavior. For example, libhildonwm is used by application switcher to show the list of active windows in the Task Navigator panel.

So, what does this mean? This means that out future UI will be just a specific application of libhildondesktop and libhildonwm for a specific device. In hildon-desktop branch, we’re about to finish the UI (based on libhildondesktop and libhildowm, of course) that reproduces exactly what you have in N800. Also, it’s good to remark that this aproach makes it easier/faster to prototype different UIs and increase the hacking possibilities for the UI! Yay!

New plugin system

We now have a common plugin system for all UI components. The new plugin system is based on plugin loaders. Each type of plugin loader is reponsible for loading desktop items from different “sources”. For example, we have a plugin loader that loads (Task Navigator, Statubar and Home) plugins written with the current plugin API (To keep backwards compatibility). However, we’ll have a new GTypeModule-based API for developing desktop plugins so obviously we have a plugin loader for this kind of plugin too. This aproach give us flexibility enough to even have plugins written in different programming languages. We already have a Python plugin loader and the bindings for libhildondesktop (libhildonwm bindings yet to come).


Task List plugin written in Python running in hildon-desktop

Plugin loaders can be dynamically loaded without needing to rebuild hildon-desktop. We did this way because in the case of plugin loaders for plugins written in programming languages other than C, we cannot ensure that the runtime requirements will be available in the device by default. For example, the Python loader resides in a different module together with the libhildondesktop bindings so that in the future, if you want to add support for Python desktop plugins, you just need to install the bindings, the Python loader and Python debian packages. That’s it!

The hildon-desktop Python support code is available, of course. We’ve written some really dummy example plugins with the new API and Python API just to give a taste of what is coming.

Contribute!

Any suggestions, comments, ideas, construtive critics and (specially!) patches are welcome. Get the code from Maemo repository and play, brake, adapt, change, etc. If you want to use the latest pre-built packages, you can always use Sardine.

Important note!

This is unstable-under-heavy-development code. You should not rely on this code for anything. At this moment, hildon-desktop should only be used by courageous developers who want to contribute/use the very latest UI framework stuff.

Attribution-NonCommercial 3.0
This work is licensed under a Attribution-NonCommercial 3.0.