Category: english

Vala

A lot of people are visiting #vala on GimpNET to tell Jürg Billeter how much they like Vala. One such person already finished a Vala binding for GtkMozEmbed, another is now working on bindings for Clutter.

This is very cool indeed. Soon we’ll have solutions in place for the vast majority of our libraries. I hope our community realizes that the emerge of a new programming language can only succeed if the creators get some help with implementing required instrumentation.

There’s for example a challenge in supporting .vala files in a clean way in autotools and Makefile.am. Although the majority of people dislike autotools & co., it’s used by nearly all of GNOME’s libraries. To make things work smoothly is a good integration needed. The difficulty is that a Vala compiler, unlike a C compiler for typical C projects, needs a list of all Vala files to start generating the .c files. For Python they needed something similar using a helping script called py-compile. Java can cope with a file per class, as there’s a file-name convention.

Vala is missing documentation, a website and there’s a lot of low hanging fruit that can very easily be picked up by new people.

As for Tinymail, me and Jürg are planning to replace the TnyList and TnyIterator interfaces with the ones in libgee sooner or later (probably later, as I’d like to release a one point zero of Tinymail before that). I heard the Anjuta folks are interested in replacing their “from IDL generated interfaces” with Vala-ones too. I might just bite the bullet and rewrite all Tinymail’s interfaces in Vala. As soon as Jürg has the binding generation for Vala in place, that would mean I would get the generation of language bindings for free. Right?

This illustrates why I think Vala is such a good idea. Especially for GObject based libraries that have interfaces for their API.

Tinymail

Today I finished the work on Tinymail to make it completely “Gdk lock” aware. This means that Tinymail’s signals, observer update invocations and callbacks are all “Gdk lock” aware. In practise this means that you, as application developer, don’t need to acquire the Gdk lock yourself. For your own timeout and idle callbacks and for your own threads calling Gtk+ or Gdk subsystems you of course still need to do this.

This work will be committed tomorrow. I don’t know when Modest’s public repository will have the required changes for this (some people are on vacation, etc etc).

Documentation still has the top priority at the Tinymail project, so some new documentation items got added. Mostly about how Tinymail works internally related to the recent improvements. I have asynchronous operations, asynchronous connecting and dealing with the Gdk lock for you.

These recent improvements combined together should make Tinymail more robust against threading problems. There’s locking order, queuing and guaranteed handling of the Gdk lock in signals, observer update invokes and callbacks. The queue waits for the return of the callbacks made by the application developer, avoiding that the application developer can launch a method in that callback that would lock with the original call that invoked the callback. Lot’s of improvements like that.

All these things have delayed the release candidate that I promised to some people at GUADEC this year. I also want to let the improvements stabilize a little bit. On top of that there’s quite a lot of work cleaning certain things up. I would also like to create a QEmu image with an IMAP server and the Tinymail demoui that I’ll release in parallel. These are certainly things people can help me with, if they want me to speedup a release for Tinymail.

The make distcheck should be again working, some of the unit tests need reviewing, the !@#*@* gtk-doc scripts need to be fixed .. again, the !@#*@* Python bindings are broken .. again, the enum and flags GTypes are synchronized once more (although some don’t have documentation in gtk-doc yet), etc. I guess all these are the typical 60% of work a project maintainer has to do. A lot of work is indeed because all our development tools are completely broken and not integrated with how people really work.

Gdk Lock aware?

Right, some people have reviewed that wiki page that I mentioned yesterday. Hoping more people will do reviews.

IRC

If you can’t join a GNOME or Gtk+ channel on GimpNET because it’s invite only: /msg dorito invite #channel. The ops had to set some channels to invite-only because of spam bots.

I’ll try to make it more of a habit to write about Tinymail‘s future enhancements before I commit them. This gives people who are following the project the opportunity to comment on and maybe improve the actual work.

In the good old current days Tinymail’s callbacks for asynchronous operations are guaranteed to happen in the GMainLoop of your application. Tinymail uses a g_idle_add_full and ensures that the operation itself happens in a queue that runs a single thread, and a GCond that ensures that the queue will wait for the callback to happen before entering the next item on the queue.

That’s not enough because a g_idle_add_full does not enter the GDK lock. In near future (the patch is ready), Tinymail will do this too. This will make all of Tinymail’s callback invokes behave like signal handlers of Gtk+ components.

Tinymail’s observer update functions will do the same thing. Although I know you can use glib’s signals for this, I used the original observer pattern for some situations. Usually for situations where it must be clear for the application developer what he’s doing. Just like signal emissions must these update invokes or notifies happen with the GDK lock locked. Next on my list is going after all signal emissions that happen outside of the GDK lock.

The thing with this GDK lock is that it’s completely not well documented, that nearly nobody in the GNOME community fully understands how it works (except maybe people like Tim Janik), how you need to use it and more importantly when you need to do it. It’s at this moment definitely not (yet) clear at all. I started this wiki page in the hopes that our experienced developers will continue improving it. This way we might someday have a real and full description of how to actually correctly use gdk_threads_enter and gdk_threads_leave.

Two or three months ago Krzysztof Cwalina made one of his Microsoft Research presentations available. It’s a presentation of around four hours about how to design framework APIs.

He talks about quite a lot of subjects that I think the community of people working on future GNOME related frameworks and infrastructure should carefully listen to.

I’m one of those software developers who have very much respect for those people that Microsoft employs who are passionate and knowledgeable. I truly believe a lot of the technical people at Microsoft do want to make things better. This makes it interesting to listen to their thoughts and ideas, to be open minded about their research.

If you have Windows Media Player you can watch the presentation here. You can download this presentation for offline view here. It contains a .asf file in one of the folders. You can probably view it using one of those media players that we have. If not, in stead of ignoring the content I advise you to use your mother’s Windows computer to nevertheless watch the presentation. You’ll suffer from having to use Windows and you’ll suffer from having to watch four hours of presentation material, but I promise you that it wont kill you and that the presentation itself is quite interesting.

I know that this blog item misses real argumentation on why you should view it and waste four hours on this. Well, just do. There you have it.

Due to naively designing the internal organs of Tinymail’s async methods, I introduced a lot of threading and locking difficulties to the application developer who’s building an application on top of Tinymail.

We noticed this and therefore we did something about it (we is Rob Taylor and me). The solution was to introduce an internal queue that guarantees locking order for operations and during the connecting of accounts. The callback, which the application developer can implement, will make such a queue item waits for its completion. They happen in the mainloop, so that is done using a small little “GCond” construction. Dialogs like the password dialog, the SSL question and the code that gets launched in case the password was wrong will now all happen in the mainloop of the application. This makes it much more easy for the application developer to implement them using user interface components like the GNOME password manager’s dialogs.

This work was being done in this branch of Tinymail and will, with the migration of an E-mail client that is being build on top of Tinymail, be merged back to Tinymail’s trunk starting tomorrow. Some of the work has already been merged in trunk. Mostly work that was not related to the account connecting and initialization (which includes the password -and the SSL question things).

Hereby apologies for making these horrible internal design decisions. I guess I focused at the start of the project too much on the external design. I guess I hoped too much that internal organs would automatically become good too. This kludge made the external API behave difficult for application developers. It’s fixed now, and we wont make the same mistakes again. I believe this work is one of the key pieces in the puzzle that can turn Tinymail from a hobby project into an actual product.

The good thing about the kludge is that it forced me to make a lot of the locking both very fine grained and yet very correct. With the locking order in place now, this should mean that the overall quality should have improved a lot. We’ll see. Let the testers begin!

Another key piece in the puzzle is to someday have a libtinymail-dbus. We’re already planning and designing this, indeed.

Make gdk_threads_enter and _leave recursive locks. Is there a good reason why they are normal locks today?

This is the first release of libgee 0.1.0, the GObject collection
library.

libgee 0.1.0 is now available for download at:
   http://www.paldo.org/libgee/libgee-0.1.0.tar.bz2

libgee is a collection library providing GObject-based interfaces and
classes for commonly used data structures.

libgee provides the following interfaces:

        * Iterable
          * Collection
            * List
            * Set
        * Iterator
        * Map

The ArrayList, HashSet, and HashMap classes provide a reasonable sample
implementation of the List, Set, and Map interfaces. ReadOnlyCollection,
ReadOnlyList, ReadOnlySet, and ReadOnlyMap are read-only wrapper classes
that prevent modification of the underlying collection.

libgee is written in Vala and can be used like any GObject-based C library.
It's planned to provide bindings for further languages.

Development is going on at svn://www.paldo.org/libgee/trunk

        Jürg Billeter

Dave writes on his blog an interesting point of view on why mobile device vendors should stick to the open standards. He’s on a blogging spree, so make sure to read the follow-ups on this item too:

This also highlights a serious issue with closed and non-standard platforms. If this were an ordinary smartphone, you could just shrug, ditch the in-built email client, and use something different. I’ve no idea whether, for instance, the email clients on the 770 and N800 are safe to use or not – but if I were using them, and I found it was insecure, I could switch to a different one. Security issue solved. I can switch to a different client because anyone can – in principle – write one, because the platform is open (allowing them to write programs for the platform) and the standards are open (allowing them to write an email client).

With Apple’s choice to use a proprietary system with Yahoo, the option to be secure has been denied to their users.

Had Apple and Yahoo chosen to use the existing, open-standard, Lemonade protocol suite, this simply couldn’t have happened.

ps. Tinymail and Modest of course use the standards, securely.

Although I’m one of those guys who’d like to see all platform code to be run by a jitter that can support all the programming languages, platforms and devices that we use today and in future, I got a very nice second introduction to Vala at GUADEC.

The nice thing about Vala is that it gives you a programming language that looks and feels like C# and D (generics, interfaces, properties, classes, delegates and all that in a syntax that looks almost exactly like C#), yet it’s completely compatible with GObject and GTypeInterface. That’s because the Vala compiler behind your back first compiles to a GTypeInterface or GObject before passing it to your normal C compiler.

Which sure sounds scary. Though … if you think about it for longer than a few seconds, it’s absolutely not a very bad idea at all. Especially not when it comes to integrating with existing GObject infrastructure. When it comes to having a nice higher programming language where your software’s release tarballs need nothing more than a C compiler and glib with gobject.

Vala is smart enough to also do this right, to generate clean GObject code and to allow inheritance and implementing from existing GObjects and GTypeInterfaces. It manages to get generics and reference counting to be just right (reference counting is done using smartpointer likes. It’s done for you automatically, so there’s no funky C++ syntax involved. You also have weak references to avoid embraced references).

The author is also working on automatic language binding generation to programming languages like Python and .NET. This is more easy with a Vala programmed piece of library because the Vala compiler knows from the Vala syntax that the developer did everything in a certain way (and not in one of the ten million ways that the C programming language allowed him to work).

On top of that is Rob Taylor working on his stuff to parse the C tree of a piece of C header code to an XML file. For this XML is useful because on that resulting XML we can apply XSL stylesheets. For example one that formats it into something that we can embed into the shared object file of a GObject library, to add introspection data. Or another XSL to aid a tool like gtk-doc to create an indexable API documentation database, HTML or whatever file that can then be used to be put online or to be used in tools like Devhelp or for code completion in an IDE like Anjuta.

But also something that can be utilized to fully automatically generate completely correct language bindings. On dynamic or so called “always late binding” programming languages, like Python and PHP, it could even do this at runtime. With type safe programming languages it could at compile time use this new and extra information to without any real help from a human developer, create a completely correct language binding.

Since today for both POP and IMAP it’s possible to, while you are retrieving summary items, start opening (downloading) uncached E-mails. On IMAP this is done (a few weeks ago) using an extra socket. With POP this is done (today) by throwing RETR commands in between the TOPs that are needed for the summary fetch on the same connection (most POP servers lock the access to one connection per user). It’s also possible and well tested to have Push E-mail events of 1000ths of new and expunged E-mails. It’s possible to see your headers (summary) view to get filled up while retrieving summary info. All this while Tinymail attempts to keep the bandwidth acceptable low for GPRS.

Jose Dapena Paz also recently added support for removing attachments from already cached E-mails. This is a feature that is interesting for devices that don’t have a lot of (flash) disk space. Again retrieving the uncached attachment should also work. Partial retrieval (initially retrieving without attachments) is working, but suboptimal. We’ll be working on improving features like this soon. POP is of course much more difficult as there’s no way to know where a MIME part starts nor to select which of the lines you want to retrieve.

Huge amounts of small and big things are being fixed. Required features being implemented. A lot of work is being done.

By changing the way work is done, electronic networks may lead to a new kind of economy centered on the individual. — Thomas W. Malone and Robert J. Laubacher.

In business, I believe the future lies in loosely connected individual contractors, dynamically coming together to attack a project or idea. — Rob Taylor.

When Rob blogged about it, I decided to order my copy of that document. I just read it. Sounds good to me.

Let’s talk about it at GUADEC. I will arrive at BHX the 15th around 13:50 by the way.

I would, out of the blue, like to highlight the work the people doing the Anjuta 2.x series have done. I have been working with whatever is in Subversion (and before that, CVS) for multiple years now. It had its weeks of total instability, weeks of total stability too. But on features, especially on features, it has seen vast improvements. It’s a totally different experience when compared to the 1.x series of Anjuta.

pvanhoof@schtrumpf:~/repos/gnome/anjuta$ sudo make install
...
 /usr/bin/install -c -m 644 'anjuta.desktop' '/opt/anjuta//share/applications/anjuta.desktop'
make[2]: Leaving directory `/home/pvanhoof/repos/gnome/anjuta'
make[1]: Leaving directory `/home/pvanhoof/repos/gnome/anjuta'
pvanhoof@schtrumpf:~/repos/gnome/anjuta$ 

They are now working on integrating some bits and pieces with scratchbox. The integration with autotools (which utilizes gnome-build) is unimaginable good. I’ve become a total addict of features like the symbol browser and the symbol searcher. I’m sure I’m missing quite a lot of other features that could potentially glue and duck tape me forever to Anjuta’s 2.x. A requirement for any distribution that I’ll use has been, since more than a year, that I can easily build whatever I find in Anjuta Subversion -> “apt-get install gnome-devel”. Thank you, Ubuntu and Debian, for that.

I believe we need more of our developers to use this project. That way we can get this project to become a product, too. Because frustrated developers will fix Anjuta’s code. In contrast, I haven’t seen a lot of GNOME-developer’s frustration get converted into code for the Eclipse CDT project. I’m confident that since Anjuta is purely GNOME/Gtk+ style of development, Anjuta would be different.

I often got so pissed at whoever broke the search dialog of Anjuta’s Subversion this time. Forcing me to go back to ‘grep’ and ‘find’, to find things. Slowing me down. But then again, I should just help them in stead. Right? In stead of remaining pissed, I’ll truly apologize for being a user of their software yet not having contributed a lot to their fabulous 2.x series. On the bright side, I did do some work on the file dialog of the 1.x series of Anjuta. That code has now vanished and been replaced by superior things, of course.

I’ll put an icon on my desktop that throws Anjuta’s process into gdb. Being a developer you’ll be surprised how often you click it and then actually fix that annoying bug in stead of just restarting the software. I used to do this with Evolution too.

We’re getting there. Although I’m thinking in months, not in weeks. If you’re working on a feature for Tinymail and you want it in its first release: you better start hurrying up.

It’s becoming a product that just works. A lot of the release work will be low hanging fruit like getting gtk-doc in perfect shape, making sure ‘make distcheck’ does the right thing, killing a few more major defects and writing some more documentation.

When those items are finished, the project can be delivered as a product. Above all, it must earn the status “product”. That’s the point where I’ll release a first version.

Rob (Taylor) used to be one of the lead developers of the Telepathy project, he co-founded Collabora and is now starting up Codethink Ltd. He has worked on HAL, D-BUS, Telepathy and various other bits and bytes of the many GMAE and GNOME components.

Although not the only participant in this, I believe he played an important role at encouraging a number of companies in working with us, the GNOME Free Software community. He combined his technical expertise with business expertise.

It’s therefore my opinion that Rob has become one of our most skilled and needed people. At LinuxTag we agreed to start working together under Codethink’s flag. I will be the first contractor to come on under the new Codethink plan.

With our expertise we are planning to change the mobile landscape. We’re both passionate people who’s goal is to make the difference, which is exactly what we’ll do.

The Evolution maintainer announced a new release. This time the release fixes a significant security problem.

The problem is a remotely exploitable one. I strongly suggest everybody updating his or her Evolution setup. Even if your Evolution package is incredibly old. I think nearly all Evolution’s versions are affected.

Evolution-data-server:
=====================
...
#447414: Security Fix - negative index of an array (Philip Van Hoof)

At LinuxTag Rob and I met and talked quite a lot to some Qt and KDE guys. We somehow came to the conclusion that a combined conference for our communities would be something positive. We concluded that the majority of people in both communities who truly matter (the people who do things, not the people who only talk about things), enjoy the competition between GNOME and KDE. That they love the other guys. That competing each other is giving both project’s members a reason for innovating their own project. Yet that the same competition should focus on being the best at what we do while that this competition should not make it difficult for the many companies and users that use our infrastructure.

Therefore we agreed that as much as possible of the D-BUS API should be shared between the KDE and the GNOME projects.

Our conclusion was that we need more social networking for this synergy to happen. We concluded that both Akademy and GUADEC share the same conference atmosphere and goals: they are both heavily oriented at meeting each other.

I would therefore, hereby, like to propose using the FOSDEM conference to pioneer the idea of perhaps in future having the GUADEC and Akademy conference to take place at the same time and location. Note that in this idea neither GUADEC nor Akademy change names nor that it would become one big conference. Note that it’s only an idea and that I think for it to succeed, it needs a pilot event. FOSDEM can be used for this.

We could play with the idea of having a few shared social events, like a game of soccer. Maybe making music together (as that was one of the greater ideas at GUADEC last year)? Social events with an emphasis on cooperating yet competing? Friendly competing!

I’m planning to ask the FOSDEM organisation to, in stead of two rooms, have one big room for both GNOME and KDE people. Or two rooms while mixing the presentations equally over the two rooms.

I hope I will be flooded by opinions coming from both sides, as this is probably a hard decision. Though I believe that both communities need to do this for our users and for the companies who get to deal with our differences.

I would like to state, clearly, that as a GNOME community member: I love KDE, I love the people who do KDE, I clearly disagree with a lot of their strategies and architecture ideas and I totally love the competition that got created by this disagreement. Let’s strengthen both and get them to share as much D-BUS API as humanly possible. Yet let’s keep competing each other by trying to provide the best implementation behind those APIs.

Let’s ignore the people who think that we are duplicating efforts, as we know we are not.

Let’s be friends who meet each other often and who have respect for each other. Let’s agree to disagree, but let’s agree on the things that we can easily agree on: D-BUS API.

Finally and most importantly, let’s not just talk and have good intentions but let’s also make it happen. Let’s compete in style.

Look at those cute little devices! All doing Push E-mail with a Tinymail based E-mail client. All at the same time! A Nokia N800, a Nokia 770, my Feisty desktop and a OLPC. Next on the list .. the iLiad and Openmoko?

Video demo, Youtube version

Just like with the OLPC build I have fixed the builds for GPE and the builds for Maemo with older distributions like Mistral and Gregale (the rootstraps in Scratchbox that’ll compile for your Nokia 770). The build for Maemo’s Bora rootstrap (for the Nokia N800) and the one for GNOME desktops were of course already functional.

On all these devices and platforms (N800, 770, OLPC, GPE) you can now out of the box compile yourself a Tinymail demo user interface with the latest features. I will bring a few such devices with me at LinuxTag. Although very unfinished, I can demo a recent development version of Modest running on my N800 too. Which, by the way, is becoming more and more useful as fine dog food. The GPE and GPEPhone folks told me they will bring some GPE devices too (it wont take long before we’ll have the Tinymail demo ui running on all of them).

~# apt-cache search empathy
~#