Feed aggregator

I prefer the kubuntu experience, but I just had to get this.


Sorry about the blurred picture - stupid telephone camera.

Not a lot of people know about this but I was originally planning to have basic window tiling support added to KDE 4.2 so that I could receive feedback on it for when I write the full thing for 4.3. With the KDE 4.2 release schedule moved forward 2-3 weeks however it looks like I will not have that luxury anymore as soft feature freeze is now only three weeks away. For those that received word that 4.2 would have tiling support I must apologise, but at least now I can dedicate the entirety of my time on the full version instead of having to spend a few weeks getting the half-complete version polished enough for release. By the time KDE 4.2 is available to the public the kwin-grid work branch should be usable enough for those who really benefit from a window tiling environment, you will just need to compile it yourself or hope your distribution backports it for you. =)

Now enough of that, lets see what's changed in KWin since my last blog article (Warning, lots of "added" words ahead):

• Added an automatic layout mode to the desktop grid effect. This just chooses a grid ratio that doesn't cause the desktops themselves to be excessively scaled away into oblivion if you have a really wide or tall desktop layout.
• Added an advanced mode to the wobbly windows configuration panel. Here you can control a few of the more involved physics settings if you truly want your windows to wobble beautifully. Not everything was added though, does anyone really need sixteen different sliders?
• Also added settings to disable wobbly windows for movement or resizing separately from one another. This was added mostly for the people with slow window resizing when compositing is enabled.
• Added a setting to dim the desktop with the dim inactive effect, and
• Added ability to change the opacity of background windows when using the box switch effect. It's also now possible to not elevate the selected window when walking through the windows if you so desire (Similar to what the non-compositing window switcher does).

Until next time.

... definitely not today.

I can't do anything in the Ubuntu wiki (bug report) ... yeah Konqueror is only default browser on Kubuntu, why would we do QA for it

I just learned that when you install the java plugin it will pull in firefox, which will pull in ubufox, which will pull in synaptic, which will pull in half the main archive.
And why do you think is that?
Depends: libasound2, libx11-6, libxext6, libxi6, libxp6, libxtst6, sun-java6-bin (= 6-07-4ubuntu2), firefox | firefox-2 | iceweasel | mozilla-firefox | iceape-browser | mozilla-browser | epiphany-gecko | epiphany-webkit | epiphany-browser | galeon | midbrowser | xulrunnerNotice anything?

Now I am feeling rather stupid because I actually started work on ubuntu-kde-default-settings making KDE 4 apps look like native Ubuntu/GNOME ones, too bad I don't feel like continuing it

... definitely not today.

I can't do anything in the Ubuntu wiki (bug report) ... yeah Konqueror is only default browser on Kubuntu, why would we do QA for it

I just learned that when you install the java plugin it will pull in firefox, which will pull in ubufox, which will pull in synaptic, which will pull in half the main archive.
And why do you think is that?
Depends: libasound2, libx11-6, libxext6, libxi6, libxp6, libxtst6, sun-java6-bin (= 6-07-4ubuntu2), firefox | firefox-2 | iceweasel | mozilla-firefox | iceape-browser | mozilla-browser | epiphany-gecko | epiphany-webkit | epiphany-browser | galeon | midbrowser | xulrunnerNotice anything?

Now I am feeling rather stupid because I actually started work on ubuntu-kde-default-settings making KDE 4 apps look like native Ubuntu/GNOME ones, too bad I don't feel like continuing it :-(

:-)

Techbase has proven to be a great resource for the KDE community of developers, administrators and project coordinators. It didn't offer much of anything to users, however, and that was purposeful: Techbase was designed with a clear purpose in mind, and I believe that to be a significant reason why it has been as successful as it has been.

To fill the user gap, however, the Community Working Group (CWG) members have started work on a wiki driven site much like Techbase but designed specifically for user appropriate content. It is not meant to replace documentation, but rather to augment it and provide a working communications channel for the KDE community of users about KDE as it develops and progresses.

Anne Wilson and Juan Carlos Torres of the CWG have been working on getting content on the wiki, working towards a structure for the content, etc. It's a huge task, however, and now that they've started the work and have set a pace for their efforts it is time for other interested people to join up and help make this new resource the amazing place it needs to become. Two people can't do it on their own, but a few dozen surely can and I know for a fact we have way more than that number of interested, concerned users.

So without further ado, say hello to Userbase!

Remember it is in a very early state right now and not a finished product by any stretch of the imagination. You can help Userbase achieve greatness sooner by emailing the Community Working Group who is hosting the Userbase project efforts and start adding content to the wiki.

Update: I just found out that the log in system for Userbase is still under construction. Danimo and Pino informed me that they having implemented only OpenID based authentication for Userbase, but that it's not fully exposed yet. Assuming this goes well, Techbase will follow suit later. Good news on all fronts, really, but one more bit of "early days, not completely ready" to deal with on Userbase as authentication gets ironed out.

So there have been quite a few people asking what is happening with KDE 4.1 on Gentoo. There are still no ebuilds in the tree for KDE 4.1 and to be totally honest I have not been actively developing the KDE ebuilds until recently (took quite a long break). It is however something I really feel that we should have and so I have been working with a few other developers and interested users on the new ebuilds in an overlay. I think these ebuilds are almost ready and I am very eager to get them into the tree.

So what have we been doing? We have been working on a set of ebuilds that can be used with portage 2.2, there were a few setbacks when it became clear that EAPI 2 was not likely to be allowed in the tree in the very near term, but good noises are being made on the mailing lists. I think one of the big changes I have been working on is bringing KDE back into the normal file system hierarchy. This means that you will not be able to slot multiple minor versions of KDE such as 4.1 and 4.2 together.

The loss of slotting also means that ebuild maintenance will be significantly easier, externally released packages will automatically relink to the latest kdelibs for example. It also means that users will not build up multiple copies of minor KDE versions such as 4.0, 4.1, 4.2. I think for the majority of our userbase (myself included) this situation is undesirable with few benefits for normal use of KDE. So having one slot for KDE 4 and upgrading in the normal fashion seems to be very beneficial.

This has not been universally accepted as a good thing. I personally think our main tree KDE should always be installed in the normal FHS hierarchy as upstream seems to intend it. I see little benefit for most users, and many developers not closely involved in KDE development, to having multiple minor versions installed. Also having external KDE packages such as k3b and amarok installed in /usr but linking to libraries in a KDE prefix has never been optimal.

My vision is for a default in-tree KDE that installs into the normal FHS tree as Gnome, Qt 4, XOrg etc do. Developers, power users and those that like to tweak would still be free to install slotted versions of KDE in KDE prefixes alongside the FHS KDE. They could also remove the FHS KDE and just use slotted versions too. We discussed during KDE 3.5 bumps how the current slotting was not ideal.

I am certainly open to opinions. It would be good to get wider feedback from the community on which direction they would like to go in and why. This will not affect KDE 3.5 slotting with KDE 4 - they will always be slotted. It will make maintenance of external KDE packages simpler as everything will be in the same tree. Overlays with ebuilds in alternate slots and prefixes are of course still easily possible and people could continue using KDE in this way.

Currently this work is taking place in an overlay. I am quite honestly exhausted discussing why this is or is not a good idea. I hope I have made my position clear and why I think it is a good thing for our user base. I really want to get KDE 4.1 into the tree as soon as possible. I do feel that these changes should be pushed into the tree, defaulting to an FHS compliant install and using a KDE prefix if requested.

What are your thoughts (other than get KDE 4.1 in tree now - we are working on that)?

Yesterday, Adriaan blogged about the Antikythera mechanism. This is a fascinating piece of early machinery. Read all about it on the wikipedia page.

Ade called for a plasmoid to be created of it and I think this is a good idea. So I looked around on the web if there is some software simulating the mechanism. I found a webpage where you can download an OpenGL implementation that is compiled for windows. You can run it with Wine on a i386 Linux machine. The source code is not available on the site. I was struck by backside of the mechanism. The inward spiraling lines look very much like the Akonadi clock Cornelius blogged about some time ago.

During Akademy 2008, we sat down with Fabrizio Montesi who's working on JOLIE integration in KDE (and Plasma in particular). He explained the mechanics of the technology and what it can do for KDE. Read on for the interview.

Hi Fabrizio! Can you introduce yourself?

Hi! My name is Fabrizio Montesi, I'm Italian and I work as a computer professional. Recently I have founded (together with my colleague Claudio Guidi), italianaSoftware s.r.l., a company that centers its business around service-oriented software solutions made with JOLIE.

At Akademy you gave a talk about JOLIE, the technology you are working on. Can you explain the purpose of JOLIE?

Well, JOLIE is a programming language for service-oriented computing. It is mostly about communication between applications. Usually, applications have communication mechanisms within themselves - in Qt this is done with the signal-slot mechanism. What it does is essentially this: suppose you have a button, and you click it. That button then tells a part of the application to start doing "its thing", e.g. display an image. Simple.

Now, you might want to have something happen in another applicaton if you hit that button; that's covered in the software world as well, e.g. on Linux/UNIX by DCOP and D-Bus, on Windows by DCOM. The problem is that these technologies are pretty specific and each one has its own set of limitations (among which the most prominent is that some don't work over networks). JOLIE tries to overcome all these limitations and offer a very simple solution for doing what should indeed be simple: "just send this message to that application in that computer".

So JOLIE is like a network-enabled D-Bus?

Well, no, it's more than that. D-Bus is a framework designed to enable application integration in the desktop. JOLIE is a fully-fledged programming language for managing service-oriented architectures and technologies. With JOLIE, you can write flexible service "orchestrators" and compose other services, independently of their technology, in order to gain sophisticated functionality.

Now that sounds interesting, "orchestrators" and composition of services, but what does it mean?

Let me explain this by giving an example. Say that you want to write an application which allows you to buy stuff at stores. You already have services for accessing your bank and said stores, but you lack the application that actually composes these services to make the money transfer and make the store order for you. Then you write an "orchestrator" to combine the services, which would coordinate the services in order to do what you wanted. Note that a JOLIE orchestrator is very easy to write and can make use of any store and bank service that are based on a technology supported by JOLIE (like, for instance, Web Services, REST, and so on).

Which is what JOLIE is all about - a generic programming language for programming any kind of service or service-oriented architecture, independent of the underlying protocols (JOLIE abstracts the communication away, e.g. D-Bus apps can communicate with a SOAP-based service through JOLIE). And of course, this is incredibly easy to use. In most other languages you'd find it is very hard to write service-oriented code, but JOLIE is all about services. Of course it also provides the normal flow control functions (like the if-else, if-then, while, for, foreach statements), and it adds some specific and powerful tools to handle distributed workflows. The latter help in compensating for network lag and help the programmer to handle complex asynchronous communications. And finally, JOLIE is very safe while doing this, due to the academic work being done.

So people can quickly write orchestrators to let any number of services work together in any way they want. Now you mentioned academic work, can you tell us a bit more about that? This is actually a research project, right?

Yes, it is. Writing distributed apps is very difficult to get right. JOLIE is based on SOCK, a process algebra for service-oriented computing, so you can make mathematical proofs on JOLIE applications. For example, we are currently developing a tool for checking distributed systems for possible deadlocks. Another advantage is that you can be sure your application does what it is supposed to do if something goes wrong in some part of your distributed workflow.

Let me give an example of that last point as well. Say, in the previous example, you're ready to order the bank to transfer the money and receive the store receipt. You want this to go fast, so you do two things at once: start the money transaction and wait for the store receipt. Say that the waiting-for-receipt activity receives an error. In that case, the money transaction must be cancelled: you don't want to lose your money for a product that will not be sent to you, right? But you don't want to cancel it at some unknown point. You want to ensure nothing happened to your money at all. So you add a little "revert when an error comes in" thing to the money transaction code. Now, in case of an error from the store, JOLIE will guarantee three things:

• if no money has been transferred yet, the transaction won't begin at all;
• if the transfer has already started, JOLIE will allow it to finish, then start the reverting action;
• if the transaction has finished already, JOLIE will revert it right away.

All this is based on lots of mathematical work to ensure and prove that this works properly. This is a good example of how SOCK is useful in our development process. When we face a very complicated and general problem, we can first build a mathematical framework for solving that problem in SOCK.

After developing the whole theoretical framework and proving that it works, we transfer the results into JOLIE.

Interesting. So this is an implementation of sound, theoretical work. But why in KDE?

Well, I wanted to bring the benefits of service-oriented computing to desktop users. There are many services out there on the web and in user computers (every D-Bus-enabled application can indeed be seen as a service), but they don't communicate with each other. JOLIE can help with this. There are a few commercial frameworks which do comparable things, but nothing free, nor very good and complete. Now for this to work, I needed to find an organization which would be interested to work on it. I needed a real, open community to work with, so Vista and Mac OS X were off the list... Vista wouldn't have been very good from a technological standpoint either. I further needed the community to be flexible, interested and pro-active.

I was following the evolution of open desktop technologies since a long time. KDE has some amazing, cutting-edge technology, and you don't write that kind of stuff without many open discussions. And from reading the blogs I was convinced this community works great, is open and flexible, exactly what I was looking for. For me, GNOME seemed much less flexible, both in terms of people and technology. More importantly, KDE showed with the KDE4 series that the project is not afraid to take a step towards innovation, regardless of the hardships that you can meet along the way.

And with Plasma, I was sold: it felt like a natural choice. JOLIE is based upon a philosophy which emphasizes generic solutions over specific ones in order to create something as flexible and powerful as possible. The same applies to Plasma, and as i've seen in KDE development, it is the vibe you see in pretty much all of KDE.

OK, so you decide to work with us. How did that go?

Well, I sent an email to Aaron Seigo and he answered back enthusiastically. He happened to have been thinking on very similar topics, but he bumped into the issues JOLIE is built to solve - it's hard to write, compose and communicate with services. On top of that, there are a lot of different communication mechanisms currently used by services all around the world: how to be able to use all of them? These issues are far from trivial, so Aaron was happy to work with us to take advantage of JOLIE. He invited me to come to Tokamak, the Plasma meeting, which I and Claudio did. There we (JOLIE and Plasma teams) found that we clearly had matching ideas. JOLIE and Plasma looked like the perfect match to offer users a flexible and powerful service-oriented experience. So we started a twofold collaboration, aimed to unite the pragmatic world of KDE and the academic world from which JOLIE comes.

Cool. And now you're at Akademy... How did you end up here, and what do you think about it?

Well, Aaron and Kevin Ottens invited me to send a talk proposal for Akademy, which I did. I must say Akademy is very interesting, though also very tiring. You find so many great people to speak with here, and I actually did that for the whole time. I've never had so many well informed questions before, too... before and after the presentation! Actually, I think the majority of questions I had during all the presentations I ever gave were asked at Akademy. Of course, this is because there are so many knowledgeable, interested developers here. Many people here will (or already have) actually put some of these ideas to work, so they have questions about it. Getting so much relevant feedback in an academic conference would be unusual: it is more difficult to reach technological collaboration between many different and separated projects. So this has been really great, i've gathered many ideas and issues i'm going to take with me, think about, and work on. And i've left something to think about for others, too.

From what I understood, there is already some code?

Yes, that's true. We are already writing a Plasma::Service layer which acts as a bridge to MetaService (a JOLIE orchestrator) on the JOLIE side. This means you can access all services supported by JOLIE in Plasma. You would have to write an orchestrator to compose services, like in the previous e-commerce example. But as you can read in my blog, there are some cool code examples. One of them is Vision, a tool which can distribute presentations real-time over several computers. That way several people can view the presentation on their screens synchronized with one another. This even works in a peer-to-peer way, where each of the PC's can distribute it even further. Look in my blog for a screencast!

Something else, not available already but we're working on, is exporting data engines from one system to another. So, for example, the "Time" engine on one computer can be queried as a JOLIE system from a remote PC. All of this is difficult to do right in terms of security, but opens a huge number of opportunities. Think about how easy it will become to start writing remote control Plasmoids, or getting access to a huge amount of information (that of services on the internet) from your desktop.

Do you have any concluding words for the KDE community?

Yes. i'd like to thank (and praise) the KDE community for its openness. I felt at ease from the start, met enthusiasm and innovative ideas, and discovered that the people behind the project are friendly, open-minded and a lot of fun to pass your time with.

During these months I have seen that the KDE project is truly innovation-driven. Open-source and community openness are what make this possible, and KDE is showing that it is capable of handling all this (with the KDE e.V., the meetings, and so on). Keep rocking!

Thank you for the interview!

Thank you for interviewing me. And who knows... see you at next Akademy!

Rejoice ye unwashed heathen! A new installable package for Amarok 2 on OS X is available. It weighs in at about 300 MB but don't let the size allow you to ignore the obvious: there's now a new installable package for Amarok 2 on OS X. Do I sound like Steve Jobs yet?

The OS X savvy among you will immediately realize the absence of, and probably want, a .app bundle. Unfortunately the enterprising young lad who has slaved away on this for eons couldn't get it to work. You get the installer instead. Speaking of which, grab it @ http://illogic-al.org/Amarok_2X.dmg. As an extra special bonus you can try out some KDE programs too.

For those who don't already know these are developer packages. That means that you should only download these 300 MB of awesomeness if you are willing to test and give feedback. That means using http://bugs.kde.org to report what's broken. Obviously if you want to contribute beyond bug reporting that's welcome too I suppose we need a wiki page explaining how to do that ...

By the way, remember when I said these packages were for OS X. I lied. They're for a certain version of OS X on certain hardware. Leopard and Intel only. All others need not apply. Now if you'll excuse me I've got to boot into Tiger and fight with gcc 4.2. Cheers.

Here's one for the road!

I was in Athens this week to do work-work and put in some touristing; next week is more work-work and sitting on beaches. Work hard, play hard is the motto.

Today I saw the Antikythera mechanism. It's amazing (why isn't there a plasmoid for it?) in its execution and delicacy. I could go on and on about Athens as a place to visit and see things, but there are other, better, sources -- including Diomidis Spinellis's Guide to Athens for Visiting CS Folk.

Any other KDE folk in Athens, stop by in Vouliagmeni in the coming week and there will be beer almost like it's Akademy (well, if you really want to achieve that effect, stop by the Craft brewery on the way, ok?).

I began this series of tutorials some time ago already, and all of them covered light issues. We used tools like levels, curves, or white balance adjustment.

I wanted to approach other type of issues this time, but I think light issues would be rather incomplete if I didn't address contrast, brightness and colors adjustments. Possibly you are somewhat familiar with these already, but I think they're worth covering.

So lets begin. Fix da colors!

Read more »

Original post.

As some of you know, I'm working on a migration project to software libre of some municipalities close to Málaga. Meanwhile, we have been contracted as part of a group of companies that are migrating the economic department of the Extremadura Regional Goverment. So since March 2008, migration is a familiar word to me. There are some things that are common to many Public Administrations in Spain that has to be taken in consideration at the very beginning so the picture you will have to face can be understood.

Since Microsoft architecture has limitation in controlling the enviromet, and it is so expensive to do so, each technician, each user, has customiced his/her enviroment (department, server, desktop, network...) so much that migrating to any plattform (or even updating) can become a nightmare. The enviroment is heterogeneous.

Regional and local Public Administrations has grown so much in Spain the last 15 years that it has been imposible for most of them to stablish a general and strict politic related with technology and digital services.

Another key factor is that, until citizens has began to demand digital services, technical departments were underdimensioned and overcharged with low level job, due to that lack of that general politic and the way Windows is designed. Old school politics know everything about building houses (the major bussiness in Spain) but nothing about technology. That demand, plus a new generation of politics, are beginning to change this situation.

To migrate, a lot of data that is supposed to be known is not, so you have to collect it.

With this enviroment...linux has risen as an alternative of how things have been done in the past. It brings many advantages to solve some of the problems we have suffered, but not all of them. In fact, the deppest problems are not platform related. Let's talk about some of those (personal and general ones).

Migrating to linux means an enormous effort for a Public Administration. It has to be well done, by professionals. Big amounts of money and time are needed so usually politics decide to, also, add new services and new procedures. Migrating is not enough. A deep change is needed. So you end up not just migrating to linux, but improving the hold system, adding new services, new apps, new network topology, new methods, etc. The original migration project grows and grows adding pressure and stressing resources. Letting you go is a natural feeling when you believe in software libre and demand a change, but is a wrong way of approaching such a project. Migrating and improving are different concepts. Sometimes you need to take one step to one side (or even back) to be able to take many steps forward in the future.

I'm afraid many of the people I'm involved here in the south of Spain are putting into linux so much illusion that, when reality faces up, they will be a little dissapointed with the result. It is hard to reach 100% of the objetives. Without noticing it, I have ended up telling people to move slow, to be careful with the expectations, to make firm steps instead of running, to improve quality instead of quantity. Working in pioneer projects involve a lot of risk, so you usually need to be intrepid. But when people around has so many expectations, believing so much in what we are doing, in what free software can do for the people, this attitude has to turn into prudence. This is not usually well accepted. People begin to question if you really believe or you have doubts. For them, it is not a question of methodology or resources but a question of faith. So you have to stay strong to stay away of that big wave of illusion and keeping everybody on the ground. It is as risky as it can be an eviroment where no one around believes in software libre. I am used to this second one. I'm a newbie in facing the first one. So I'm learning a lot.

We have developed a new methodology and some simple tools to collect the data we need in order to define with accuracy the migration project. Since Public Administrations have hundreds of computer, not much information from other projects can be used. Scalability is a tough concept. Working in mEDUXa, the linux edu distro from the Canary Islands, have helped me a lot. Still there are many big differences. Schools are not regular Administrations, of course.

We are making a deep inventory of machines and apps installed and interviewing each and every public worker in its own desk, so they show us how they use the computer, share the information and interact with other workers, for example. I'm been doing many of those and it is beeing really interesting. Many conclusions are showing up that weren't expected. It is taken a lot of effort but it is totally worth it. It has been a money well invested.

After collecting all the the data, a good analysist has to be done (it is being done). Then, the real migration project begins. Technical solutions are well known. Most of them are well tested and have success stories behind them. We are not going to invent anything new in this area, I think by now. The risk is doing the migration smooth and softly, not stopping the services and making everybody feel confortable with the solutions. All this with limited resources and time.

For the Public Administrations involved, the analysis of the migration project will be the first time they think about the technology they use and the procedures the follow in a general approach, without names and surnames of any particular solution (take this as a wish). For many of them it will be the very first time they will be able to take key decisions related with technology. That is why it is important to give them all the information we can. They have to take their own decisions and they are not used to do this in technology. They usually just buy products (so decisions).

This is something some don't follow. I believe that trying to convince people to use this or that because you say it, because you are the "expert", is wrong. That's what have happened before (with propietary software) and the reason why many customers are so suspicious about software libre. In Public Administrations this is the root of many of the reactions against it (in politicians and, specially, in public workers). It is not that they don't trust the technical solutions we offer, they simply do not trust us. Our messege has a 100% commercial motivation form them.

After 6 monthes working here one clear conclusion has risen. Migrating Public administrations to GNU/Linux is way more difficult and more expensive than many people expected, but is possible. Much more than that...it is needed.

A wish ...

After I finish my job here it would be great to travel to other countries to get involved in Migration Projects to keep learning about different enviroment, facing new challenges, working with new and different people. Big deployments and migrations are a very interesting area to get involved. I've been working on it since 2005 and I feel I know nothing about it yet. Also, helping to spread GNU/Linux (software libre in general) makes me feel good. I like my job and I know I'm lucky.Agustín Benito Bethencourt (aka Toscalix) Blog in spanish: http://abenitobethencourt.blogspot.com Grupo CPD: http://www.grupocpd.com

In my last blog I found out that Qt is being evil when using QPainter::eraseRect() with a QImage based textured brush. How evil? Well, calling QPainter::fillRect() with the same brush results in something like a 30-50% speedup while achieving the exact same results. Not only that, but the QPainter::eraseRect() codepath makes QImage not thread safe for painting outside the main thread because it is silently using QPixmap behind the scenes. However, this isn't the whole story. I was surprised that even with all this fixed the algorithm is still not optimal.

In fact, you can see a very substantial increase in performance using a fractal based filling and tiling algorithm. Here are the results for a 10000x10000 QImage for tiling operations:

Algorithm       Brush              msecs
----------------------------------------
naive           checkered brush    1186
eraseRect       checkered brush    4445
fillRect        checkered brush    704
fractalFill     checkered brush    284


As you can see, the QPainter::eraseRect() is evil. Just changing to QPainter::fillRect() provides a very big decrease in the amount of time to paint a pattern. However, the fractalFill algorithm is still much faster. It cuts that time by more than half. So what is this algorithm?

void ...
{
    QImage image(WIDTH, HEIGHT, FORMAT);

    /* create our pattern */
    QImage base(20, 20, FORMAT);
    QPainter p1(&base);
    p1.setCompositionMode(QPainter::CompositionMode_Source);
    p1.fillRect(0, 0, 10, 10, Qt::gray);
    p1.fillRect(10, 0, 10, 10, Qt::white);
    p1.fillRect(0, 10, 10, 10, Qt::white);
    p1.fillRect(10, 10, 10, 10, Qt::gray);

    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);

    /* draw the pattern once at 0,0 */
    p.drawImage(0, 0, base);

    const int imageW = image.width();
    const int imageH = image.height();
    int w = base.width();
    int h = base.height();
    while (w < imageW || h < imageH) {
        if (w < imageW) {
            /* Copy and draw the existing pattern to the right */
            p.drawImage(QRect(w, 0, w, h), image, QRect(0, 0, w, h));
            /* Update width of our pattern */
            w *= 2;
        }
        if (h < imageH) {
            /* Copy and draw the existing pattern to the bottom */
            p.drawImage(QRect(0, h, w, h), image, QRect(0, 0, w, h));
            /* Update height of our pattern */
            h *= 2;
        }
   }
}

This would be even faster if Qt were smarter about the overloads of QPainter::drawImage(). The real inline drawImage overload that does the heavy lifting takes a QRect. This forces the other overloads to create and destroy a QRect which is minimal overhead, but in a tight loop this cost starts starts to grow.

Implementing this algorithm and seeing the improvement led icefox and me to investigate whether we could use the same idea to speedup the general case of QPainter::fillRect() with a solid brush. We didn't have much hope it could be sped up as this is a fundamental painting routine in Qt, but surprise this algorithm does give a nice speedup

Algorithm       Brush              msecs
----------------------------------------
fillRect        solid brush took   508                                                                                          
fractalFill     solid brush took   293

This is a large performance increase in a fundamental painting routine. This same idea could be used inside of QPainter::eraseRect(), QPainter::fillRect(), and hopefully a future QPainter::drawTiledImage(). Hopefully the Trolls can investigate and see if something like this should go into Qt 4.5.

Here are the two methods side by side:
QImage fillRectSolid()
{
    QImage image(WIDTH, HEIGHT, FORMAT);
    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.fillRect(QRect(0, 0, WIDTH, HEIGHT), Qt::red);
    return image;
}

QImage fractalFillSolid()
{
    QImage image(WIDTH, HEIGHT, FORMAT);

    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.fillRect(0, 0, 1, 1, Qt::red);

    const int imageW = image.width();
    const int imageH = image.height();
    int w = 1;
    int h = 1;
    while (w < imageW || h < imageH) {
        if (w < imageW) {
            p.drawImage(QRect(w, 0, w, h), image, QRect(0, 0, w, h));
            w *= 2;
        }
        if (h < imageH) {
            p.drawImage(QRect(0, h, w, h), image, QRect(0, 0, w, h));
            h *= 2;
        }
   }
   return image;
}


A few notes: this speedup only occurs with non-alpha channel QImage::Format's or at least pre-multiplied. With the inline overloads rearranged again it'd be even faster. I hope this is useful. Read on for the source to all of these tests...

Here you go. Happy playing!

#include <QtGui>

#define WIDTH 10000
#define HEIGHT 10000
#define FORMAT QImage::Format_RGB16

QImage naiveCheckered()
{
    QImage image(WIDTH, HEIGHT, FORMAT);
    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    int w = image.width();
    int h = image.height();
    QBrush brush(Qt::gray);
    for (int j = 0; j < h; j+= 10)
        for (int i = (j % 20 == 0) ? 0 : 10; i < w;i += 20)
            p.fillRect(i, j, 10, 10, brush);

    return image;
}

QImage eraseRectCheckered()
{
    QImage image(WIDTH, HEIGHT, FORMAT);

    QImage base(20, 20, QImage::Format_RGB16);
    QPainter p1(&base);
    p1.fillRect(0, 0, 10, 10, Qt::gray);
    p1.fillRect(10, 0, 10, 10, Qt::white);
    p1.fillRect(0, 10, 10, 10, Qt::white);
    p1.fillRect(10, 10, 10, 10, Qt::gray);

    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.setBackground(QBrush(base));
    p.eraseRect(QRect(0, 0, image.width(), image.height()));

    return image;
}

QImage fillRectCheckered()
{
    QImage image(WIDTH, HEIGHT, FORMAT);

    QImage base(20, 20, QImage::Format_RGB16);
    QPainter p1(&base);
    p1.fillRect(0, 0, 10, 10, Qt::gray);
    p1.fillRect(10, 0, 10, 10, Qt::white);
    p1.fillRect(0, 10, 10, 10, Qt::white);
    p1.fillRect(10, 10, 10, 10, Qt::gray);

    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.fillRect(QRect(0, 0, image.width(), image.height()), QBrush(base));

    return image;
}

QImage fractalFillCheckered()
{
    QImage image(WIDTH, HEIGHT, FORMAT);

    QImage base(20, 20, FORMAT);
    QPainter p1(&base);
    p1.setCompositionMode(QPainter::CompositionMode_Source);
    p1.fillRect(0, 0, 10, 10, Qt::gray);
    p1.fillRect(10, 0, 10, 10, Qt::white);
    p1.fillRect(0, 10, 10, 10, Qt::white);
    p1.fillRect(10, 10, 10, 10, Qt::gray);

    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.drawImage(0, 0, base);

    const int imageW = image.width();
    const int imageH = image.height();
    int w = base.width();
    int h = base.height();
    while (w < imageW || h < imageH) {
        if (w < imageW) {
            p.drawImage(QRect(w, 0, w, h), image, QRect(0, 0, w, h));
            w *= 2;
        }
        if (h < imageH) {
            p.drawImage(QRect(0, h, w, h), image, QRect(0, 0, w, h));
            h *= 2;
        }
   }
    return image;
}

QImage fillRectSolid()
{
    QImage image(WIDTH, HEIGHT, FORMAT);
    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.fillRect(QRect(0, 0, WIDTH, HEIGHT), Qt::red);
    return image;
}

QImage fractalFillSolid()
{
    QImage image(WIDTH, HEIGHT, FORMAT);

    QPainter p(&image);
    p.setCompositionMode(QPainter::CompositionMode_Source);
    p.fillRect(0, 0, 1, 1, Qt::red);

    const int imageW = image.width();
    const int imageH = image.height();
    int w = 1;
    int h = 1;
    while (w < imageW || h < imageH) {
        if (w < imageW) {
            p.drawImage(QRect(w, 0, w, h), image, QRect(0, 0, w, h));
            w *= 2;
        }
        if (h < imageH) {
            p.drawImage(QRect(0, h, w, h), image, QRect(0, 0, w, h));
            h *= 2;
        }
   }
   return image;
}

void makeTab(QTabWidget *w, const QImage &image, const QString &text)
{
    QLabel *label = new QLabel;
    label->setPixmap(QPixmap::fromImage(image));
    w->addTab(label, text);
}


int main (int argc, char **argv)
{
    QApplication application (argc, argv);

    qDebug() << "starting tests...";

    QTime time;
    time.start();

    QImage naiveCheckImage = naiveCheckered();
    qDebug() << "naive \t\tcheckered brush took\t" << time.restart();
   
    QImage eraseRectCheckImage = eraseRectCheckered();
    qDebug() << "eraseRect \tcheckered brush took\t" << time.restart();

    QImage fillRectCheckImage = fillRectCheckered();
    qDebug() << "fillRect \tcheckered brush took\t" << time.restart();

    QImage fractalFillCheckImage = fractalFillCheckered();
    qDebug() << "fractalFill \tcheckered brush took\t" << time.restart();

    QImage fillRectSolidImage = fillRectSolid();
    qDebug() << "fillRect \tsolid brush took\t" << time.restart();

    QImage fractalFillSolidImage = fractalFillSolid();
    qDebug() << "fractalFill \tsolid brush took\t" << time.restart();

#if 0
    QTabWidget w;

    makeTab(&w, naiveCheckImage, QLatin1String("naive checkered"));
    makeTab(&w, eraseRectCheckImage, QLatin1String("eraseRect checkered"));
    makeTab(&w, fillRectCheckImage, QLatin1String("fillRect checkered"));
    makeTab(&w, fractalFillCheckImage, QLatin1String("fractalFill checkered"));
    makeTab(&w, fillRectSolidImage, QLatin1String("fillRect solid"));
    makeTab(&w, fractalFillSolidImage, QLatin1String("fractalFill solid"));

    w.show();
    return application.exec();
#else
    return 0;
#endif
}

Somehow i managed to forget to announce here we are looking for organizers for this year KDE Spain users and developers meeting. If you are interested have a look at http://www.kde-espana.es/akademy-es2008/ubicacion.php. We are accepting proposals up to september 15th.

There is one thing of Tiny SVG1.2 that I really like. It is the possibility to embed audio and video. For video you can do transformations, filters and the usual stuff of SVG. TinySVG1.2 is popping up in more specs and recently I began to read DIMS again and well and thanks to the support of GMIT I had a go at it.

This shows parts of the TinySVG spec and the video was replaced with Code Rush. It is dog slow and needs some refactoring to SVGSMILElement and parts of the SVG RenderObjects to be merge able. The code should popup in my holger/dims branch soon.

Hacking on the WebKit codebase is so much fun that I seriously wonder if I want more of that...

I don't know for how long it has been available on-line, but I wrote another article for Qt Quarterly. For your reading pleasure: Designing Delegates.

Long time no blog as usual, so let's do some Plasma Quickies:
I've decided to do some love to two configuration dialogs, the wallpaper one and my loved ultrascary panel configuration "Thing". A while ago the configuration dialog had some problems.

The monitor preview looked ugly and deformed on widescreens, but most annoying thing it wasn't possible to chose the desired cropping or scaling method when in slideshow mode, so you had to chose between a single image or a series of horribly distorted images :)

now the thing looks like this:

Desktop activity and theme before the wallpaper section, because wallpaper configuration will be just one aspect, even secondary behind the concept of activity (oh and now there is a textbox t give them a name), explayned way better by aaron.
the monitor preview looks always good, not important what weird ratio your actual monitor has :)
All the controls are better aligned conforming the HIG and making less visual noise.
The folder list in the slideshow mode grows and shrinks when adding/removing folders, so there is no more a big white empty spot when it's empty :)

Now, my favourite configuration little monster, the panel configuration:

The size handles have little arrows that should be a bit more intuitive what is the min and what is the max and now the move and resize actions are buttons with a label, so should be more obvious how to do to move it and change the height, while the less frequent actions (or dangerous as in the case of remove panel) are moved in a submenu, so it gives a less crowded look.
And oh, now there is a config ui for the quite recent panel autohide too :) you can chose between normal panel always visible as is now, autohide or a panel not always on top, that can go under other windows.
It still looks a bit ugly but will be given a way more plasmalove(tm) look in the next days, stay tuned :)

You might remember some months ago that I posted a proof-of-concept plasma plugin for Mozilla Firefox on Linux. Well, a lot of tweaking later, we can now see a wide assortment of clocks in Mozilla Firefox on another platform (no prizes for guessing which one).

The most time consuming part of getting this up and running on Windows was actually just getting KDE compiled in the first place (emerge hates me). After that, it took about 10 lines of code and a few tweaks to CMakeLists.txt and it works.

Well, I say it works, but if I were more honest I’d say I managed to get the clocks to appear once out of many attempts in Firefox, and to grab a quick screenshot before I started trying to interact with them and brought everything crashing down. So, if you want to try this out yourself, be warned: you’ll need a lot of patience to do all the tweaking needed to get it working, and then it’ll still eat your babies.

Source code is in the same git repository as last time. See the README file included for barely-comprehensible instructions on how to destroy your soul.

When I blogged about this originally, there were lots of comments from people worrying about the security implications. I’d like to write about that in more detail, but I don’t have enough time, so it will have to wait for another day. For now I’ll just point out one thing: it is only a proof-of-concept at this stage. Obviously if this ever becomes a finished product, there will be security in place to stop plasmoids from the web interacting with your local computer in inappropriate ways - it will not work like Microsoft’s ActiveX, but much more like Adobe Flash.

Now that kwebforms is mostly functional and working let me talk about its future. We all know that kwebforms is a web application, it is written in C++ and it might become rather complex as new features are added but how to manage that complexity?

At the moment kwebforms is developed using Pion::Net, a C++ network library which abstracts things a little by using concepts like web services and such.
While this seemed sufficient for a while, now I feel that something is missing.
My plans are a bit greater and I want to make the application easier to develop and less bloated.

So I began wondering if it was worthy to create a framework allowing me to develop resource-oriented applications. And this is when REST comes to play. It is an excellent architecture to write resource-oriented applications which let me choose the communication protocol (and the transport protocol) between parts (unlike SOAP or XML-RPC) and make CRUD operations on resources identified by URIs.

That's how the "nanogear" was born (what an ugly name, isn't it? In fact the name "nanogear" is related to an earlier attempt to create an easy-to-use FastCGI library in C++ similar to Java Servlets).

My plans aren't big for the short term: I published a whitepaper (available at [1]) with the components that should be finished before the first release, mainly the REST Api and the REST HTTP Implementation. The rest will come afterwards.

The REST Api will be mainly a port of Restlet [2], developed by Noelios Technologies. At the moment I'm finalizing the details on how my code will be licensed (even if some portions are already in subversion).

The project is hosted on Google Code (at [3]) but there's nothing functional right now. Any help is appreciated (a Google Account is needed, though). I have no plans to move the development out of Google Code since I have no funds to move that on a separate server (and I think that it's not needed at the moment).


[1] http://nanogear.googlecode.com/files/nanogear_whitepaper.pdf
[2] http://www.restlet.org/ 
[3] http://code.google.com/p/nanogear

Imagine if you will ... (ah, such a classic start! =) You are working on a work project involving Sarah and John and Marmaduke; you switch to working on your MySpace profile ... Let's call each state (the work project, MySpace fiddling) a "context" and changing between them a "context switch". What happens with the rest of the software running on your computer when you switch contexts? Answer: pretty much nothing. At least not automatically.

Compare with network connectivity. When you lose network connectivity, KMail stops fetching your mail, Kopete closes it's connections .. and when the network connectivity comes back, it all fires up again automatically. This is great because now the software is reacting to the environment it "lives" in.

Virtual desktops help somewhat as people can use them to aggregate related windows into contexts. But let's face it, there's only one Kopete window. Wouldn't it be great if you could tag Sarah, John and Marmaduke in your Jabber buddy's list with the "Workmates" tag? That way, when you switch back to the work project after you're done MySpacing, Kopete could re-arrange your buddy list to put those workmates at the top of your buddy list. The contacts widget in your panel or on your desktop could also switch the people they are showing.

To make software react to the user context in the environment they live in, we need a way to publish the user context and for the user to communicate "I am now doing $FOO" and "I am physically located in $BAR". This is similar to how Solid broadcasts changes in network status to KDE applications, but for user context.

In Plasma we have the idea of Activities. In 4.2 you can give your Activities names and Plasmoids can ask what the current Context is and do whatever they might want to do given that Context. Plasmoids are also notified via a Constraints update when the context changes.

For this to really fly, though, this contextual information needs to be accessible by software outside of Plasma itself. Nepomuk will be filling this role, and today a few of us huddled together on IRC for a quick meeting to wrap up a week's worth of discussion on the Nepomuk KDE mailing list about user context. Trüg, Hari and myself managed to align our schedules with one goal to achieve: come up with the initial ontology (fancy way of saying "organization definition", more or less) for context.

Over the next couple of days we'll be coding the start of a Nepomuk service for publishing and collecting information on the current context and I'll be hooking Plasma into it. This will allow other applications to see the various known Contexts and either automagically tag data with appropriate Contexts and/or let the user manually tag data. Going back to the Kopete and contacts widget example, once we can associated (or "tag") contacts in Akonadi with Contexts then Kopete and the contacts Plasmoid will be able to adapt in concert with Plasma.

We aren't going for auto-context switching yet, though we will be automating location changes and eventually hopefully be putting in some intelligence for detecting the user's current activity.

Fortunately for us, there's a lot of really good science that's already been done in this field for us to reflect upon and base our efforts on. We're also starting simple, though we intend to build as far as it makes sense to, as defined by real world user benefit. Which is to say that our odds of success are extremely high.

Once 4.2 is out, I'll be poking and prodding application developers to start making their applications context aware. (Application developers: you've been warned! ;) This won't make applications dependent on either Plasma or Nepomuk, they'll just work better when they are around. All that will be required is D-Bus, which is already a requirement for KDE 4 applications. But if Nepomuk is around then applications will be able to rifle through and get information on Contexts. Likewise, if Plasma is around then the user will be able to interact rather directly with the Context using their desktop shell.

As we develop the application API further, I'll blog more about it. Plasmoid developers can start having fun right now, though! =)