The above combination was never a painless experience, still at some point in past it seemed to be better to have a NVidia card on Linux then anything else, so I continued to buy them whenever my system was upgraded. Lately although it started to make me rather bad. I have two computers, one that is a 4 core Intel CPU with 8GB of memory, the other is a Core2Duo with 3GB. The latter is a Lenovo laptop. Both have NVidia, nothing high end (Qudaro NVS something and 9300GE, both used with dual monitor setup), but they should be more than enough for desktop usage. Are they?
Well, something goes wrong there. Is that KDE, is that XOrg, is that the driver? I suspect the latter. From time to time (read: often), I ended up with 100% CPU usage for XOrg. Even though I had 3 cores doing nothing the desktop was unusable. Slow scroll, scroll mouse movements, things typed appearing with a delay, things like that. Like I'd have an XT. I tried several driver version, as I didn't always have this issues, but with newer kernel you cannot go back to (too) old drivers. I googled, and found others having similar experience, with no real solution. A suspicion is font rendering for some (non-aliased) fonts, eg. Monospace. Switching fonts sometimes seemed to make a difference, but in the end, the bug returned. Others said GTK apps under Qt cause the problem, and indeed closing Firefox sometimes helped. But it wasn't a solution. Or there was a suggestion to turn the "UseEvents" option on. This really seemed to help, but broke suspend to disk. Turning off the second display and turning on again seemed to help...for a while. Turning off the composite manager did not change the situation.
Finally I tried the latest driver that appeared not so long ago, 256.44. And although the CPU usage of XOrg is still visible, with pikes going up to 20-40%, I gain back the control over the desktop. Am I happy with it? Well, not....
As this was only my desktop computer. I quickly updated the driver on the laptop as well, and went on the road. Just to see 100% CPU usage there. Did all the tricks again, but nothing helped. Until I had the crazy idea to change my widget theme from the default Oxygen to Plastique. And hurray, the problem went away! It is not perfect, with dual monitor enabled sometimes maximizing a konsole window takes seconds, but still in general the desktop is now usable. And of course this should also make me have more uptime on battery.
Do I blame Oxygen? No, not directly. Although might make sense to investigate what causes there the NVidia driver going crazy and report to NVidia.

So in case you have similar problems, try to switch to 256.44 and if it doesn't help chose a different widget style.

Now, don't say me to use nouveau or nv. Nouveau gave me graphic artifacts and it (or KDE?) didn't remember the dual card setup. Nv failed the suspend to disk test with my machine and doesn't provide 3D acceleration needed eg. for Google Earth.

> Read More... | Digg This!

The above combination was never a painless experience, still at some point in past it seemed to be better to have a NVidia card on Linux then anything else, so I continued to buy them whenever my system was upgraded. Lately although it started to make me rather bad. I have two computers, one that is a 4 core Intel CPU with 8GB of memory, the other is a Core2Duo with 3GB. The latter is a Lenovo laptop. Both have NVidia, nothing high end (Qudaro NVS something and 9300GE, both used with dual monitor setup), but they should be more than enough for desktop usage. Are they?
Well, something goes wrong there. Is that KDE, is that XOrg, is that the driver? I suspect the latter. From time to time (read: often), I ended up with 100% CPU usage for XOrg. Even though I had 3 cores doing nothing the desktop was unusable. Slow scroll, scroll mouse movements, things typed appearing with a delay, things like that. Like I'd have an XT. I tried several driver version, as I didn't always have this issues, but with newer kernel you cannot go back to (too) old drivers. I googled, and found others having similar experience, with no real solution. A suspicion is font rendering for some (non-aliased) fonts, eg. Monospace. Switching fonts sometimes seemed to make a difference, but in the end, the bug returned. Others said GTK apps under Qt cause the problem, and indeed closing Firefox sometimes helped. But it wasn't a solution. Or there was a suggestion to turn the "UseEvents" option on. This really seemed to help, but broke suspend to disk. Turning off the second display and turning on again seemed to help...for a while. Turning off the composite manager did not change the situation.
Finally I tried the latest driver that appeared not so long ago, 256.44. And although the CPU usage of XOrg is still visible, with pikes going up to 20-40%, I gain back the control over the desktop. Am I happy with it? Well, not....
As this was only my desktop computer. I quickly updated the driver on the laptop as well, and went on the road. Just to see 100% CPU usage there. Did all the tricks again, but nothing helped. Until I had the crazy idea to change my widget theme from the default Oxygen to Plastique. And hurray, the problem went away! It is not perfect, with dual monitor enabled sometimes maximizing a konsole window takes seconds, but still in general the desktop is now usable. And of course this should also make me have more uptime on battery.
Do I blame Oxygen? No, not directly. Although might make sense to investigate what causes there the NVidia driver going crazy and report to NVidia.

So in case you have similar problems, try to switch to 256.44 and if it doesn't help chose a different widget style.

Now, don't say me to use nouveau or nv. Nouveau gave me graphic artifacts and it (or KDE?) didn't remember the dual card setup. Nv failed the suspend to disk test with my machine and doesn't provide 3D acceleration needed eg. for Google Earth.

UPDATE: I upgraded my laptop to 4.5.1 (from openSUSE packages).Well, this broke composition completely, I got only black windows. I saw a new driver is available (256.53), let's try it. So far, so good, even with Oxygen. Let's see on the long run how it behaves, I didn't test it in deep.

> Read More... | Digg This!

A friendly note that KDE SC 4.5.1 will be tagged on 26 August.

So keep those bug fixes coming.

> Read More... | Digg This!

Marble 0.10.0 has been released as a major update last week together with KDE SC 4.5. As a user you might be interested in our Visual ChangeLog which is also available in spanish over at muylinux.com.

But Marble is also a library. So it can be used as a widget in other applications. Today I'd like to show you how.
In our previous tutorial I already introduced you to the very first steps of Qt Programming and Marble Programming. Now the last few Summer days in Germany have been rather rainy. So in the second part of our tutorial I'd like to show you how to create a weather map!

Creating a weather map

We'd like to display a small weather map. So we need to modify the map defaults of MarbleWidget. And we need to turn on the satellite view, enable the clouds and enable the country border lines.

Again MarbleWidget provides a convenient way to make these changes to the overall look and feel of the map.

By default Marble shows a few info boxes: Overview Map, Compass and ScaleBar. But the size for the widget is very limited. Therefore we want to shrink the compass. And we want to get rid of all the clutter, so we turn off the Overview Map and the ScaleBar. In the source code the class AbstractFloatItem is used to display all kinds of Info Boxes. All the Info Boxes are derived from the AbstractFloatItem class. Now we get a list of all the float items that are known to MarbleWidget and we go through it. Once we reach the float item which has got the name id compass we make all the changes we want to it (this has been simplified in Marble pre-0.11.0 where you will be able to access AbstractFloatItems directly via their nameId):

Save the code above as marble_weather.cpp and compile it:

Instead of calling the compiler directly you can also create a qmake project file:

Store it as marble_weather.pro in the same directory and call

If things go fine, execute ./marble_weather and you end up with a map application that displays clouds on top of a flat map:

That's all for today. In our third chapter we'll show how to load KML and GPX files into Marble. So stay tuned. If you need help join us on our mailing list marble-devel@kde.org or on #marble (IRC on Freenode). If you want to obtain the latest Marble source code have a look at Marble's website.

If you are interested in more news about Marble then join us and feel welcome in our Marble Facebook Group!

> Read More... | Digg This!

Marble 0.10 was released on August 10th, 2010. It is part of the KDE 4.5 Software Compilation. In the good tradition of recent years, we have collected those changes directly visible to the user. Unfortunately we were a bit late with our visual changelog for the release. So please enjoy looking over the new and noteworthy:

Online Routing

Do you want to plan a bicycle tour in the nearby wood? Need driving instructions to get to an address in a foreign city? Besides searching for places, Marble can now display possible routes between two or more of them.
And the best thing is: The routes are draggable!

Online Routing in Marble

Places to travel along can be entered using search terms (e.g. addresses) in the new Routing tab on the left. Of course Marble also allows you to input them directly on the map. Routes are retrieved using OpenRouteService and displayed on the map. Turn-by-turn instructions are displayed on the left.

You can customize the route using preferences like transport type (car, bicycle, foot). An arbitrary number of via points can be added easily: Use either search terms or create stopovers quickly and conveniently by dragging them out of the existing route and dropping them at the desired position. While a real-time navigation mode is scheduled for Marble 0.11, you can already export the route in the GPX format now. This feature is handy for using routes in conjunction with your navigation device or other software.

Bulk Download for Tile data in Marble for Offline Usage

For normal usage, Marble downloads the map data that is needed on the fly in the background. It also saves the data that has been downloaded on the hard disc. Now imagine that you make a trip to Norway, and you don't know for sure whether you'll have internet during the trip. So you want to download the whole Oslo area in advance. Up to now this hasn't been possible. But with Marble 0.10.0 you can click "File->Download Region ..." and you get a dialog where you can specify the region and the zoom levels that you want to download. This feature was brought to you by Jens-Michael Hoffmann.

Download of the Visible Region

Support for Multiple Layers in Marble

So far, Marble has had support only for displaying a single map texture on top of the globe. (The only exception was the cloud feature which allowed having clouds displayed on top of the satellite map. This, however, was hard-coded and not extensible.)
For this release, Jens-Michal Hoffmann has worked on Multiple Layer support.
This means that maps can now be created which display multiple texture layers. For instance: a cloud layer on top of a street texture layer on top of a satellite texture layer. This is all done in a generic way. So people who create maps for Marble can create an arbitrary amount of layers blended on top of each other. The best thing is: Due to the way the feature was implemented the performance doesn't change! And the clouds feature has been reworked to make use of the new mechanism.


Support for Gimp-like Filters Between Layers in Marble

The City of Dresden shown in Marble with multiple layers: Satellite images provided via WMS displayed on top of OpenStreetMap data via Multiply Blending.

As described before, Marble has support for multiple layers now. Layers can get blended
on top of each other using Gimp-style "filters": You can choose among more than 30 blending algorithms, such as: Overlay, ColorBurn, Darken, Divide,Multiply, HardLight, ColorDodge, Lighten, Screen, SoftLight and VividLight. If you've ever use an application like Photoshop (TM), Krita or Gimp then you probably know what this means.


Quick and Dirty WMS Support and More Url Download Schemes.

Lots of map data is provided on the internet on servers via the Web Map Service ("WMS") protocol. Bernhard Beschow has added initial quick and dirty WMS support to Marble. This means that there are now a huge number of maps that can be easily displayed using Marble.


Marble Goes Mobile: Support for Nokia's N900 and UI profiles

With KDE 4.5, we have completed the first step toward mobile platform support: Marble will show a slightly different and simplified UI on the N900 Maemo platform compared to the desktop. For KDE 4.6 we aim for an even better user experience and improved performance.

Marble on a Nokia N900

Marble Routing on Maemo5

For more information please visit the Marble Garage Project. Next stop will be the MeeGo version for Marble.


Display APRS (Automatic Packet Reporting System) Senders with Marble

This is one of our first more specialized Online Service Plugins: The APRS plugin created by
Wes Hardaker shows worldwide Ham-Radio stations. HAM Radio's APRS program allows radio transmitters to send their position and other information and is frequently used in disaster relief efforts for coordinating team distribution.

APRS senders displayed in Marble

We are still looking for programmers who would like to create more Online-Plugins: e.g. Twitter, News, Earthquakes or a social network plugin. It's easy to do and there's an Online Service Plugin tutorial available on our website that shows how to do it.


Performance Improvements and More Changes Under the Hood ...

In addition to these major improvements, our Marble developers have worked on several other small features, bug fixes and performance improvements:

• Two additional search backends: Hostip (try "planetkde.org") and OSM Nominatim (try "ATM,
  Karlsruhe") (Dennis Nienhüser)
• Improved animation support for zoom and panning (Dennis Nienhüser)

> Read More... | Digg This!

Last weekend I received a postal package that contained a classroom atlas from Austria: the Neuer Kozenn Atlas. Inside there was a nice shiny CD with the title GEOTHEK Schulatlas, Version 1.1 Digitaler Weltatlas. The publisher of this atlas and its software is Ed. Hölzel.

The Kozenn Atlas (named after the slovenian born teacher Blasius Kozenn) has been produced in Vienna since 1861. It has been updated continously by the Geographical Institute Ed. Hölzel. And it has been published in a lot of other countries as a world atlas (France, Netherlands, Belgium, etc.). Up to these days it's the most famous austrian school atlas.

Geothek is a software published by Ed. Hölzel that had been developed by Helmut Mülner from the renowned Joanneum Research. I was curious since this was supposed to be the first version based on the Free Software Marble.

So I booted up the Windows 7 partition of my Thinkpad and put the CD into my external DVD drive. The setup application started automatically and I had to approve the License:

Afterwards the Nullsoft Installer quickly installed the files into the directory that I had chosen. A help text showed up and a new entry Geothek Schulatlas appeared in the Start Menu. A click on Atlas started the Geothek. It turned out that this version of Geothek is a nicely enhanced version of the Qt version of Marble: The application is fully translated into German. Also the location database is replaced by data from Ed. Hölzel.

Entering a location in the Search query field centers the globe onto the selected place as usual. However a second tab in addition to the globe view had also been added which contains a 2D-Viewer for the physical maps of the Kozenn atlas (see screenshot above). This 2D viewer would automatically choose the correct physical map and center and zoom it according to the search query. Symbols are added on top of the the physical map which the user can click on and which interactively provide hundreds or thousands of encyclopedic articles, climate diagrams and beautiful photo material for lots of popular places.

The "Map Theme" tab contains additional maps featuring topics like "Population Density", "Climate Zones" and "World Trade". And for each of these a specific legend had been created. Of course all those maps can be panned and zoomed as always in Marble. Very nice quality work!

At the bottom left there is a "Statistics" page. Clicking onto it makes a big table appear: The table lists all countries of the world. The columns cover all kinds of topics, like area, population, life expectancy and lots of other interesting facts. After selecting one of the columns the second tab displays a map that nicely color-codes this information. There are more configuration options for this map and it's pretty evident that the application developer had a lot of fun in developing this particular feature.

Another interesting addition is the 3D Satellite View. Marble itself which serves as a base doesn't provide a true OpenGL view with flights over mountain landscape sceneries. Adding something like this is on our roadmap. But it will still take some time to add it properly.

So the Geothek developer added a special separate OpenGL based canvas which would allow to fly over a given area. The view features satellite imagery on a "flat" map and it's possible to tilt and rotate the view in all directions. Also the elevation of the landscape can be exaggerated:

As a bonus access to a set of "silent maps" is provided for teachers via the application menu.

All in all this application is a great showcase how Marble can be turned into a customized and polished quality product that is fun to use! The current version of Geothek is based on Marble 0.7/0.8, which is more than a year old. Since then Marble has developed a lot furter, adding stuff like Routing, WMS support, multiple layers, better OpenStreetMap integration and a lot of details that make life of application developers easier.
So I think that Marble nowadays should be an even more attractive solution for publishers of schoolatlases and encyclopedias: They could just rip out the original Marble content (if necessary) and replace it with their own high quality data. That would cost a lot less than building up a full custom solution on their own. In the Marble project we'd really like to support such kinds of projects. And since the Marble development pace seems to increase I wonder what the next two years will bring.

I'd like to congratulate and thank Helmut Mülner and Lukas Birsak for this amazing product they have created. I was also very impressed by the way they credited the Marble team's work. Even better: The Geothek was published as an LGPL project on sourceforge. Of course the Hölzel maps are not included in the source code but that was naturally to be expected. But we also liked how the Geothek developer contributed his bug fixes back to the Marble Project in the best possible way.

> Read More... | Digg This!

Harald has asked me to organize a KDE release party here in Graz.

However, I am too lazy (wait! busy! sorry for my English, busy is the word I was looking for) to do that there won't be a dedicated event to celebrate KDE's newest achievement.

Fortunately the release date, August 4th, is a Wednesday or more precisely the first Wednesday of the month.
And on such rare occasions (happens only twelve times a year) Free Software users from Graz and areas close by gather at a nice Italian restaurant to have Pizza, Beer (some even have Cappuchino and Tiramisù) and talk about stuff that comes to their minds.

For the German native speakers among you, we call this "LUGG Stammtisch"
(as in Linux User Group Graz, Stammtisch should be self-explanatory)

So if you think you can stand yet another pizza or fancy having some beer with awesome people, including at least one well know KDE developer , join us at Cosa Nostra, Hans-Sachs-Gasse 10.

Beginning at 20:00, until we are thrown out (gah! until we are politely asked to leave)

See you there!

> Read More... | Digg This!

In a few hours KDE 4.5 will be released. And together with it the new version of our Virtual Globe and Map Widget Marble. The new release Marble 0.10.0 will bring lots of additional features (Routing, Tile-Bulk-Download, Multiple Layers, initial WMS support and a lot more) - many of them related to OpenStreetMap.
Of course development on the next release has started already: Dennis Nienhüser and Niko Sams have added Worldwide and Offline Routing support to Marble using Gosmore and Routino.
In other news the spanish Linux Magazine has published a really nice article by Tim Schürmann about Marble the application: "¡MARBILLOSO! Marble se ha convertido en una alternativa interesante a Google Earth, y funciona sin conexión a Internet. ". If you are interested in more news about Marble then join us and feel welcome in our Marble Facebook Group!


But Marble is more than an application: You can use the MarbleWidget and its framework in your own application to display map data! There are many applications which are doing this already. See our success story page for more information. And today we start to show how to do it. All you need for our Tutorial is a little bit of C++ and basic Qt knowledge:

Hello Marble!

The API of the Marble library allows for a very easy integration of a map widget into your application.

Let's prove that with a tiny Hello world-like example: Qt beginners might want to have a look at the Qt Widgets Tutorial to learn more about the details of the code. But this is probably not necessary. For a start we just create a QApplication object and a MarbleWidget object which serves as a window.
By default the MarbleWidget uses the ''Atlas'' map theme. However for our first example we choose to display streets. So we set the maptheme id to
OpenStreetMap. Then we call QWidget::show() to show the map widget and we call QApplication::exec() to start the application's event loop. That's all!

Copy and paste the code above into a text editor. Then save it as my_marble.cpp and compile it by entering the folling command on the command line:

If things go fine, execute ./my_marble and you end up with a fully usable OpenStreetMap application:

That's all for today. In our next chapter we'll show how to create a basic weather map with Marble. We'll also show how to change basic properties of the map widget. So stay tuned. If you need help join us on our mailing list marble-devel@kde.org or on #marble (IRC on Freenode).

Tip

Here's a little checklist to tackle some problems that might arise when compiling the code above:

• You need Qt and Marble development packages (or comparable SVN installations)
• If ''Qt headers'' are not installed in /usr/include/qt4 on your system, change the path in the g++ call above accordingly.
• Likewise, add -I /path/to/marble/headers if they're not to be found in /usr/include

Note

If you provide maps in your application please check the Terms of Use of the map material. The map material that is shipped with Marble is licensed in the spirit of Free Software. This usually means at least that the authors should be credited and that the license is mentioned.
E.g. for OpenStreetMap the license is CC-BY-SA. Other map data shipped with Marble is either public domain or licensed in the spirit of the BSD license.

> Read More... | Digg This!

It's official the combined KDE Akademy and Gnome GAUDEC conferences will be held in Berlin in 2011, next year and this is great news! I played a small part in organising the joint conference in Gran Canaria in 2009, and really enjoyed working with the Gnome guys most of whom I hadn't meet before, as well as the familiar KDE people. It was great fun to see how it turned out. I don't think anyone really knew in advance - we didn't know if too much collaboration would spoil the 'community bonding' aspects of the conference and their individual identities. Or maybe too little collaboration would increase the distance between the two communities. In the end I thought the collaboration aspects could have been better, indeed like the WiFi could have been better - there is always something you can improve at these conferences, but what the heck, by and large it was mostly pretty good.

I enjoyed being able to go to both presentations, and some of my favourite ones, like the MeeGo^h^h^hMoblin user experience talk in the mobile track, came from the Gnome side. Both projects are facing the problem of how to you merge your desktop technology with the upcoming Smartphone/Small devices that run platforms such as Android or Meego.

A consequence of stresses like upstream vs downstream or mobile vs desktop, is that Dave Neary's recent survey of Gnome contributors has given rise to much discussion and flaming about Canonical's contribution. One from Mark Shuttleworth called Tribalism is the enemy within, which is worth a read. That addresses tribalism within the Gnome community, and that is clearly a bad thing.

Another good post from Jono Bacon RED HAT, CANONICAL AND GNOME CONTRIBUTIONS included this from Dylan Macall, which made a good point:

"..This whole thing is really putting forwards an issue Gnome has right now: they can?t, as a community, decide whether they like the idea of external projects building new environments on the Gnome platform. (Case in point: Meego for netbooks).
I think there?s one camp that thinks Gnome should be a user-facing product, with its own special branding and its own distinctive look that everything ships in pristine condition. (I?ll inject my opinion in brackets here: I think that entirely defeats the purpose of having multiple distributions).

Then there?s another camp that sees Gnome as a starting point with lots of handy tools (and common modules) for distributions to build operating systems. For example, Unity, Meego, Jolicloud, UNR?
That first camp sees Gnome as a monolithic project; only internal work is worthy. The latter camp sees Gnome as something akin to Gnu.."

I think you could have exactly the same discussion about the KDE project and what it's relationship with MeeGo should be. Does KDE consist of a lot of useful tools and libraries that we should encourage as many other projects as possible to use? Or should we concentrate mainly on a cohesive desktop experience? Are the two aims incompatible? I don't know..

I hope we can minimise Gnome vs KDE tribalism too, and I'm looking forward to another combined conference, where we can integrate the communities better (and in the process have great parties involving much beer drinking of course). I was slightly disappointed that Gnome 3.0 has been delayed, and I really wish them good luck in getting it out of the door. It is not true at all, that if Gnome does worse, then KDE will do better. If both projects succeed it is more like '1 + 1 = 3' or if one project fails it is '1 + 1 = 0.5'. We now have much infrastructure in common and need each other to succeed so let's "Relax"..

> Read More... | Digg This!

During the Akademy kde-on-mobile discussion, Kévin Ottens suggested that mimetypes be splitted out from the main sycoca database, in order to reduce the overall time kbuildsycoca takes every time it runs, and to make things more modular. Last monday I had a look and decided to go one step further and not use ksycoca at all for mimetypes. This makes the KMimeType subsystem really independent (usable without having run kbuildsycoca4 before, so no dependency on kdeinit+kded etc). Took me the whole week, but there we are.

Given that shared-mime-info delivers pre-processed output already, we "just" have to load what we need, on demand, in-process. I was afraid this would be slower and take more memory as a result, but see results below.

The KMimeType subsystem now loads directly from disk the information it needs. The first time you use findByPath("foo.jpeg") it loads the "globs" file generated by shared-mime-info once and for all into memory, and then uses that for fast matching. Same thing for the list of aliases (one big file, loaded once), and for "subclasses". The more expensive information is the XML file for each mimetype, but this is only needed when asking for the icon, the comment, or the list of extensions for a given mimetype. This used to be all parsed and cached into ksycoca, now it's done on demand by KMimeType.

The only mimetype-related thing that is still in ksycoca is one tiny entry per mimetype, with a pointer to the list of services (applications) which support this mimetype, for KMimeTypeTrader.

Here are the performance results:

• "kbuildsycoca4 --noincremental" (with warm caches) went from 2.8s to 2.1s
• Mimetype inheritance tests (KMimeType::is() on a list of 40 mimetypes, like PreviewJob does), went from 791,404 instr. loads to 568,345 instr. loads (QBENCHMARK and "./mytest -callgrind" rock). So, loading the subclasses file directly from disk is actually faster than loading a preprocessed form from ksycoca? Well, it's also that constructing a KMimeType is way faster now, since the mimetype details are not loaded in this case.
• Mimetype glob matching (reconizing that "foo.jpg" is a jpeg file) is also much faster: from 100k-120k instructions to 75k instructions. (This doesn't include the one-time-per-process parsing of the globs files).
• Something had to give, though. The worst case for loading mimetype details is a tree that shows all mimetypes, such as the KMimeTypeChooser widget. Instead of loading the icon and comments from ksycoca it now loads them from individual xml files, so even though I ported that code from QDomDocument to QXmlStreamReader (which made it 29% faster), the overall time for loading all mimetype details is much longer: 1182k instead of 113k instructions. However from the user's point of view, this means 460ms instead of 60ms when opening that tree of mimetypes, which actually takes quite longer because of the icon loading anyway. I think this is acceptable. The very common use case (mimetype lookup and matching) was optimized at the expense of the rare case (showing all mimetypes).

I find it interesting how not using a cache that was invented to improve performance, actually improves performance

Interestingly, I thought it would be worse on memory usage too, but it's not:

I'm not entirely sure why, in fact, apart from the fact that ksycoca (kmimetypefactory, more precisely) was loading some dicts unconditionally, like the alias list, which isn't loaded anymore in this particular use case. It can't be the size of KMimeType objects, they are not kept in memory in either case. So I'm still a bit surprised, but well, the good way, so not really worth spending time with massif

The "visual" result of all this:

(This particular use case of starting one process for one mimetype lookup has of course worse performance now, but it's time to stop looking at performance when it's about 0.01s vs 0.03s for a one-time operation...)

Anyway the main point of these 2 commands was: no ksycoca needed.
Now I'm not trying to send the message that ksycoca is bad. We definitely need it for things like "find the apps that support image/jpeg" or "find the apps that contain FooBar in their name or keywords". The number of app desktop files is so big, that we definitely need some kind of database index for these, we don't want to load all of them into memory in each process. But for mimetypes, thanks to shared-mime-info producing usable output, not using ksycoca actually makes sense, the information is already in a usable form even for fast lookups (mimetype by name, mimetype for a certain file, by name and/or content).

Writing all this makes me realize that the caching of kioslave .protocolinfo files into ksycoca is more like mimetypes than applications and even simpler: fewer items, and always used for looking up the details for a single protocol by name. So, logically I should extract it from ksycoca too. Well, after the vacations

> Read More... | Digg This!

In case you use Icecream (the distributed compile system which makes your coworkers' machines compile KDE for you ) and happen to be using a glibc >= 2.11.2, you might notice that you are not able to send compilation jobs to other machines while still being visible to the scheduler and receiving jobs from other hosts.

It turns out that some commits to ldconfig made the script which created the environment sent to all other clients not work as expected because of a missing directory.

So until a new stable Icecream release is made (the current one is 0.9.4), make sure to apply this commit to your package to keep things running smoothly.

> Read More... | Digg This!

Proposed by chrome developers - two entries and submenu are removed. Reduces mouse clicks and movements.

                                                                     

> Read More... | Digg This!

Do you remember the tabbed toolbar thing that was once born in Kexi? It's an attempt to optimize the UI when collection of actions depends on context. This part of development goes well, even while there is no framework for use by other KDE 4 apps. Those still use the KDE 3 technology, i.e. KXMLGUI leading to rather big menus.

What's understandable many users prefer to use menus, and even more of them would ideally use both toolbars and menus. Certain actions are hard to express using icon or icon+short name.

Read on to see a proposal to have both of the worlds.

Only few out there probably know that Zoho office has a fresh concept. Here's normal tabbed-toolbar-like interface:

Now the interesting - the same interface provides menu. Just click the arrow:

If you ask me, it's simple and can work. It's possible to add shortcuts and keyboard navigation goodness.

Here's more explanation: google PL->EN translation. Let's hear what you think in the comments!

> Read More... | Digg This!

Besides maintaining Ark, I also spend some of my KDE time reviewing and applying patches for other projects as well. This weekend I had some free time, which was dedicated to applying some Kopete patches and pushing some KDE-FreeBSD patches upstream.

So let's start with Kopete. My initial intention when subscribing to the kopete-devel mailing list was to work on new features and get in touch with the development community in general. Even though in the end I haven't written code for Kopete myself and have replaced it with Bitlbee, irssi and GNU Screen on a remote server, I still comment on the list, help moderate it and review patches whenever I can.

Actually, "reviewing" may be too strong a word here -- since I've never digged too deeply through the code base, I usually just give an outsider's look at the patches, watching for const iterators in foreach() loops, giving hints about what patches should be applied after trunk is unfrozen and other things like that. Since there aren't many active Kopete developers, even these small actions end up helping the development.

Yesterday I went through some open review requests for Kopete, checking which ones could finally be committed now that trunk is once again open for feature commits, asking some request authors to close their reviews as Submitted or simply pinging people about pending reviews. Ralf Haferkamp's patch, for example, implements wishlist item 97998; Manuel Luitz's one connects and disconnects an account when the IdentityStatusWidget is double-clicked. Finally, Igor Poboiko's big patch brings the translator plugin back to a working state after who-knows how much time -- I've never used it myself, but it apparently fixes no less than 6 bug reports! The patch does add some new strings, though, so it will only make it to KDE SC 4.6.

On the FreeBSD front, Alberto Villa asked me a few days ago to take a look at some patches to kdeadmin's KNetworkConf and KDM that were lying around FreeBSD's ports tree. I asked him to forward the KDM patch to ossi (who has already given him some suggestions of improvements), but the KNetworkConf ones were fairly simple -- even though the application is quite old and mostly unmaintained, it's good to keep things such as correct FreeBSD release detection and routing information loading upstream.

P.S.: No, I'm not at Akademy

> Read More... | Digg This!

It's Friday and day three of the OdfKit Hack Week. So what did we do all day besides folding balloons, talking to men in wooden shoes and eating pancakes? We actually implemented the style inheritance I blogged about yesterday. Background images are now supported too. There was some philosophizing over APIs and we published some code (recommended if are interested in (Qt)WebKit or ODF).

Since the weekend is here we'll not go into details too much, after all you can download the Qt client code or try the online demo in a WebKit or Firefox browser, but we will show some images.

The first image shows that background images are working in the Qt client now and the second screenshot shows the first part of the ODF 1.2 specification odt format opened in OpenOffice, our WebKit based viewer and KOffice.

> Read More... | Digg This!