Shouldn’t we talk?

The number of GNOME-Platform-based user interfaces (or “Desktop environments” if you prefer) for embedded devices is growing. AFAIK, those are the guys in the field:


We have different focuses: OLPC (Sugar) on education, ACCESS on PDAs, Maemo (Hildon Desktop) on Internet Tablets and OpenMoko on cellphones. However, I’m sure we have a lot to share and learn with each other in terms of architecture, UI framework, plugin systems, standards, code, ideas, and so forth.

I saw that (probably) there will be some talks related to those projects in GUADEC. This means that we will all be at the same place, at the same time, It’s a good oportunity for us to get together and talk! So, what do you think?

Update 1: It seems that some very interesting discussion among OLPC, Maemo and OpenEmbedded guys already took place during Bossa Conference. Good to know we’re already talking. :-)
Update 2: Someone commented that I should add LiMo Foundation to the list. Does anyone know if there will be anyone from LiMo at GUADEC?

Google Summer of Code 2007


GNOME is participating in Summer of Code 2007. If you are a student and you want to apply, you can submit your project before March 24th. You can find some ideas for projects on our wiki.

If you want to help us on getting more student projects to GNOME, print the poster in your language and post it at universities of your city. Don’t forget to notify in the university advertisement page to avoid duplicate effort.

Maintainers, there’s still time to add some ideas to the game. Just add it to the “New/not-prioritized” section (see the instructions in the page). I’ve seen some nice potential SoC projects on your plans for 2.20. :-)

Big thanks to Máirín for the beautiful banner and poster!

GNOME 2.18 released!

Yes, Yes, exactly! GNOME 2.18 is released! It’s always nice to see such a nice result of hard work from so many people (have a look at the gnome-about dialog)! Congratulations to everyone who contributed in anyways to this beautiful release!

GNOME 2.18 is 100% translated to brazilian portuguese (2.14 and 2.16 had 98%)! A big thanks to the whole pt_BR team: Leonardo Fontenelle (pt_BR hero!), Og Maciel (pt_BR hero!), Guilherme Pastore, Raphael Higino, Washington Lins, Licio Fonseca, Alexandre de Menezes, Pedro de Medeiros, Afonso Celso Medina, João Bueno Calligaris, André Noel, Raul Pereira, Robson Negreiros, Everson Araujo, Vicente Aguiar, Vinicius Pinheiro, Amadeu Júnior, Lucas Veloso, Claudio André, Franz Gustav Niederheitmann, Luiz Fernando Armesto, Igor Soares, Jonh Wendell and Fábio Nogueira (Sorry if I forgot anyone). I love you guys!

I’m really excited about what’s coming for GNOME 2.20! Let’s start our hard (and super fun) work again! Go Go Go!

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

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?

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.