I can haz KDE 4.1

Well KDE4.1 is available, and it is a sweet. For a lot of people, this will be the switchover point, the rest of you – KDE4.2 should do it :)

I would like to suggest looking at Bruce Byfields excellent review for a good idea of who should be switching yet.

I, I’m sold. Despite the slowness of my NVidia card natively, I can work just fine using XGL. However, I also found that XGL conversely made my KDE3 installation almost unusably slow (ditto KDE3 apps I still use – even though inside KDE4 I can hack-launch them to run on the native screen with a few tweaks).
So I split out XGL to only run for KDE4 for now. To do so I rm’d /etc/X11/xsession.d/98xserver-xgl_start-server
then created a new script in /usr/bin called startkde4-xgl with the following content:

#!/bin/bash
GL_START=/usr/share/xserver-xgl/Xgl-session
XGL_DISPLAY=:1
XGL_OPTS=”-nolisten tcp -fullscreen -br +xinerama”

$XGL_START $XGL_DISPLAY $XGL_OPTS –execute /usr/lib/kde4/bin/startkde

Gave it execute permissions and added a session file for it in /usr/share/xsessions.
Please note: These instructions arethe short-version and they are for kubuntu, other distros handle XGL in very different ways.

Either way, it’s great to finally have KDE4.1 final installed – now to go PLAY !

How I made KDE4.1RC1 Usuable on my Nvidia card

By now, most people know that KDE4 and later are severely hampered on NVidia hardware due to problems with the driver. This appears to be a problem with XRender feature primarily, though there are other things as well. I have in the past tried every single piece of the many pieces of advice out there – and none of them had any measurable effect for me. It all worked – it was just utterly, unusably slow.
News I saw today confirms the same problem is hitting the upcoming Gnome 2.6 and even the firefox browser.

Today, as I was reading more sites about it, I saw a possible hint that sounded worth a try – and I tried it – and it’s working perfectly – so I thought I would share it.
Switch to XGL. Unlike the AIGL favored by most distributions now, XGL does not make composition and render feature available through extensions (which is where NVidia seems to do an epic fail) – the actual X server is implemented directly in OpenGL – and then makes these features function by actually doing them in it’s existing OpenGL setup (yes I know this is an oversimplification but it covers the core reason why this seems to work).

On kubuntu hardy, getting xgl is as simple as: sudo apt-get install xserver-xgl
You need to reboot afterward as there is a bootscript that handles the switchover.

However, once I did that – KDE was a LOT faster. For a test, I enabled desktop effects – at first, nothing happened. Then I looked in the advanced settings and found it was set to use OpenGL – since my X-server is now already using OpenGL to render, this apparently does not work. So for a test, I threw it over to XRender – and suddenly they were working.
Frame rates were high – much higher than they had been under the Xorg server with XRender, the effects worked stably and without issues – there was no visual problems at all – and the desktop remained perfectly fast and responsive. In fact the only problem was the actual effects HAPPENED slow. This I am disinclined to blame on either XGL or XRender – I suspect this is simply a case of “don’t run desktop effects on a box with only 512MB of physical ram” – the card and display was handling it perfectly fine, the computer was just taking long to do this extra stuff (which I believe are done with lower priority to save resources for the more important applications).

I am pretty sure they are actually usable anyway – I will play more with them in the next day or two.

*Note: XGL is not considered stable, and being basically a fork is not a nice way of doing things. I have also heard reports of various shortcomings in it, some things that should work but just don’t. I haven’t used it long enough yet to find any – but you have been warned. It seems to make KDE4 usable – and right now, that is my highest priority, it may not be yours.

**Note: I do not suggest letting this blog be a suggestion to buy NVidia, I will never again – ATI has a FREE driver now, without problems and that works very well according to people – I can now get a card that meets my needs without a non-free driver, so I won’t be buying another NVidia and deal with nasty surprises like this again. I had no choice before – if you have one – choose free software. This entry is an attempt to help those who, like me, at a time when there was no other sufficient choice available were forced to buy an NVidia card and cannot upgrade at this time, to allow you to at least deal with the situation of the problems NVidia’s proprietary driver has with current software releases until the time you CAN upgrade.

kde3to4 is almost ready for it’s next release

Last night I finished the code for kde3to4 version 0.0.2. This release will mark a major leap ahead in the race from a newly implemented idea to a genuinely solid and useful program.

The first major change is that it now uses kioclient rather than shell cp as it’s backend for copying files and directories. This is a major improvement over the previous one for many reasons. Kioclient is graphical and has things like progressbars working out of the box. Overwrite’s are handled sanely in the way users are already used to and error handling is well implemented.
It basically makes the entire user experience a huge deal better than it used to be. I highly recommend it (or for KDE3 apps it’s parent utilities integrated in kfmclient).

An even more important change is the new all_apps plugin which uses a fairly standard formula to try and migrate any and all apps it finds. This one is still very experimental and marked as such, but it should work very well since the vast majority of apps will play happily with the formula it uses. For the rest it contains a double-level of protection to reduce the risk of breakage.

1) It deliberately ignores any program for which an existing script exists. In other words, it gives precedence to specialized plugins rather than it’s own formulaic approach.
2) It has an internal blacklist of programs to ignore.

This gives quite a bit of power to the protection scheme. Amarok for example is safe to migrate for 1.x versions, but 2.x is not compatible with 1.x settings. A migration tool for amarok is on their TODO list but not finished. So what I did was to blacklist amarok in the all_apps plugin, and provide an amarok1.x plugin that you can use if you are not using amarok2 yet. When amarok2 has a safe way to import amarok1 settings, we can build another plugin for upgraders and handle each edge-case.

This morning I sent a mail to the kde-devel mailing list asking developers to let me know about apps that should be pointedly ignored by all_apps or provide plugins/documentation where specialized plugins could work instead. It got me some very useful feedback. At time of writing this post (less than an hour after the mail) the blacklist has been updated to include mailody and kdevelop. In the former case because it is completely incompatible (I will look at the possibility of a specialized plugin when I have time) and in the latter because the settings are so vastly different that an import makes no sense.
I also have specific confirmation from Boudewijn that krita should work perfectly with this setup.

All in all, kde3to4 is coming along very nicely and I have solid hopes that it may be included with KDE4.2 (a point where many people have already indicated they will switch and thus a point where it’s usefulness will likely peak).

——-
UPDATE: The new release is now available from the application page (link in the menu on the left)