Tag: digiKam

My life with KDE4

It was late July that I went back to KDE — I left it just after version 4.0 was released, with the whole confusion after it. I’ve got now a generally good impression with it, it works much better than it used to in the original release, and it proved itself much more stable than GNOME 3 or Cinnamon, as it never crashed on me altogether, like both of them did so many times. Multi-monitor, which is what I complained about regarding Cinnamon, is not perfect here either, but that’s a completely different story at this point I guess.

While I’m still not liking the way the whole KDE 4.0 release has been handled – “everybody should know that a dot-zero is not ready for daily use” is just a sorry excuse for a mess up – the situation has improved and the results are good. Of course, like everybody already told me, I steered clear of semantic desktop, which means I’m not using KMail or anything like that (even though Tomáš pointed out that the problem is that it needs to have the code available, but not enabled at runtime). On one laptop I’ve been using Thunderbird — on the other I’m using only GMail and it seems enough for most cases, right now.

There are a few things that I still don’t really find straightforward, like the Plasma widget sharing (what the heck is it used for?) and the fact that you can have both widgets and notification icons in the lower panel for things like battery and network — and of the two, the nice ones are the notification icons, which have been, to me, the most difficult to identify. I also haven’t grasped the idea of activities, or to be precise their difference from desktops, beside looking, to me, like a three-dimensions desktop wall. I know that for it to work properly you need support from the apps as well, and they change both the apps and the available widgets… still, it doesn’t look like I can care for it right now.

KRunner (the thingy that comes up with M-F2) is actually quite nice, but there are a few rough edges on it as it is right now, I think. One of the was with the latest update (4.10) I lost the icons on it .. till the next reboot, then they appeared back. Maybe it was something to do with the further updates done on the ebuilds after the first unmask. Also, at least in 4.9, sometimes if you’re too quick to type and press enter, it executes the results of the previous search rather than current one… but okay, it’s my fault I guess.

After quite a long time I also decided to give up on Pidgin (on the Dell where I have been using it, the Zenbook right now does not have it at all, as when I’m using it, like right now, I care about being left alone, mostly — I have bought it as my “time to write” laptop), in favour of the Telepathy integration provided by KDE itself – you probably noticed after my previous rant about SSL implementations – which actually seems to work pretty well. Only issue? When you first try to add an account, and you don’t have the backends installed yet, it’ll tell you to install both telepathy-gabble and telepathy-haze — the former implements XMPP and thus allows both GTalk and Facebook accounts, the latter implements almost everything else on top of Pidgin’s libpurple… you don’t need it for either GTalk or Facebook, which happen to be the only accounts I care about myself, so at the end I was able to get rid of both telepathy-haze and Pidgin itself.

I like digiKam for photo handling, although the Flickr upload feature (at least in the previous version) was lacking, and the Facebook one absolutely unreliable… I know that version 3 has been just released and I’m looking forward to see if the new version solves my problems, which would make me very happy. I’m also hoping I’ll be able to get a new harddrive just for the photos, the one I’m using now is shared with Windows, and thus is formatted in NTFS — access speed even over USB3 is abysmal.

So, all in all, going back to KDE was really a very good idea. Although it took me a while to get used to it, and while it includes a number of features that I don’t think I’ll ever use (activities and widget sharing as noted above), it does not get in my way, which is the main reason why I was so bothered by GNOME 3, and it’s much more stable than Cinnamon.

Back to … KDE‽

Now this is one of the things that you wouldn’t expect — Years after I left KDE behind me, today I’m back using it.. and honestly I feel again at home. I guess the whole backend changes that got through KDE4 were a bit too harsh for me at the time, and I could feel the rough edges. But after staying with GNOME2, XFCE, then Cinnamon.. this seems to be the best fit for me at this point.

Why did I decide to try this again? Well, even if it doesn’t happen that often, Cinnamon tends to crash from time to time, and that’s obnoxious when you’re working on something. Then there is another matter, which is that I’m using a second external monitor together with my laptop, as I’m doing network diagrams and other things on my dayjob, and for whatever reason the lockscreen provided by gnome-screensaver no longer works reliably: sometimes the second display is kept running, other times it doesn’t resume at all and I have to type blindly (with the risk that I’m actually typing my password on a different application), and so on so forth.

Then since I wanted to have a decent photo application, and Shotwell didn’t show itself as valid enough for what I want to do (digiKam is much better), I decided to give it another try…

So first of all I owe lots of congratulations to all the people working on KDE, you did a tremendously good job. There are though a few things that I’d like to point out. The first is that I won’t be using the term “KDE SC” anytime soon; that still sounds dumb to me, sorry. The second is that I wonder if some guys made it a point to exaggerate on the graphical department, and then having to roll back. I remember how much hype was created around Oxygen and now it feels, that just like Keramik at KDE 3 time, they had to drop it back.

Another sore spot is the Italian translation — it’s not just awkward but in some places it’s definitely wrong! They translated “Plastique” (the theme name) and “Plastik” (the reference to the KDE 3 theme) as if they were “Plastic” — this is not the case! Keep the names the same as the original please. There are also a few more problems, including the fact that they did translate terms like “Serif”, “Sans Serif” and “Monospace” which … well they don’t really sound that good in Italian. At the end I simply changed the system language back to English.

There are still quite a few things that I have to take care of to set this up properly; right now it’s just a messy first set up and there are a few bugs that I have to report (including the fact that to upload originally-sized files on Flickr, KIPI is actually copying the original file to /tmp which makes it very unpleasant especially when you have that directory in tmpfs.

At any rate, you’ll probably read some more comments on KDE4 from me in the next few weeks, so be ready for them.

And what about imported libraries?

Following the previous blog here also a list of projects that seem to like importing libraries, causing code duplication even for code that was designed to be shared.

  • cdrkit, again, contains a stripped down version of libdvdread, added, of course, by our beloved Jörg Schilling; bug #206939; additionally it contains a copy of cdparanoia code; bug #207029

  • ImageMagick comes with a copy of libltdl; bug #206937

  • not even KDE4 seems to have helped libkcal which even in its newest incarnation ships with an internal copy of libical, causing me to have three copies of it installed in my system;

  • libvncserver comes with a copy of liblzo2; actually there are two, one in libvncserver and one in libvncclient; even the source files are duplicated!; bug #206941

  • SDL_sound, Wine and LAME seem to share some mp3 decoding code, which seems to come originally from mpg123;

  • cmake couldn’t stay out of this, it comes with a copy of libform (which is part of ncurses); follow bug #206920

  • I’m not sure what it is, but DigiKam, Numeric (for Python) and numpy have a few functions in common; the latter seems to have even more than that in common; bug #206931 per Numeric and numpy, and bug #206934 for DigiKam.

  • ghostscript comes with internal copies of zlib, libpng, jpeg and jasper; unfortunately jasper is also modified, for the other three there’s bug #206893; by the way, the copies are present in both the gs command and in the libgs library;

  • OpenOffice comes with loads of duplicated libraries; in particular, it comes with its own copy of icu libraries; see on bug #206889

  • TiMidity++ comes with a copy of libmikmod; bug #206943

  • Korundum for KDE3 has a copy of qtruby embedded, somehow; I wonder if it isn’t a fluke of our buildsystem; bug #206936

  • gdb contains an internal copy of readline; –bug #206947

  • tork contains a copy of some functions coming from readline; bug #206953

  • KTorrent contains a copy of GeoIP (and to think I removed the one in TorK as soon as I’ve spotted it); bug 206957

  • both ruby and php use an internal copy of – I think – oniguruma; I haven’t looked if it’s possible to add that as a system library and then use it; bug #206963

  • MPlayer seems to carry a copy of libogg together with tremor support; bug #206965

  • pkg-config ships with an internal copy of glib; bug #206966

  • tor has an internal copy of libevent’s async dns support; funny, as it links to libevent; bug #206969

  • gettext fails to find the system copy of libxml2, falling back to use the internal copy; at least it has the decency of using a proper commodity library; bug #207018

  • both Perl and Ruby have a default extension based on SDBM, a NDBM workalike; there seems not to be a shared version of it, so they just build the single source file in their own extensions directly, without hiding the symbols; beside the code re-use not being available, if a process loads both libperl and libruby, and in turn they load their sdbm extension, stuff’s gonna hurt;

  • enchant has an internal copy of Hunspell; probably due to the fact that old Hunspell built only static non-PIC libraries, and enchant uses plugins; bug #207025; upstream fixed this in their Subversion repository already;

  • gnome-vfs contains an internal copy of neon; funny as it depends on neon already, in the ebuild; bug #207031

  • KOffice’s Karbon contains an internal copy of gdk-pixbuf; bug #209561;

  • kdegraphics’s KViewShell contains an internal copy of djvulibre; bug #209565;

  • doxygen contains internal copies of zlib and libpng; bug #210237 ; this time I used a different method to identify it as doxygen does not export the symbols;

  • rsync contains an internal copy of zlib; bug #210244 ;

Unfortunately making sure that what I’m reading is true data and not false positive, looking at the output of my script, becomes more difficult now for the presence of multiple Sun JDK versions; I have to add support for alternatives, so that different libraries implementing the same interface don’t show up as colliding (they are that way by design).

Migrating from iPhoto to DigiKam

For my photos I’ve been using, up to now, iPhoto. The reason for this is that the big part of my photo collection is actually composed of my sister’s photos, which I downloaded directly with the MacBookPro when she asked me.

On the other hand, I use way more often my Linux box, and while iPhoto is a nice tool, DigiKam is not bad either, so I’d gladly move everything on Enterprise, as the mobility option for the photos is lost already once I moved everything on the external harddrive (as I now have more than 10GB of photos).

Unfortunately this migration is not going to be painless I’m afraid, especially because there are a few features I might be losing, unless I can spend some time writing stuff on my own.

The first problem would be having a way to save the photos from risks of losing data; the quick way would be to put them in raid. At the moment the photos are backed up by TimeMachine too, so I don’t risk losing them. I don’t think putting them in my /home directory will be a good idea: it’s just 14GB and the photos will soon be over that quota. I wonder if LVM can mirror partitions easily.

Then there’s the cleanness of storing the photos on the iPod, I don’t think Amarok can load them, can it? I have to check that out. And having them on the AppleTV too.

On the Wiki there are instructions on how to set up a DPAP (Digital Photo Access Protocol, I suppose it’s a relative of DAAP) server to share the photos with iPhoto, and AppleTV. I have to check that out, maybe writing an ebuild.

Of course the easiest way to handle this would be to have DigiKam actually providing DPAP support ;)

Another point I’d like to address is Flickr uploading. To upload to Flickr at the moment I’m using the FlickrUploadr, as the only plugin to allow that in iPhoto is proprietary commercial software. kFlickr is better than FlickrUploadr, but still isn’t well integrated (can’t just select an Album and say “upload to Flickr”).

Probably some of these concerns will be addressed with the KDE 4 version of DigiKam, I expect that to happen, but now I’m wondering if I should migrate already or wait for those to be done…

On the other hand, I wonder if there is anybody working on reverse engineering the protocol with which iTunes talks to AppleTV, it would be nice to be able to just command it through Amarok or DigiKam.

/me adds stuff to his TODO, which is probably way too big for this to ever happen.

But I certainly hope someone will write this stuff for me :) After all we all do our parts in the greater Free Software plan!

Cleaning up the digiKam docs mess

With the recent discussion about Google’s Picasa port to Linux, digiKam got its share of attention, being, for many people, a good alternative to Picasa, being Libre and native. And if you would consider installing Wine, even if you’re a GNOME user you should be ready to install KDE, too :)

But with this attention, there was again whining about the ~40MiB digiKam documentation tarball. The problem is that it is all user documentation, but with 19MiB of images to make it simpler to understand, and in the past the solution was “download everything, it’s user doc, you need it”, but this of course does not scale at all for dialup users or users that pay per traffic.

Today I reached an agreement with Mark (as representative of QA Team) to make use of the doc useflag for media-gfx/digikam to download this extra pack of documentation, as it requires time and a lot of downloads. It might be “out of standard” with respect of other KDE ebuilds, but I care about standards only when they make sense to me, and forcing 10 * $package_size MiB of extra downloads does not make sense to me.

To try limiting the impact even when using documentation, I’ve re-packed digiKam’s doc, so that all the languages are in a different tarball, to just have the English documentation you’ll download 19MB, and that plus something more if you’re enabling other languages, you’ll never get more than 30MiB for any language, it’s one hour less on 56k!

The problem now is testing the ebuild as it’s a long change.. and as carlo does not seem to like this approach, I’ll be probably the only one maintaining digiKam from now on, which means that it might take some more time to get it bumped and stuff (also because I have to split the tarballs).

I’m not sure if I’ll have time tomorrow, but absolutely in the next days I’ll write a maintainer’s guide for digiKam describing the problem, the approached solution, and the script, telling what it’s needed to run it. I have to thanks again the guys of the AMD64 team, as I’m letting pitr do the hard job for me (also because that makes it take just seconds to put the data on the mirroring directory ;) ).

I’m spending quite a bit of time on this, unfortunately :/ but hey, I like when my users are happy ;) at least they won’t hate me :)