Elementary Prefs

So, the work on Elementary, Enlightenment project’s toolkit, kept going this year. Last I blogged here, I was on my task of rewriting the entire widget set as to factorize common widget patterns in classes and create a widget tree.

So, EFL 1.7 release came and just 2 or 3 widgets didn’t make it to the conversion, up to that time. No big deal, because:

  • This next release is going to be much more awesome, because of the tons of new features (and bug corrections) coming in.
  • People just changed the inheritance infrastructure out there in Elementary.

Yep. They didn’t change the architecture/pattern decisions I made, they just exchanged the classes infrastructure from Evas Smart Objects to Eo — a new library (yep, they keep growing forever) implementing an object system. I’ll leave to that library authors a better post about the matter. This was just a background on what happened since my last post, but let’s talk about a new feature, in Elementary, I was involved with after that — Elementary Prefs.

Prefs is a new widget, along with its infrastructure, providing a mechanism to store and access configuration data, with that access being (if the user wants) in a graphical way. Yep, this is like Android Preferences, but in a EFL way :)

We designed an Edje-like (EDC-like) declarative language to describe the configuration data to be stored (and retrieved). Its composed by data items, each bound to some type. Items are grouped in pages, that can group other pages themselves. We called these files EPC (Elementary Prefs Data Collections), since they can store one or more pages of items. Here is a valid EPC file:


collection
{
   page
   {
      name: "main";
      version: 1;
      title: "Preferences Widget";
      subtitle: "Test Application";
      widget: "elm/vertical_box";

      items {
         item {
            name: "age";
            type: INT;
            label: "Your age:";
            editable: 1;

            int {
               default: 18;
               min: 0;
               max: 150;
            }
         }

         item {
            name: "save";
            type: SAVE;
            label: "Save";
         }

         item {
            name: "reset";
            type: RESET;
            label: "Reset";
         }

         item {
            name: "subp1";
            type: PAGE;
            label: "Sub Page 1";
            source: "subp";
         }

         item {
            name: "subp2";
            type: PAGE;
            label: "Sub Page 2";
            source: "subp";
         }
      }
   }

   page {
      name: "subp";
      widget: "elm/vertical_frame";

      items {
         item {
            name: "subint1";
            label: "Sub Int 1";
            type: INT;

            int {
               min: 0;
               max: 100;
            }
         }

         item {
            name: "subint2";
            label: "Sub Int 2";
            type: INT;

            int {
               min: 0;
               max: 100;
            }
         }

         item {
            name: "subsubpage";
            type: PAGE;
            label: "A Sub Sub Page";
            source: "inner";
         }
      }
   }

   page {
      name: "inner";
      widget: "elm/horizontal_box";

      items {
         item {
            name: "subfloat1";
            label: "A Sub Float 1";
            type: FLOAT;

            float {
               min: -10;
               max: 10;
            }
         }

         item {
            name: "subfloat2";
            label: "A Sub Float 2";
            type: FLOAT;

            float {
               min: -10;
               max: 10;
            }
         }
      }
   }
}

Here we declare 3 pages of data items. Note that we nest them inside each other with the SOURCE-typed item. It happens that “main” will be chosen as the parent page, and because it sources “subp” twice, we’ll see its items replicated twice on the UI counterpart of this prefs declaration. Now what would that be?

Prefs items are bound to Elementary widgets, when “realized”. We have two entities dealing with prefs data — the prefs widget, which displays that data in a visual form, and the prefs_data handle, used to save and restore back values of prefs items set by an user.

Here’s the common usage:


prefs_data =
  elm_prefs_data_new("./preferences.cfg", "main",
                     EET_FILE_MODE_READ_WRITE);

elm_prefs_file_set(prefs, "./preferences.epb",
                   "main");
elm_prefs_data_set(prefs, prefs_data);

The .epb file is a binary form of an EPC one (just like the one seen above), which we get by using the elm_prefs_cc compiler on it. This is meant to act as “system” preferences — shared by all users.

The .cfg one, on its turn, is also a binary file with prefs data. It will store values for each item of the .epb one, but just the values (no meta-data, like minimum value allowed and such). This is meant to be user preferences on this data set, i.e., values specific to the user.

In short, the former gives life to a prefs widget, which is visual, and the latter loads in it the user values back (saving them back too). For instance, each realization of the “subp” page in this collection will have its values saved separately in the .cfg file.

A screenshot of that file, when live on a prefs widget, would look just like this:

Elementary Prefs Widget

Elementary Prefs Widget

Note that most of the values have been played with in the UI, making them different from the defaults, declared in the .epb file.

As you can see, items are bound to Elementary widgets, and one can even choose widgets to represent items other than the defaults (look at the choices for pages, for example). Elementary now ships with a set of available widgets for each item type, but one can also extend these sets via Elementary modules, with the prefs signature. This is a more advanced usage, in the future I can talk more about this.

So, this is it. Expect it to hit your homes soon, in Elementary’s next release, and enjoy it (right now, if you dare to build from unstable trees).

This was a team work by Murilo Belluzzo, Ricardo de Almeida and yours truly. Gustavo Barbieri was also of key importance, coming up with most of the design.

New widgets hierarchy on Elementary

It’s been a while since I last posted here, but my work with and for the EFL (Enlightenment Foundation Libraries) has not stopped at all during this time!

The EFL have had a lot more momentum these days, since Tizen 1.0 was launched, having these libraries as important building blocks of the whole architecture of this system.

My current work has been on an important part of that stack — the native widgets library. Note that despite Tizen 1.0 being all about web apps, future releases will open up for native applications, as it was announced at the last Tizen Developer Conference, which took place at San Francisco, California.

I had the chance to attend to this Tizen conference myself, thanks to my employer ProFUSION Embedded Systems. In our stand, people were able to know our services and see, live, lots of demonstrations of native Tizen applications with rich UIs. The beauty of those UIs were made possible in great part by the use of Elementary.

Elementary is a nice widget set library, which grew fast to the current state where we got lots of widgets and nice UI-infrastructure tools. You can have an idea of the library by looking at its documentation web page.

One of the drawbacks of Elementary, because it grew that fast, is that it had no notion of widget inheritance and code reuse on the widgets base — all of them where flat, inheriting from a same internal “widget” class.

My current work has been to rework all of Elementary internals, so that we create an intelligent widget inheritance schema. I had to analyse the purpose and behavior of each widget in order to categorize them and come up with class patterns.

With that, we aim to gain a lot of code reuse and ease of maintainability. Besides, we can use commonly namespaced API calls to act on widgets belonging to a same class. What we had previously was a messy “hooks” system, in which the developer of a widget had to hook-up the widget to whichever feature it would support, and all the features were exposed and accessed in the API via general elm_object_<feature>() calls. Those would work on widgets that supported them and fail silently on the others. Now we’ll be much cleaner on what each widget supports, in syntax too.

In a not distant future, we’ll have a definitive way (present on Elementary’s API) to extend and create widgets by Elementary users, at run time. My work already provides that, but the API on creating new widgets is still subject to changes — consider it unstable.

The current state of my work on that hierarchy can be seen on the following picture:

I’ve been working hard to have all of the missing widgets (which are few) on this picture too. If you have any suggestions or doubts on this work, just ping me at freenode (“glima”) or email me. I hope you all enjoy the fruits of it :)

Finally, I must say this work on Elementary is being sponsored by Samsung Electronics. Thank you for your great effort on Linux and Tizen :)

Emacs-uncrustify updates

Emacs-uncrustify emacs extension had some small but cool contributions by Gordon Read (thanks, man!).

It has now a customization group with variables holding:

  • path to uncrustify’s configuration file
  • arguments to be passed to uncrustify
  • boolean flaging if uncrustify should be applyed on a buffer on save

We also have two different functions, now. The uncrustify one does the same — uncrustifies a region. There’s also uncrustify-buffer, now, as a shortcut for applying it to the whole buffer.

Finally, a c-mode-common-hook was added, which will apply uncrustify on the buffer if and only if that third variable is set.

Enjoy.

Enlightenment Project’s Coding Style or “If you can’t beat ‘em, join ‘em”

This is a quick post for all of you Enlightenment developers and users (the latter also willing to adhere to that weird coding style). The named coding style, which seems to historically have come from Rasterman’s text editor, Jed, has been recently been called for a standardization/modification by means of an uncrustify configuration file.

While the file itself is still not perfect (there are “indentation bugs” yet), I wanted to have my editor — Emacs — to help me to adapt to that thing. So, I present you with a crude first attempt at it: http://github.com/glima/Emacs-uncrustify. Patches are obviously welcome.

By the way, exciting news are emerging from E-land, so stay tuned for hot hot new stuff, soon.

Editje: Edje GUI creation for the masses

As some people might already know, Profusion has been working on a new Edje editor, intended to replace the one there was on Enlightenment’s subversion repository. I’m now participating more actively in its development and, besides that, I did help with an early version of its user manual.

It will be fixed/revamped incrementally, so that even at development stage we can have users able to do their GUI creation jobs done with it.

Stay tuned for more news on EFL applications development infrastructure soon.

The Enlightenment Foundation Libraries: A Big Picture

As part of my job activities back in August 2009, I wrote an introductory document on the Enlightenment Foundation Libraries as a client request. It is now being publicly released, hosted at Enlightenment Project’s subversion repository.

You can find a rendered version here, too, but I can’t promise how often it is going to be updated. The idea is have this document accessible by Enlightenment project’s website both in PDF and HTML formats. Ideally, both forms would be updated by a cron job or something. We’ll work on that soon.

Feel free to contribute to it, if you wish (license is Creative Commons Attribution-Share Alike 3.0) and, of course, to read it. This is one more step into making the EFL more accessible and recognized worldwide by GUI application developers.

Memphis

Gustavo has already announced it, but here I come with just a few more words about it: Profusion has been working on a multimedia platform over Canola2, intended for in-car entertainment. After playing around with Canola, itself, a time ago, it has also been fun to work with this adaptation/expansion too!

I’ve managed to learn edje more and to grasp its full theming potencial. It rocks! We have architectural improvements on Canola which can be upstreamed, not far from now, I guess. One of the coolest additions was the total replacement of its thumbnailer with Profusion’s own one: Ethumb. This is a library which will soon be officially announced (it is already in Enlightenment’s code repository, but we would like to complete some small TODOs befoure going into 1.0). Besides many other things you can get with this (highly optimized) lib there are thumbnails with edje (objects) overlay borders and animated thumbnails of video files :).

Here is one of the demo presentation recordings.

Habemus Canola

Following Etrunko, who was the most rushed :P, I must announce that Canola 2, a media player for the Nokia tablets (but not restricted to them!), was set free! It is now available under GPLv3 and its code can be reached here. There you’ll find some instructions on how to build it, made by Etrunko.

I must only warn some of you that, for reasons already raised by Etrunko there, to this date there seems to be issues regarding some of the EFL python bindings. You are encouraged to wait a little bit, until they are fixed, help to fix them or try to stick to a revision older them Enlightenment repo’s HEAD (can’t say which will work). Profusion is also going to post instructions on how to build it, it won’t take long.

Another important thing is that Google Summer of Code 2009 did accept Maemo as one of its organizations. There are project ideas on Canola 2 plugins and I have applied as a mentor to one of them. I (glima) would joyfully embrace any plugin idea on Canola, but I’m specially interested on musical stuff (blip.fm anyone, now that last.fm has lost most of it charm?) :).

Finally, we hope you all enjoy hacking on Canola 2, which is a great piece of software!

ps.: Besides the title, no relation to catholicism (and no puns, either :P) intended!

Canola 2: one more release

So, as most of you Maemo users and developers must have seen, another release of Canola 2 is out in the extras-devel repository, which was called beta11. It’s been fun to work on it! It is, for sure, one of the greatest media players out there. Soon you’ll also have the pleasure of contributing to the project, the source code release is approaching (we all hope, hehe).

All in all it’s been very exciting to work here, at Profusion. The whole team is too cool and very skilled. So, I finish this quick post, while listening to Johnny Cash on Canola, promising new cool stuff is coming out from Profusion soon, stay tuned. :)