It was decided after the last conference that instead of coming up with a new website every year we wanted something that would be reusable for several conferences. Koen Martens set up Open Conference Systems and the great designer Vinicius Depizzol made a beatiful theme for the website.

I’ve been working on maintaining the website, extending the functionality a bit and pushing the code to Git for everyone to access. You can download the code from the guadec-web module at git.gnome.org. All patches will be considered. We don’t have a product registered in Bugzilla, but of course mails are welcome.

One of the things I’ve been working on was adapting UDStream for use on the GUADEC website. You can see it in action at the ‘Conference lifestream‘ page. I haven’t pushed the code to Git yet, but that’s because I’m also working on integrating OpenStreetMap with the accommodation page.

I’m unsure whether to file a merge request with the changes I’ve done to UDStream. I have to admit that I didn’t change a lot, most of the changes to the theme and changes to the way the JavaScript is included in the HTML file. Does anyone know whether UDStream is going to be used again during the upcoming UDS in Brussels?

We keep track of applications that need support for Indicator Application on Launchpad with the bug tag ‘indicator-application‘: the list of bugs against applications that need Indicator Application support. There are code snippets on the wiki page of Application Indicator but in this blog post for those who would like to use it in their application.

I recently added support for Indicator Application to Lernid, Bzr-Gtk and Transmission and am now working on getting it into Banshee. How do you help Ubuntu with adding support to existing applications? I’ll try to make that clear in this blog post.

#1. Find something to work on. That list of bugs against applications that need Indicator Application support is a great place to start looking. Don’t forget to mark a bug as ‘In Progress’ when you’re actively working on it!

#2. We’re adding support to an application that is most likely used on more places than just Ubuntu. Therefore you should keep in mind that not only enabling Indicator Application support should be easy, but also disabling it. This means you’ll have to do some Autotools magic in order to make sure libappindicator is present and it is wanted. At the AppIndicator wiki page there is an example autotools macro. This should be added to the ./configure.ac, which can mostly be found in the project’s source code root directory.You may have to adapt this in order to make it fit in the existing makefiles.
NOTICE: The previously mentioned autotools example was written with the programming language C in mind. When you’re writing in C# you can reuse the code, but please keep in mind that you should check for ‘appindicator-sharp-0.1′ rather than ‘appindicator-0.1′. The whole check isn’t necessary for Python.

#3. Now we can start writing the code. Finally! I’m afraid I have to disappoint you, because the code itself is the least work of the whole procedure. Again, there is a Porting Guide at the wiki page with examples for all supported languages. Those are pretty straightforward, so I won’t repeat them here, but if you still have questions, don’t hesitate to leave a comment. Important is that you should use the previously defined autotools variable HAVE_APPINDICATOR (when programming in C) to allow the application to be compiled with a GtkStatusIcon as well, on other systems. You can do that like this:

#ifdef HAVE_APPINDICATOR
 #include <libappindicator/app-indicator.h>
#endif

(other code)

#ifdef HAVE_APPINDICATOR
(Indicator Application code here)
#else
(leave the old GtkStatusIcon code here)
#endif

#4. Now that the code and build macros have been written — and the configure script and the makefiles regenerated — and you’ve tested it (naturally), it’s time to submit your wonderful patch. Of course you do this on the bug report we’ve got in Launchpad, but we also would like you to forward the patch upstream. If there was not yet a bug report in the bug tracker of the application you ported, report one and link it to the Launchpad bug report. In the upstream bug report, leave a comment with your patch.

After that you’re done. Congratulations, you’ve helped with making the systray cleaner and prettier and more consistent. This makes us happy!

MVC-pattern rewritten
The MVC-pattern is now applied more strictly.

in the changelog.
After several days of work I know managed to let the code do roughly the same with 3117 lines of code more, which means the codebase has almost doubled.

Why would I do this? Why would I make such an effort to expand the codebase so much while there doesn’t change a lot to the external behaviour?
Because now the MVC-pattern is applied strictly and the models can do more than just presenting information it’s just a matter of connecting wires when you want to add a page. No need for writing lots of queries.
Because of the new store function it’s going to be a a lot easier to add AJAX functionality and it already makes it easier to update entries.
The data is loaded into Model::data and when you call Model::store() the data is compared to a copy (Model::_data_copy) and all changes are written to the database.

Now on something different: I created a milestone for Ubuntu Wanted called usable, if all bugs and blueprints marked for that milestone are finished/fixed we can start with testing Ubuntu Wanted in a Real Life Situation. I found milestones a lot easier to use than mind maps, so I’m going to dump the mind map I blogged about earlier in favour of Launchpad.

Lets show some stats! Everyone loves stats!

I let Ohcount examine the branch before and after revision 18, which gave these results:

Before

Examining 79 file(s).

Ohloh Line Count Summary

Language          Files       Code    Comment  Comment %      Blank      Total
—————-  —–  ———  ———  ———  ———  ———
php                         31       2173       1020      31.9%        646       3839
css                           9        2122            73        3.3%        185       2380
html                      31          397              9        2.2%         172         578
sql                           1            44             33      42.9%           11           88
javascript              2            16              4       20.0%            2            22
—————-  —–  ———  ———  ———  ———  ———
Total                      74       4752       1139      19.3%       1016       6907

Platforms detected: PHP, SQL, Drupal
Tools detected: None

After

Examining 118 file(s)..

Ohloh Line Count Summary

Language          Files       Code    Comment  Comment %      Blank      Total
—————-  —–  ———  ———  ———  ———  ———
php                        64       3431       1922      35.9%       1010       6363
css                            9       2122           73         3.3%         185       2380
html                       64        802            18        2.2%         328       1148
sql                             1          46             33      41.8%            11          90
javascript               3           31               8      20.5%             4          43
—————-  —–  ———  ———  ———  ———  ———
Total                    141      6432       2054       24.2%       1538      10024

Platforms detected: PHP, SQL, Drupal
Tools detected: None

If you feel like helping the project out a bit, have a look at the usable milestone page to see if there’s anything for you.