Qt

Back to Cinnamon!

Okay after my negative experience I’m now back to try Cinnamon, and I have a quite different story to tell.

First of all, thanks to Julian, I found that the issue I was having with the keyboard only involved my user’s settings, and not the code by itself. After a bit more fiddling around, I found a more detailed case where this happens.

My keyboard layout of choice is the so-called US Alternate International (us alt-intl); unfortunately even with the recent improvements in Input hotplug for Xorg, it seems like configuring Xkb on the configuration file, or on the directories, is not recognized by the evdev driver (at least), which is why I configured it with GNOME, Xfce, and, by reflection, Cinnamon, to change the layout of the keyboard — and that’s where the problem lies. When GNOME3 or Cinnamon are started, and they set the keyboard layout (both do it the same way as in both cases you configure it through GSettings), the Alt_L and Meta keys get somehow swapped… but not in all cases, as Emacs was still getting it right (which meant that just switching the two is not going to help me).

I guess I should track it down even further than this, but for the moment, I solved this by using setxkb in my ~/.xsession file, and that doesn’t seem to cause any trouble.

The other issue I reported, was that clutter is unstable when using nvidia hardware; to be precise, the issue is with nvidia-drivers (surprised?), and it’s actually the second issue that I find with their drivers in the last few weeks: the other was Calibre being able to get Xorg to eat so much memory that the system gets unresponsive, just by the sake of being launched, and add to that Skype that was unable to render *at all*….

So I decided to give a try to what Pesa suggested me to solve the Skype (Qt) issue: I decided to try the nouveau driver. Actually I wanted to try that a couple of weeks ago, but after reading through their website I wasn’t sure that my video card (NVIDIA GT218) was supported or if I had to deal with dumping the firmware out of the nvidia drivers and whatever else… but the other day, after screwing my own system over, and needing to boot from SysRescue, I found out that the driver they load is … nouveau, and it worked decently well.

So since this is weekend, and the time was right, I decided to give it a try — and the results are great! Clutter works fine, Cinnamon works fine, and while I haven’t tried anything that is running in OpenGL proper yet (no games), and Google’s Maps GL reports not working with this implementation (not that I care much), it works definitely well enough for what I usually do. I haven’t tried audio out on the DisplayPort connection, but it’s not like I’ve ever tried it before… Suspension works very fine.

And yes for now my experience with Cinnamon is terrific!

Sorry Sput, but Quassel has to go from my systems

I’m going to get rid of Quassel in the next days unless something drastically changes, but since I really think that Sput was doing a hell of a good job, I’d like to point out what the problems are in my opinion.

There’s nothing wrong with the idea (I love it) nor with the UI (it’s not bad at all); having it be cross-platform also helps a lot. What I really feel is a problem, though, is the creeping in of dependencies in it. Which is not Sput’s fault for the most part, but it is a good example of why I think Qt and KDE development is getting farther and farther from what I liked about it in the past.

With KDE, the last straw was when I’ve noticed that to install Umbrello I had to install Akonadi, which in turn required me to install MySQL. I don’t use MySQL for myself, I used for a couple of web development jobs but I’d really like for it to stay stopped since I don’t need it on a daily basis. On the other hand I have a running PostgreSQL I use for my actual work, like the symbol collision analysis. I doubt that it would have required me to start MySQL or Akonadi to run Umbrello, but the problem was with the build system. Just like KDE guys bastardised autotools in what is one of the most overcomplex build systems that man was able to create in the KDE 3 series, they have made CMake even worse than it would be as released by Kitware (which, on the other hand, somehow seemed to make it a bit less obnoxious — not that I like it any better, but if one has the major need of building under Windows, it can be dealt with better than some custom build systems I’ve seen).

So the new KDE4 build system seems to pick up the concept of shared checks from KDE3, which basically turns down to be a huge amount of checks that are unneeded for most software but will be executed by all of it, just because trying to actually split the “modules” in per-application releases, like GNOME does already, is just too difficult for SuSE, sorry, KDE developers.

This time the dependency creep hit Quassel badly. The recent releases of Quassel added a dependency over qt-webkit to show a preview of a link when posted in IRC. While I think this is a bad idea (because, for instance, if there was a security issue in qt-webkit, it would be tremendously easy to get users to load the page), and it still has implementation issues when the link points to a big binary file rather than a webpage or an image, it can be considered an useful feature so I never complained about it.

Today after setting up the new disks the update proposed by portage contained an interesting request of installing qt-phonon. Which I don’t intend to install at all! The whole idea of having to install phonon for an application like Quassel is just out of my range of acceptable doings.

I was the first one to complain that GNOME required/requires GStreamer, but thanks to Lennart’s efforts we now have an easy way to play system sound without needing GStreamer, on the other hand, KDE is still sticking with huge amount of layers and complex engines to do the easiest of the tasks. I’m not saying that the ideas behind Solid and the like are entirely wrong, but it does feel wrong for them to be KDE-only, just like it feels wrong for other technologies to be GNOME-only. Lennart’s libcanberra shows that there is space for desktop-agnostic technologies implementing the basic features needed by all of them, it just requires work and coordination.

So now I’m starting up Quassel to check on my messages and then I’ll log it out, after installing X-Chat or something.

Frontends and scripting languages

So today I updated my system and seen that the new nmap version features a totally new frontend, written in Python with pygtk. While this bothres me a bit because I had to install the pygtk package with its siblings, I actually find this an interesting and useful change.

I say this because, well, frontends don’t need to be fast or to have a tight memory usage pattern; most of the times, frontends only have to take care of user interaction, and the user interaction is neither cpu, nor memory, nor I/O bound, it’s user bound.

Scripting languages don’t usually suffer from architecture problems, like endianness of variables, or missing definitions or include files moved around; well, the base interpreter does suffer from these problems, but it’s one package instead of every package.

Also, scripting languages usually makes it easier for users to change the frontends if they need, which is certainly an advantage for the part of the program – the frontend, as said – that faces the user.

This made me think about writing a new Valgrind frontend; my language of choice would certainly be Ruby, the problem is: which GUI libraries would I be using?

An year ago I was dead set on Korundum, KDE’s Ruby bindings, but I don’t think this is feasible now. The reason is of course tightly related to the KDE4 development: writing on Korundum makes little sense, considering that the focus is now KDE4, but KDE4 itself is too young to write the frontend using that. Plus there is one big problem with QtRuby: the Qt3 and Qt4 Ruby bindings install the same shared object, with different APIs, making a Qt3 Ruby program incompatible with a system where Qt4 Ruby is installed. And writing the frontend in pure Qt4… I’m not sure about that.

The alternative is to use ruby-gtk2. Even if I don’t like the GTK C interface myself, the Ruby version seems nicer to me. And with Nimbus I can finally stand GTK2 interfaces. I should probably try this out, it might be good enough to go.

Actually, with little work it’s likely that I could write a pure-Ruby abstraction for a valgrind frontend, and then two interfaces, one in GTK2 and one in Qt4. This is another nice part of scripting languages: you usually have the basic set of objects not being part of the libraries used (QString, GString, …) and you can more easily share code between Qt, GTK, NCurses, whatever you want.

So, anyway.. I need something to keep my mind busy tonight, as I’m having some real-life trouble (no, not health trouble, just… love trouble :/), so I’ll probably start tonight to work on something.

If there was a “Most Useless Free Software Developer Award”…

… I would have won it many times.

So, yesterday I was so happy around to have removed 10MiB and 300KiB of memory waste from picoxine, that I gone a step further, and worked on supporting mmap-ed (memory mapped) files input in xine. What I hoped was to not having to read the file by hand piece by piece, but rather pass the whole mmap to the decoder and be done with it.

I worked on it and I was able to get something usable, after a while, but… the block reading does not work as I hoped, it works only for MPEG TS, thus breaks for anything but FLAC (I’m not sure why, to be honest).

At the end, the MMAP implementation is in xine-lib, it does not have any regression, up to now, but it’s not the improvement I hoped, either. Right now instead of read() calls you have memcpy() calls that copies from the MMAP the data for the decoder to parse, it’s still a good waste of memory I’m afraid.

Another problem are the buffers used for the audio decoding, that I’m not sure how are well reused and freed and so on, unfortunately from picoxine I cannot play more than one file with a time between them, and I cannot get an useful massif output from Amarok, because QImage::create() seems to do some spikes of memory usage which reduce the scale of the graph. By the way: such impressive usage of memory seems to really be one of the causes for which Konqueror and similar are slow; I haven’t looked up Qt’s sources, but likely if you can reduce the memory usage of QImage::create(), KDE would be quite faster.

Last night I also tried to implement new rtp/rtsp support through lu_zero’s library, but resulted in a moot point that I will probably never be able to get something useful from, like for the WavPack decoder … sigh, I should probably give up on adding more stuff and just think of doing the little tweaks that gives you 300KiB out of 200..

I’m depressing myself thinking of how many useless project I started, I continued with eager of preparing something useful, and now are there waiting for something, probably their death. Stuff like rubytag++ is in my GIT repository bitrotting, as the original library itself (TagLib) had enough holes to make my bindings useless for what I hoped to do, and upstream seems not to care at all (I still haven’t received any reply from Wheeler, to my many bug reports and considerations); ruby-hunspell is probably a lost cause, too, as the unicode conversion thing I’m still unable to find a way to bind; gitarella is there, I cannot continue it alone, because I have not enough time, and there is still lots of stuff to add; KDigest in Ruby is still incomplete, I forgot why in the first place now…

Okay, better not to think of the failures, at least I can be proud of my ebuilds 🙂

Don’t you hate when…

… you’re working on cleaning up a series of ebuild, and while looking for configuring one your whole IME setup goes down because skim crashed, and neither restarting X helps? I do.

And I do even more when this happens during the night, and I’m already nervous because I was sick the whole day, and it’s too hot for my mind to stay clear.

So, as I was pretty pissed off at that, I decided to simply shut everything down and tomorrow I’ll see what to do. If the 9250 arrives before noon, I’ll probably put it on before actually doing any work, so it’s a good idea to leave the box turned off tonight.

In particular I would end up burning myself again if I tried to remove the GeForce out of that box after leaving it on for some days without ever shutting it down.

Unfortunately I was also trying to update Defiant so that I could keyword a few things, but that will have to wait.

So, what I was working on before getting hindered by my own X? After a bug received about scim-tables I passed the night looking at the scim methods ebuilds that needed to be cleaned up, scim-pinyin and scim-tables in primis, as they had an optional automagic KDE support that now came down to a kde useflag.

There is a lot of work to do on the CJK ebuilds I’m afraid, mostly because I see the same errors repeated over and over, probably because of the ebuilds copied from one package to the other, and cleaning them up to have a decent style is going to be a long work. At least I can try to make myself useful in CJK herd other than patching Qt (considering that daisuke didn’t release an official patch for Qt 3.3.6 yet).

Oh of course yesterday Amarok got added to portage, and there is trouble with that, as usual. It’s a quite widespread application, so it’s somewhat normal that people find troubles with it the same day it’s released, sigh. I’ll try to blog tomorrow after I’ll have fixed a few errors.

Now I really need something to calm myself down… I’ll read a book, as yesterday I finished The Wolves of the Calla by Stephen King, and I usually put a different genre of books between every book in the Dark Tower series to find it even more stimulating.

From the IME world

Well I said some time ago, while I don’t really have an actual use for IME to be enable on my box (not like I actually know enough of Japanese or other cjk languages to use it “daily”) I do like having it at hand for the couple of words I remember. It’s also an interesting way to call scripts 😉

Because of this and that, I eventually ended up having, in my overlay, a few updated ebuilds for app-i18n apps like scim and skim, and today I added a new version of scim-anthy (0.9.0 with ~amd64 keyword missing in 0.8.0 in portage) and the new skim-scim-anthy package to configure scim-anthy itself (needed a patch to build with Qt 3.3.5).

I’m trying to find some of the CJK people to get those version bumps in portage, but with scarce results for now 😛

For who wonders where my overlay is because wants to try the ebuilds, ~~it can be found as a bazaar-ng repository. To get a copy of it, just to this:

emerge bzr
bzr pull http://dev.gentoo.org/~flameeyes/bzr/overlay

After that a simple bzr pull will bring in all the changes in my overlay since last time 🙂

On a semi-related (to bzr) note: Brian passed to me the maintainership of confcache ebuild and with that the responsibility of the emerge breakages due to it… it will be funny when portage 2.1_pre5 will be released with confcache support in it 😛

I’m starting wondering how many configure.ac I’ll have to fix 😉