Month: May 2005

A few minutes ago I quickly made this sample (quicklink to the code) for AsyncWorker. Getting the sample to work forced me to fix some issues in the library. It shows you a GtkTreeView with tree buttons: Add, Remove and Cancel. Pressing Add will create a new AsyncWorkerItem that has some simulation-delays (usleep). Remove will remove the item. Cancel will wait for a cancellation point in the item (and will then abort the item).

Hey Sven,

A few days ago I tested the clipboard-manager of Anders. Regretfully, however, it’s using gtk. It would be better if a desktop-neutral solution was build. The freedesktop concept really doesn’t need ten different solutions for one little problem. No I don’t hate gtk. But lets be reasonable and accept the fact that not everybody likes depending on gtk. We can always conqueror the world later.

And the clipboard-manager only fixes one issue and only for applications that can and will be modified. Many applications will not be modified and will therefore still cause the clipboard to disappear when they owned it and decided to shut down. So the backwards compatibility issue isn’t fully resolved. Yet I agree it’s a nice solution: In my document I wrote that (imho) it’s not always a good idea to overcommit yourself to backwards compatibility. In the end it needs to solve the problems. A long-term solution would be to create a series of standard target-formats (xslt?) and to let those persist automatically (by a clipboard manager). The current solution requires that the desktop application developer understands a specific detail of the clipboard system: The fact that a clipboard manager needs notification of which targets to persist. Whereas that should be obvious for certain formats! Desktop application developers shouldn’t have to worry about such specifics (and in reality I think they’ll often disregard it).

Perhaps a solution for xclients that don’t have “persistent targets” (is it the “SAVE_TARGETS” atom? The document you talked about isn’t available on fdo) could be to nevertheless save (one of) the UTF-8 plaintext targets.

And it’s not the only problem of the X11 clipboard. There’s many other problems like the performance on remote xserver X11 deployments, support for console applications, recovery after session restart, etcetera.

Some years ago (when I was still young and naive) I implemented a tool that had the purpose of fixing the many issues of the X11 clipboard. While some people packaged and even used it, I didn’t succeed in really fixing any of the issues.

The real fix is harder and more difficult. It involves working together, X11 politics, creating standards and agreeing upon a set of solution and or proposals.

Therefore I created a document that enlightens my views on the subject. It contains some proposals that might or might not be doable. The purpose isn’t to get these specific proposals into the throats of the developers of our free desktop environments. The purpose of the document is to keep people talking about these problems. Who knows someday people will start fixing them.

An overview of the subjects:

• Sharing the clipboard with console applications like vim;
• Clipboard owner dies means that the clipboard is gone;
• Performance issues when xserver is remote while clipboard owner and requester run on the same host;
• Standardisation of clipboard-formats;
• Standardisation of a transformable clipboard-format;
• Recovery of the clipboard upon session-start;
• Addressing backwards compatibility;
• Extending the clipboard: Virtualization and network clipboard sharing;
• Confusing multiple clipboards.

ps. If you find errors in the document, feel free to inform me about them.

Hey Dom Lachowicz, I like the new layout. Perhaps, however, you’re right about the wasted space. This could be solved with a layout like this.

Note that I don’t have a stylesheet like it. I just quickly GIMP’ed this one

ps. Sorry for raping your post Luis. I needed a victim with a long blog-entry.

Today I added some aid for supporting cancellation of items to asyncworker. It goes like this (check the link):

What will happen is that first the item will be created and then (at some point) launched. Upon some_event will a request to cancel the item be set. If such a request is set and a cancellation point happens, the item will be cancelled. You can pass a boolean to the cancellation point that will tell the asyncworker-library whether to still launch the callback (for cleaning up). Once cancelled or really finished, the “item_finished” signal will be emitted (and the handler will therefor happen).

ps. I also created the build-environment for the gtk-doc stuff. You can preview the API-docs here

AsyncWorker is a GObject-style library (liboasyncworker.so) that will ease implementing a task queue. By
which I mean a system like a printer spool, but for functions (or methods) rather than printer-tasks. So for
each queue instance, there’s always maximum one task being processed. Tasks can’t be preempted (it’s not a kernel scheduler),
but tasks that haven’t run or aren’t running can be removed. Of course can the kernel preempt tasks (the entire proces). I mean
that within your application, you can’t preempt a task: to make another task happen before the current task ended. While using
the same queue instance.

Creating a task happens by creating a OAsyncWorkerItem instance, which is of course a simple GObject. The object
holds, for example, a reference to a launcher function (the task itself), a callback (to cleanup your stuff after
the launcher finished), a launcher-arguments pointer (user data for the launcher) and a priority.

Once you add the item to the OAsyncWorker instance, the worker will make sure that at some point in the future, the
item will be processed. The higher the priority of an item, the faster it will be selected to be processed.

My plans for this one are to replace a specific GList with a GAsyncQueue. And to let all the signals (it has signals like
item_finished, item_added and item_removed) emit in the GMainLoop.

There’s some basic support (on platforms that support this) to set CPU affinity on a queue-instance. This way you,
as the programmer, can specify on which processors the queue may process it’s tasks. I haven’t yet added support
for the other sched.h functions. You can, of course, use multiple queues simultanously.

There’s no support for cancellation of the current-item (but you can remove items that haven’t ran). The reason is
rather simple: GThread isn’t supporting thread cancellation (for good reasoning). Yet, you can of course implement your own
cancellation-points and a cancel trigger. I might add functionality to ease this (not sure yet).

You’ll still need to use gdk_threads_enter() and gdk_threads_leave() in the launcher and callback functions of your
tasks. For example in case you’re planning to perform gtk stuff. You wont need to do that in the signal-handlers.

Mikael Hallendal invented both the name AsyncWorker and the namespace
to which I renamed this library. That namespace is “O”. It means “Onion”. It’s indeed to make sure that now we have
“Egg”, “Bacon” and “Onion”. Yet you can’t blame me for it!

pvanhoof - EggAsyncWorker ? :)
Hallski - eek
luis - I think Egg is a curse :)
Hallski - OnionAsyncWorker
pvanhoof - lol
Hallski - so we have an entire omelette
Hallski - with Egg, Bacon and now Onion

You can find asyncworker as a module in CVS here. You can find a simple sample that illustrates all this a little bit here.

Please note that the API isn’t stable (this is bleeding edge and very new). I did, however, already added some API documentation (so you can already generate API-documentation).

Hey John and others who’ll tryout this new release of Anjuta. I created this little script that will help you (compile and) keep that checkout of Anjuta updated. If you’re using one of the popular GNOME-from-CVS buildscripts, this ain’t useful of course.

About Marc Maurers Evince stuff: And if you want to let Evince also load some ppts without making it crash on most of them, try this patch which I quickly created while debugging this stuff :-).

There’s still much work. The stuff in present/libpresent/, for example, needs love!

A few weeks ago I blogged about a multi-alarm aware alarm notification dialog in Evolution. Now Evolution’s HEAD has reopened, these patches have been accepted by Rodrigo Moya and are now availabe in Evolution’s CVS.

It looks like this:

I hope people will like this improved alarm notification userinterface. You can suggest HIG specifics about it on the evolution-hackers mailinglist.

I decided to go to GUADEC this year. My employer was also convinced it’s a good idea so I’m even getting sponsored for it. Traveling expenses, food, the hotel and the conference price for professional GNOME Foundation members are being payed by my employer. Thanks :-).

I’ve been to all FOSDEM‘s (Brussels). I’m hoping the GUADEC meeting will be even more technical. So even more programmers and even more interesting discussions and presentations from GNOME developers. If I checkout the planned schedule, I’m confident I’ll be satisfied.

One of my colleagues, Bjorn Monnens, will be joining me. He’s mainly interested in the Nokia, Eclipse and Java talks. He works as a Java and .NET developer for our GIS-group. So that’s probably his reasoning. He’s also getting interested in different opensource (free software) projects. So it isn’t a bad idea to invite him, right?

I’ll be visiting Keiths talk about fdo, Fresh and new evolution maintainer Harishs Eplugin talk, Owens talk about Cairo, Wims talk about GStreamer, Roberts fast and slick talk, Damiens talk about gnomemeeting (so that I can explain my girlfriend why it often doesn’t work), Jons talk about Beagle, Federicos talk about Mono, Thomas talk about Flumotion and probably many many more lightning talks and/or other non scheduled talks.

Okay. I learned this the hard way: Never use the pthread API in glib applications. Use the GThread stuff! For example will the GList type reuse memory from the memory pool (the GAllocator stuff). This memory pool is locked using G_LOCK macros. If you didn’t launch g_thread_init(NULL), those macros won’t really lock the code-parts that ought to be locked. Therefor won’t the GList be threadsafe. So filling multiple glists in multiple threads can (and probably will) cause race conditions.

The GThread stuff will wrap pthread functions on platforms that use pthread as threading implementation. It doesn’t support the pthread_cancel() function. But then again, is the cancellation of threads not a clever thing to do. It’s better to implement cancelling of parallel procedures by checking some condition that might have been set by another thread (and returning or g_thread_exit in the thread that is to be cancelled).

I received my copy of “Linux Kernel Development” by Robert Love from Amazon. Started reading it. I even reached chapter seven by now! It’s a good book, easy and fun to read. For example when Robert starts to describe bottom halves (like) softirqs and tasklets and how important it is to use tasklets rather than softirqs. That chapter is a little bit subjective but for sure fun to read.

For example on page 96: To further confound the issue, some people refer to all bottom halves as software interrupts or softirqs. Ignore those people. They run with the same crowd that named the BH and tasklet mechanisms.

And on page 97: Some people also confusingly call all bottom halves “softirqs,” but they are just being annoying.

Okay. I get the point :-). Not all bottom halves are softirqs! Your code should be using tasklets (unless you have a really good reason for using softirqs) and tasklets are in fact build upon softirqs. (Did you really need 20 pages to explain that Robert?)

Going to start reading about Work Queues now.