Category: Maemo

On the way to 0.5

It’s been a bit since my last post about siggy. But don’t worry. That only means that I’ve been working hard on it 😉

I’ve made a real lot of changes to the application since version 0.4.2. And I have some more in mind before releasing 0.5. But I wanted to give you an advance of what I’ve been doing and what I plan to do:

  • Things done:
    • Added some performance improvements here and there, mostly related to avoid unnecessary redraws, and modified the hiding of the dialogs. Maybe you have realized that the more expenses you had in a month, the more it took the new expense dialog to hide. That doesn’t happen anymore, and everything runs a bit faster.
    • Added a new feature to the summary section: Evolution. This option uses the expenses graph to show the evolution of your budget and expenses during a period of months. Is has a monthly and accumulated view as the normal graph. Now you can check during with months you spend more money! 😉
    • Source code restructured, making the appearance of the application totally independent of the rest of the code. Thanks to this, creating new views for the application for different platforms is really easy. This is something a normal user won’t notice but I needed it for other goals ;). Also, this was something almost mandatory for someone who likes designing as I do :).
    • Created a desktop version of the application. Yes, siggy now has a desktop version with a view adapted to the desktop environment 🙂
  • Things to do (in a not relevant order):
    • Create a database updater: I’m a slave of the database schema. I have some features in mind that would break the database compatibility with previous versions of the application. This is something I need to fix. I have in mind a program able to update the database schema and migrate existent data when upgrading to a new version.
    • Implement forecasts: I’d like to add the application the capability to tell you how are you going to finish the month according to your current expense rate. Something similar could be done with a period of months.
    • Remove the packaging stuff from the master branch and put it in a different one. Well, you know, code is code, and packaging is packaging 😛
    • Add an rpm packaging branch.
    • Implement the account password protection feature.
    • And last, but not least, create a MeeGo version of the application 🙂

What do you think? Have I been busy or not? 😉
The only bad new is that I’m not planning to create a new package and upload it to garage and those things yet. I’ll probably just create version 0.4.3 in the repository and wait until version 0.5 to create the new package.

Anyway, feel free to get the source code from gitorious and build it yourself. Just launch build.sh and it will create the package for your platform! 🙂

A camera using GDigicam and Qt

You may (or not 😉 ) know that GDigicam is an open source library used in Maemo 5 as a middleware betweeen the camera application and the GStreamer stuff. The goal of the library is to ease the development of camera style applications by hiding the low level stuff to the UI developers, and it allows different GStreamer pipelines to be used in the lower layers to achieve the camera funcionality. Currently the camerabin plugin is the fully supported one, and it’s also the one being used for the N900 camera.

I had the chance to collaborate in the development of the GDigicam library time ago, and it’s currently maintained by some of my colleagues at Igalia. One of them asked me some days ago about the possibility of using GDigicam together with Qt to develop a camera application. You know how this works… that seed was enough to awake my curiosity, so I started working on it 🙂

Some tests later, I’ve developed an experiment integrating both things. A Qt application that uses GDigicam to display a viewfinder in a Qt window, and to get pictures and show a preview of them. I must confess that I got really surprised because it was a really simple task. You can clone my personal repository (http://git.igalia.com/user/magomez/qtcamera.git) if you want to check the code. These are the steps I followed and the tricky parts of the code 🙂

First, extend the QWidget to create a CamWindow widget. In the CamWindow constructor, create the GDigicamManager, the GStreamer camerabin plugin, the GDigicamDescriptor and fill the bin capabilities (this is done in the setupCamerabin method). Connect the callbacks to the GDigicam desired signals and set the initial configuration. In the example, I used CamWindow’s static methods as callbacks of the GDigicam signals. This is fine as long as you don’t need the CamWindow instance. If you need it, then you’ll have to set it as the callback user_data parameter when connecting the signal (as in the preview signal case).

void CamWindow::setupGDigicam()
{
    GstElement *bin;
    GDigicamDescriptor *descriptor = NULL;

    /* create the GDigicamManager */
    manager = g_digicam_manager_new();
    colorkey = 0;

    /* create the bin */
    bin = g_digicam_camerabin_element_new ("v4l2camsrc",
                                           "dspmp4venc",
                                           "hantromp4mux",
                                           "pulsesrc",
                                           "nokiaaacenc",
                                           "jpegenc",
                                           NULL,
                                           "xvimagesink",
                                           &colorkey);

    /* create and fill the descriptor*/
    descriptor = g_digicam_camerabin_descriptor_new (bin);
    descriptor->max_zoom_macro_enabled = 6;
    descriptor->max_zoom_macro_disabled = 6;
    descriptor->max_digital_zoom = 6;


..... more descriptor capabilities stuff....


    /* set the bin and the descriptor to the manager */
    g_digicam_manager_set_gstreamer_bin (manager,
                                         bin,
                                         descriptor,
                                         NULL);

    /* connect to the manager's signals */
    g_signal_connect (manager, "pict-done",
                     (GCallback) captureDone,
                      NULL);
    g_signal_connect (manager, "capture-start",
                     (GCallback) captureStart,
                      NULL);
    g_signal_connect (manager, "capture-end",
                     (GCallback) captureEnd,
                      NULL);
    g_signal_connect (manager, "image-preview",
                     (GCallback) imagePreview,
                      this);

    /* set initial configuration */
    setOperationMode(G_DIGICAM_MODE_STILL);
    setResolution(G_DIGICAM_RESOLUTION_HIGH,
                  G_DIGICAM_ASPECTRATIO_16X9);
    setFlashMode(G_DIGICAM_FLASHMODE_AUTO);
    enablePreview(true);
}

I’ve created some private members in CamWindow to encapsulate the GDigicam function calls. They are used for initialization and also called through the options in the window menu (change resolution, play/stop bin) and when clicking the capture button. This is the one to set the resolution for example:

void CamWindow::setResolution(GDigicamResolution res,
                              GDigicamAspectratio ar)
{
    GDigicamCamerabinAspectRatioResolutionHelper *helper = NULL;

    helper = g_slice_new (GDigicamCamerabinAspectRatioResolutionHelper);
    helper->resolution = res;
    helper->aspect_ratio = ar;

    g_digicam_manager_set_aspect_ratio_resolution (manager,
                                                   helper->aspect_ratio,
                                                   helper->resolution,
                                                   NULL,
                                                   helper);

    g_slice_free (GDigicamCamerabinAspectRatioResolutionHelper, helper);
}

One of the capabilities of the camerabin is that through the use of a colorkey, it allows blending UI components over the video stream. To make this work, the background of the window where the video is put must be filled wit the colorley color (this color is provided when creating the camerabin element). This is why this is done in the paintEvent method of the window:

void CamWindow::paintEvent (QPaintEvent *)
{
    QPainter painter(this);
    QBrush brush;

    QColor color((colorkey & 0x00ff0000) >> 16,
                 (colorkey & 0x0000ff00) >> 8,
                  colorkey & 0x000000ff);

    painter.save();
    painter.fillRect(0, 0, width(), height(), color);
    painter.restore ();
}

This done, by calling g_digicam_manager_play_bin() and g_digicam_manager_stop_bin(), you can control the viewfinder running on the window. The g_digicam_manager_play_bin() function received the XWindow id of the widget, which is obtained through the winId() member of QWidget.

Finally, when the pipeline is running, by calling g_digicam_camerabin_get_still_picture(), you can capture a picture. When doing so, besides the picture being stored in the provided path, the manager will emit (if preview is active) a signal containing a preview of the captured picture. In order to show this preview, I connected the imagePreview member of CamWindow to the preview signal. Inside this method, the GdkPixbuf received is turned into a QImage and then a QPixmap that is shown in a new window:

void CamWindow::imagePreview(GDigicamManager *manager,
                             GdkPixbuf *preview,
                             gpointer data)
{
    QLabel *label = new QLabel();
    label->setAttribute(Qt::WA_DeleteOnClose);
    label->setWindowFlags(label->windowFlags() | Qt::Window);

    QImage image(gdk_pixbuf_get_pixels(preview),
                 gdk_pixbuf_get_width(preview),
                 gdk_pixbuf_get_height(preview),
                 gdk_pixbuf_get_rowstride(preview),
                 QImage::Format_RGB888);

   QPixmap pixmap(QPixmap::fromImage(image));
                  label->setPixmap(pixmap);
                  label->show();
}

If you get the code and run the example in an N900, you will see a window with a capture button. Go to the menu, select play and the viewfinder will show up (and capture button will be over it!). You can change the resolution of the picture through the menu, and press the capture button to get a picture, and see the preview of the capture in a new window. For the moment, those are the features I’ve implemented in the example.

It’s quite simple, isn’t it? 🙂

siggy now on extras-testing

As you know, PR1.2 is there, so I’ve retaken siggy to have it ready to use.

Finally all the Qt 4.6 dependency problems have gone and the promotion to extras-testing became available. But I was missing a little detail, as I had no bugtracker link in my debian/control file. So I’ve released a new minor version (0.4.1) containing that link, uploaded all the stuff as usual (gitorious, garage), and promoted it to extras-devel.

So, help me a bit with the testing and I hope it will be soon available at the extras repository!! 🙂

The piggy keeps growing: 0.4 is here!

It took me longer than expected, but at last I’ve been able to release the version 0.4 of siggy. As usual, you can find the source code at gitorious, and together with the armel package at Maemo garage, and I’ve also uploaded the package to extras-devel.

For those who haven’t realized, due to the upcoming PR1.2, the Maemo 5 sdk has been updated, so developers can perform the appropriate changes to their apps in order to have them ready for it. To the Qt developers this means that the brand new Qt 4.6 has replaced the old 4.5 version, so we don’t need to keep using the previous testing packages anymore. I’ve modified the application to use the new libs and everything seems to be fine… despite I haven’t been able to promote it to extras-testing yet… it seems that there is a dependency problem somewhere that I need to check. I also need to ask for a bugzilla component at the Maemo bugzilla. But don’t panic ;), I’ll work on it 🙂

So, what’s new in this release besides the change in the dependencies? I guess the main change is the multiple account support. Now you can create more than one account in the application (personal, job, whatever) and assign the expenses to it.
How does this work? When users open the application, they can’t do anything else than managing items and accounts. Any other action is forbidden (and not shown in the menu):

At this point, users need to create an account and select it to be able to anything. Now each account has its own default budget:

And after creating the account, users may update, delete or select it:

Once the account is selected, the application behaves exactly as before, but all the data stored will belong only to that account (budget, expenses and scheduled expenses), and the active account is shown in the application’s title bar.

A small difference is that the Budget option in the menu doesn’t allow to set a default budget as before (this is achieved by editing the account), but only changes the budget of the current month.

At any point, users may select any other account to work with, or delete stored accounts. In the delete case, the user will be prompted for confirmation, as deleting an account will also delete all the data associated to that account. An small constraint is that the active account can’t be deleted.

Keep in mind that, due to this new feature, this version is not database compatible with the previous one so, if you had a previous version installed, you will need to delete the old database to use this new version. To do so, you can remove the folder $HOME/.siggy or you can purge the application.

Is this what you expected? Do you think of any improvement that can be made? Feel free to raise your had! 🙂

Besides that main change, there are a couple of minor ones. The first one is that when adding/updating an expenses, the days in the selector have been humanized, so they show something like “Mon, 1″… “Tue, 2″… Yesterday… Today… Tomorrow… which is easier to understand. Thanks to Joaquim Rocha for this patch!. Also, as promised, I’ve added an UUID column to the expenses table in the database, thinking of a possible synchronization service (this was really easy when I found the QUuid class).

And last, but not least, I’ve been working in the password protection issue, but I’m currently hesitating about how to implement it. I could add an optional password to protect the whole app, so it doesn’t even launch without entering the password, or I could add an optional password to each account, so some of the accounts could be used without entering it and some others will require the password. What do you think?
For the moment, in this version I’ve added a password column to the account table that would allow the second option (probably the chosen one), but I haven’t implemented the feature as I didn’t have too much time lately. But at least the field in the database is already there, so no database changes are needed later 🙂

And I guess this is all for 0.4. Hope you like it! 🙂

siggy version 0.3 released!

As promised, the brand new 0.3 version of siggy is out 🙂
You can get the source code and package at garage, and it has also been uploaded to the extras-devel repository. You can check the source code from its git repository as well.

When developing this version, my idea was to add some way to get information from the data stored in the database. So I thought of two views. One of them would be a statistical view, where I could check how I’ve been evolving during a period of time, showing totals, average values, etc.
The other view would be a kind of chart representing the amount of money spent during a period in each of the items defined in the application.

Some hours coding and this is the result:

What do you think? Could this be useful to you? 🙂

Unfortunately, the next mayor update is not out yet, so the limitation to move the package from extras-devel to extras-testing is still there. Anyway, this can be seen as an advantage 😉
For the upcoming 0.4 version, I have planned a couple of features requested by you:

  • The first one is adding support multiple accounts, just in case someone wants to handle more than one of them.
  • The second one is adding to the expenses in the database some kind of unique id that would allow synchronisation with a centralized service/database. This one opens a new and really interesting functionality for the application: it could be used by workers from a company to write down their work expenses. Periodically, the workers might sinchronize their expenses with the central server, so they are automatically queued to be paid as allowances. Sounds cool, doesn’t it? 🙂
  • If I have enough time, I will also add password protection to open the application

So, why the delay in the mayor update is an advantage? All these new features require changes in the database tables, which means problems for those who have started to use the application using a previous vesion. So, my advice is: test the application as much as you can, report bugs, patches, translations, etc, but don’t start to use it regularly yet. Wait a bit more. I’ll try to have the next version ready before the upcoming mayor update. This way, when the update is out, you’ll be able to install the new version without migration problems 🙂
Anyway, if there’s someone who wants to start using it asap, just tell me, and I’ll provide a script to update the database together with the new version.

I’m eager to get feedback from you!! 🙂

(Update: I put https URLs instead of http. Sorry! Should be fixed now.)

… and the piggy got detained in the border…

… suspicious of carrying illegal dependencies XD

You may know form my last post, that I’ve released the 0.2 version of siggy. During these days I’ve been performing all the paperwork to put available to the world: creating the project at garage.maemo, creating the packages so you could download them, and also uploading them to the extras-devel repository.

After doing so, I was happily going to promote the package to extras-testing, when the border guard came and stopped me: the piggy may not go beyond here, son, he said. What does this mean? Easy: siggy depends on the 4.6 Qt libraries (to be ble to use the Maemo5 widgets). These libraries are been developed and available from extras-devel, but with different package names than the 4.5 ones (libqt4-maemo5-* instead of libqt4-*), and different installation path. This was done so the users could test the new version on the libraries without mixing them with the system 4.5 ones. But at some point, these packages will be removed from extras-devel and they will replace the 4.5 ones (this is planned for the next major update AFAIK). So, as siggy depends on those about to dissapear libqt4-maemo5-* libraries, once the next update was released, it would stop working.

I must say that I was already aware about this, and I had planned creating a new release with the new libraries as soon as the update was available, but I guess the policy of non promoting the applications to extras-testing makes sense as well 🙂
(BTW, good work to Qt team! keep up with it!) 🙂

So, what’s the plan now? Well, current package (both at garage and extras-devel) will work with the libqt4-maemo5-* libraries available in extras devel. So you can grab them and start using the application. But if don’t want to mess with your system and install these libraries, you just need to wait for a while. At some point, the next update will be released, and the Qt 4.6 libraries will be installed in your system. At that moment I’ll create a new package with the new dependencies (you can do it also from the source code), and will update it in extras-devel and extras-testing, so you can easily install it 🙂

In the meanwhile, working in the 0.3 release, I’m currently developing a summary window where the user would be able to get some information from a period of time: amount of money spent and saved, average month expenses, average money saved, etc, together with a pie chart showing the percentage of money spent in each item.

After that, I have some cool suggestions coming form you that are really interesting but… hey!… that’s another story 😉

Who cares about the piggy? I do!

As I commented in my last post, during my investigation about the state of Qt in Maemo, I decided to start implementing an idea I’ve had in my mind since I got my N900.

I guess I should start explaining that I’m a complete disaster managing my money. I don’t really know what I do with it, or where I spend it. And living in this global-crisis time, this is serious guys! I need a way to fix it.

So I thought: wouldn’t it be great if I could store all my expenses in my brand new N900, so I could not only know where I spend my money, but also be able to know my current state compared to the month budget???? Even more!!! once I have all that information stored, I could perform every kind of weird queries over it, like how much money I spend in coffee, food, beer (mmm… not sure if I want to know about this one 😛 )
And having all this information, I could start saving money, and my piggybank would be able to leave peacefully without being afraid of being killed!

I guess you already know what happens when you put a developer with an idea in front of a new technology to test so… I started the development of siggy (whose name is a declaration of intentions: Save the pIGGY!) 😛

These were the features I wanted to have for its initial release:

  • Be able to define a budget for a month
  • Be able to write down expenses in that month
  • Be able to easily see my evolution during the month, comparing it to an ideal one
  • The creation of expenses should be as fast as possible, and I shouldn’t need to use the keyboard
  • Be able to define categories to the expenses
  • Autocreation of recurrent expenses

And besides those, of course, I wanted to test what could be done with Qt in the N900. So, I had also these ones:

  • Integrate siggy visually with the Maemo environment as much as possible by using the custon Maemo5 QWidgets
  • Internationalization support
  • Integration with the backup system
  • Make siggy rotation aware?

So, I created the siggy repository on gitorious and started coding: put a SQLite database here, a MVC pattern there, a custom widget to draw a graph with the expenses evolution, some basic gesture support, lots of dialogs to achieve the Maemo5 user experience, and… I’m proud to announce that I’ve just released the 0.2 version of siggy!!! 🙂

What can you find in this 0.2 release? These are the features:

  • A month is represented as a graph where the expenses are represented together with an ideal evolution, so getting info about the current state is really easy and fast. User can navigate through existent months by dragging left or right in the main window
  • There are two views for the month, the daily one and the accumulated one. User may change between them by clicking on the main window
  • User can define a budget for each month, and define a default budget for every month
  • User can create/update/delete items. An item is a category for an expense with a predefined price
  • User can create/update/delete expenses in any month. An expense may or may not be associated to an item
  • User can create/update/delete scheduled expenses in the application. Scheduled expenses will automatically be created in the specified months, so the user doesn’t have to create, for example, an expense for the rent each month
  • Application is perfectly integrated with the Maemo5 environment
  • The application has internationalization support and currently has english and spanish translations
  • Both database and configuration file are integrated with system’s backup application

Of course, this are not the only features siggy will offer, but they are the basic ones needed to start using it and entering data. After this release, my plan is to start implementing features related to extract information from the stored data. But, of course, I’m willing to hear your opinions, suggestions, whatever! 🙂

You can get the source code from the siggy repository on gitorious, where you can also find a small user manual. Bear in mind that in order to build/run the application, you need to have installed the libqt4-maemo5-* packages available from the extras-devel repository. Please, feel to report any problems you can find 🙂

And as farewell, here you have some pics! 🙂

About G’s, Q’s and M’s

During last years, I’ve been collaborating in the development of the 5th version of Maemo. As you already know, almost everything in this version has been created using GNOME technologies, so these were my tools to help with the development.

But some time ago, Nokia announced that they have changed their mind, and that the new upcoming Maemo6 will be Qt powered. And a bit after that, this new Meego initiative was announced, as the fusion of Maemo and Moblin to create the “ultimate mobile technology that will rule them all”. Well, I must say that these movements attracted my curiosity, so I decided to rescue my Qt knowledge and give a look to what’s really being done in/with Qt inside Maemo. Of course, having some knowledge about the Maemo5 environment and being the proud owner of a N900 made me start with the “what can be done with Qt in Maemo5?” question.

You may (or may not) know that Qt4 is already in your N900 if you have installed the Nokia released updates. It’s the 4.5 version. Nothing new under the sun. But the most interesting stuff is not there, but in the beta 4.6 version that lives in the extras-devel repository (how to enable it?). A lot of work has been and is being doing there to (among other things) ease the development of Qt applications and to be able to use the Maemo5 Hildon widgets from it. You can find more information about it here and here.

So, what’s the cool stuff? For the lazy ones, who don’t want to read all the documentation, these are the main ones regarding app development:

Ok, there are a lot of resources available. Great!. But… are they useful? Are they usable? Can we do cool software with them? The best way to test that is by using them, of course, so a while ago I started to develop an old idea I got for my N900 and… well, I guess that’s a story for another post… 😉