Category: KDE
I’m still using this small utility that displays the activity of ‘emerges’ on the misc gentoo boxes I’m admin for. I’ve wanted to add a graphical interface for very long, but did not have the time… until recently. So here it is.
It is available for download from the homepage and as a mercurial clone.
As time goes, my mercurial ‘activity’ plugin has got more and more options. Useful and requested options of course, but still it kinda clobber the –help output and it is more and more cumbersome to play with. This is why I have introduced a new frontend, based on Qt, to play/decide about those options.
First, let me issue a very strong statement: this is optional and it is still possible to use the extension in an desktop-less environment (aka a server). This is an important point as many people, including myself, use the extension to provide activity information on some html page, maybe even integrating with the mercurial web interface.
So how does it work ? The extension now has a new option –mode. There are currently three possible values:
This looks like this:
You’ll notice that the bottom of the window contains the corresponding command line, that you can copy/paste.
Last thing: the extension is now a python module, and as such, the way you configure the extension in your ~/.hgrc has slightly changed. Instead of having
activity=/home/orzel/hg/hgactivity/activity.py
you should now have
activity=/home/orzel/hg/hgactivity/activity
Well… you know how it is, you get used to a tool, and even if some brand new software is now available, you keep on using this old stuff. In his case, i’m speaking of xv, whose last release was in 1994. It’s still my default viewer for all image formats in my KDE/firefox/whatever settings.
So it’s old, it’s unmaintained, but there’s something even worse : it’s not Free Software. That’s probably the reason nobody took off maintainance, by the way.
Because of all those reasons, most distributions do not ship it anymore, and that’s a shame (my distribution of choice, Gentoo, does though, congrats!)
This project is about providing a key-to-key compatible image viewer, GPL, and maintained. Using a toolkit sush as Qt, it’s not very difficult. The two main features are “Free Software” and “maintained”. I use it everyday, trust me it will be maintained 
I’ll also probably provide binaries for MacOS and Windows, because we basically have this for free thanks to Qt portability.
qxv is a single binary, and does not depend on any other files (despite, of course, dynamically linked libraries, whatever they are).
The 0.1 release provide those features (all present in xv)
More information:
You might know that there’s a new kid in the C++ compilers list ; clang. Llvm has been around for quite some time, but until recently the only way to make use of it was through the somehow cumbersome llvm-gcc which binds the gcc C/C++ frontend to the llvm backend. People (mostly Apple) have been working since 2005 on a frontend dedicated to llvm, clang. It is already used ‘in production’ by Apple for the C and objective-c languages.
The C++ part is still very alpha, but i still wanted to play with it. Among other things I wanted to try compiling some Qt projects using qmake. So i hacked this quick&dirty linux-clang mkspec. To use it, uncompress the tgz in your $(QTDIR)/mkspecs/ , edit the clang.conf file to suite your own paths, and do something like:
qmake -recursive -spec linux-clang
make
I’m using it with Qt-4.6, and it works for me (c). As a last advice, I highly recommend the svn trunk instead of the last release for clang. The website has clear information about how to do this.
* Download linux-clang.qt-4.6.mkspecs.tgz
qmake (sort of) supports lex/yacc, but modern people prefer to use flex/bison. If you google, you can find some tricks like convincing qmake that yacc is spelled ‘bison’ and so on. Morever qmake supports for lex/yacc has several drawbacks, such as weird naming scheme, and (when using the tricks), dependencies are not building files in the right order.
Finally, I created my own *.pri files, and here they are:
% cat flex.pri
flex.name = Flex ${QMAKE_FILE_IN}
flex.input = FLEXSOURCES
flex.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.lexer.cpp
flex.commands = flex -o ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.lexer.cpp ${QMAKE_FILE_IN}
flex.CONFIG += target_predeps
flex.variable_out = GENERATED_SOURCES
silent:flex.commands = @echo Lex ${QMAKE_FILE_IN} && $$flex.commands
QMAKE_EXTRA_COMPILERS += flex
% cat bison.pri
bison.name = Bison ${QMAKE_FILE_IN}
bison.input = BISONSOURCES
bison.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.cpp
bison.commands = bison -d -o ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.cpp ${QMAKE_FILE_IN}
bison.CONFIG += target_predeps
bison.variable_out = GENERATED_SOURCES
silent:bison.commands = @echo Bison ${QMAKE_FILE_IN} && $$bison.commands
QMAKE_EXTRA_COMPILERS += bison
bison_header.input = BISONSOURCES
bison_header.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.hpp
bison_header.commands = bison -d -o ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.parser.cpp ${QMAKE_FILE_IN}
bison_header.CONFIG += target_predeps no_link
silent:bison_header.commands = @echo Bison ${QMAKE_FILE_IN} && $$bison.commands
QMAKE_EXTRA_COMPILERS += bison_header
Of course, the proper way to use those is to include them and then define FLEXSOURCES / BISONSOURCES as needed. Example:
include(flex.pri) include(bison.pri) FLEXSOURCES = myproject.l BISONSOURCES = myproject.y
Twenty years ago, I was reading some books about Unix at the local library. By the time, it was really difficult for me to see, touch, or test an actual unix system and reading books was the closest I could get.
I remember that among the numerous very good ideas ™ in this system, one totally buzzed me : processes and memory protection. A piece of software was protected from other pieces. If one crahes, the other ones could still keep on doing their stuff. Amazing feature, isn’t it ??
Years later, and until very recently, I could proudly say to my friends: “I use linux, I don’t have such problems that you have in Windows and MacOS”. Well, of course, now at least MacOS is based on a serious kernel and the Windows kernel is far better in this regard. But still, unix has had it for very long, and among them, my favourite Unix : Linux.
And then, people started to talk about plasma. It is cool, it is great, it is beautiful. One of the reasons I like KDE so much, is that I am very happy with the technology choices made by the project over the time (do you remember the drop of CORBA ?). I’m not into buzz and fancy desktop, so I did not pay much attention to plasma at the beginning. Later on, I started to try KDE trunk again. For months, it was about: compile, start, wait few seconds, plasma crashed, and the whole desktop/X session restarted.
Then, it got better : plasma crashing would not make the whole session crash, and plasma would handle its own crashes gracefully by restarting. Trust me, I really like KDE, but I could NOT resist to think “Hey, they now handle crashes as well as MS Word do!, great job!”. Well, of course, It was still pre-alpha times, you are not supposed to expect more at this time.
Still some months pass by, and came the beta time. I could finally get into KDE and plasma would not crash on startup. So I tried this new plasmoid thinguy. I added few plasmoids, played with them, even configured some. I tried to add a new one… and WLANG, suddently the whole thing crashed.
Do you see my point ? One of the plasmoids made the whole plasma thing crash. We are back 30 years ahead in time. End of process separation and memory protection. Back to the “don’t try to touch anything, it WORKS, don’t disturb it” and “I do not dare trying this new cool stuff because it could crash it all”.
This sounded weird. Really, really weird. I wondered, and learned that indeed plasma was only one process. It seemed to me like a very bad design choice, but I do not know much about all of this, so I just kept my faith in KDE and did not worry too much. I don’t know anything about internals. I talked to a few people, on IRC, in real life… but nobody seems concerned. Nothing about that on the FAQ, not even on the (short) architecture documentation.
As time goes by, people put almost anything into plasma. I mean it : anything. Developers and users for once seem to agree, and everybody is happy. I still do not really understand the need to put a browser in a plasmoid, but if people enjoy that, I don’t have a problem with this. Free software is all about fun, isn’t it ?
After I updated to KDE 4.2.1, I’ve spent one hour to fix it, finally removing the plasma configuration files to get a usable system. I did not look further, but I guess I could have removed only one part of one file, or maybe even just remove a faulty plasmoid.
I don’t mind the hour I’ve spent… but I worry about the design of plasma. I do not dare asking plasma people, as it seems so.. deeply obvious. They MUST have thought about it, mustn’t they ?
Today I had to kill one of my konsole because one of the software I’m working on was eating all the memory. I used the great CTRL-ALT-ESCAPE kill feature and that saved my computer. Once recovered, I was really surprised to see that all my konsoles were dead. “ps” could confirm this. I usually have 4 or 5 konsoles with 5 or 6 tabs each. Lot of opened vi inside and so on. A doubt came to me and i started several new konsole, and then issued a “ps aux | grep konsole”. You’ve guessed it, only one was present. I rushed on konsole source code and konsole/src/main.cpp confirmed my fears : konsole uses only one process on purpose, through the use of KUniqueApplication.
I don’t understand and I’m sad about this.
Don’t get me wrong , I still think that a lot of things are still done right in plasma (and KDE in general): separation between data and views (nothing new, but still a great thing to do), packaging (though it’s not done yet, I like the ideas). And it looks darn good, that’s right, too.
I just feel very uncomfortable with this. This is the first time ever in more than 10 years that I am not happy with a KDE design choice, and a blog post looked like a great way to release this embarassment. As usual I’m afraid that people will read this post lightly, will feel insulted, and will answer with even more insults.
This week-end we did the final conversion of the eigen2 source code repository. I shall describe here the few problems we had, as a feedback to the community.
Eigen original purpose was to help provide linear algebra for several KDE parts. As such, it was until now developed inside the KDE repository, which (still) uses subversion. Let it be clear that KDE did a wonderful job at hosting eigen repository, even though several accounts needed to be created for people who only contribute to eigen and not KDE as a whole. Eigen is getting big enough to live and release its own way , but eigen keeps very strong relationships with KDE.
Here is the script that was used for the conversion. The version of mercurial (and of the mercurial convert extension) was 1.2.1.
hg convert https://orzel@svn.kde.org/home/kde \ --authors eigen.authors \ --config convert.svn.tags=tags/eigen \ --config convert.svn.branches=branches/eigen \ --config convert.svn.trunk=trunk/kdesupport/eigen2\ eigen.hg
We faced several problems. Fortunately all but one could be resolved patching python code. That would have been a lot more difficult using, for example, git. Speaking of git, we have found no easy way to make such a conversion, mainly because KDE repository is so huge and it seems git needs to parse the whole history of the whole repository just to convert this part. Eigen is quite small. It took mercurial two hours to convert it, almost all of which was due to network latency between my computer and KDE repository.
In mercurial, the default branch name is ‘default’ (same as ‘trunk’ on svn). If you browse a mercurial repository (using the wonderful tck/tk frontend or the web browser), each changeset is tagged with the branch name (and with every tag name is there is any). There is an exception to this, if the branch is ‘default’, nothing is displayed, as a convenience for clarity. Which is great. Using the script I present here, the convert extension would create a branch according to the name of the branches/ subdirectory, which is fine. Though the name for the main branch, the one called ‘trunk’ in svn and usually called ‘default’ in mercurial, was named ‘eigen2′ here, probably because the main directory was named this way.
I have found no way to prevent this using command line arguments. I have tried to play with the –filemap option, but failed. The final solution I used was to locally patch my mercurial (yes, I know, this is ugly):
--- /usr/lib/python2.6/site-packages/hgext/convert/subversion.py
+++ hgext/convert/subversion.py
@@ -777,6 +777,8 @@
branch = self.module.split("/")[-1]
if branch == 'trunk':
branch = ''
+ if branch == 'eigen2':
+ branch = ''
except IndexError:
branch = None
In mercurial, tags are created by updating a file called ‘.hgtags’ which maps changesets (identified by their md5 sum) to a string. At the end of the conversion process, ‘hg convert’ will create such a file and check it in the mercurial repository. Unfortunately in our case, the file was not created on the right branch neither, so I also had to patch mercurial for this :
--- /usr/lib/python2.6/site-packages/hgext/convert/hg.py
+++ hgext/convert/hg.py
@@ -178,7 +178,8 @@
self.ui.status(_("updating tags\n"))
date = "%s 0" % int(time.mktime(time.gmtime()))
- extra = {'branch': self.tagsbranch}
+# extra = {'branch': self.tagsbranch}
+ extra = {'branch': 'default'}
ctx = context.memctx(self.repo, (tagparent, None), "update tags",
[".hgtags"], getfilectx, "convert-repo", date,
extra)
Once the conversion was done, we noticed a file called src/Core, which should not be here. A diff with a svn checkout would confirm that this is the only difference. I have traced back the problem to a bug in svn which would allow a ‘svn copy’ to be done even if the destination name would already exist.
In our case, a directory called ‘Core’ was copied on top of the file ‘Core’. As such, the underlying file was never deleted, and mercurial kept it. Mercurial did quite well dealing with this actually.
See this wonderful commit
http://websvn.kde.org/?view=rev&revision=72256
And this is how the repository looked like just before this commit:
http://websvn.kde.org/branches/work/eigen2/src/?pathrev=72254
We could not manage to fix this problem, and we just removed the file after the conversion. Having this file would anyway not prevent using eigen2 in compilation.
It seems the bug is fixed in svn 1.6.2: I can not reproduce this on a small test svn repository. A bug was filled for mercurial with all details, but as we cannot reproduce this behaviour on a test svn repository, this will be very difficult to solve. We for sure can not use KDE repository to test, it is far too huge for this.
We now have eigen2 repository on https://bitbucket.org/eigen/eigen2/ and so far everything seems ok. The repository is worth 7.3 Mb, which is perfectly honest. We can now grant or revoke write access very quickly and easily without disturbing KDE admins. And of course we also have all the wonderful advantages of DVCS.
I have the problem for my application Opale, which used to be KDE only and is now both Qt and KDE.
The first thing I’ve done is to switch from *.po (gettext) to *.ts (qt), because Qt can not (or can it ? tell me how !) handle gettext files. Then, I needed to use qApp->addTranslator() to load the Qt translation files (the *.qm generated from *.ts). So far it’s easy.
But then I had a problem : if I start the application, the strings from KDE are not translated. Especially the menu entries created using KStandardAction::*. The reason is that the application does not load any *.mo, and this is what triggers the loading of KDE messages.
The solution is to give “kdeinit4″ as second argument to KAboutData::KAboutData() instead of 0 as is usually done. Instead of trying to load your application translation, fail, and finally not load anything at all, it will load the ones for KDE directly. And you can still use qApp->addTranslator() , isn’t it great ?
Thanks a lot to tsdgeos and Chusslove on #kde-devel for their help, they are the ones who found out.
If you want an example of how to do, you can refer to Opale’ source, and most importantly to the following files:
We are used to polished and great tools from the trolls, but qmake has always been the big exception to this: ugly documentation, lot of undocumented tricks, and missing features.
For me the biggest one was that it would not automatically create the rule to transform *.ts to *.qm in the generated Makefile. I have been trying for very long to fix this problem. This is especially a shame because this is Qt’s very own translation stuff, and qmake should really knows about it.
Today, thanks to ‘luks’ on #qt, I know have the solution, and I think it’s really worth a blog entry, for my own record, and to help all those having the same problem. : put this in a file updateqm.pri and include it from your *pro(s).
isEmpty(QMAKE_LRELEASE) {
win32:QMAKE_LRELEASE = $$[QT_INSTALL_BINS]\lrelease.exe
else:QMAKE_LRELEASE = $$[QT_INSTALL_BINS]/lrelease
}
updateqm.input = TRANSLATIONS
updateqm.output = ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.qm
updateqm.commands = $$QMAKE_LRELEASE ${QMAKE_FILE_IN} -qm ${QMAKE_FILE_PATH}/${QMAKE_FILE_BASE}.qm
updateqm.CONFIG += no_link
QMAKE_EXTRA_COMPILERS += updateqm
PRE_TARGETDEPS += compiler_updateqm_make_all
Thanks to the great work of the gentoo KDE packaging team, I have been able to update to KDE 4.2.1 yesterday. And since then, a couple of processes suck up all my CPUs.
The first one is a well-known issue : lancelot does that when used with Qt 4.5. Ok, this one was quick to remove.
The second one is plasma. Somehow I was not really surprised : it often happens. I usually first blame gentoo for that, and I’ve tried to re-install a few things in order to fix it (like emerge @preserved-ebuilds, and so on…). But actually, that was not the problem. On #gentoo-kde, some other people seem to have either this very same problem, or worse (crashes). Removing your ~/.kde4.2 directory is said to help. That’s too much a loss for me so I have spent a little time to narrow the solution a bit.
And finally the solution is to remove only share/config/plasma*. How come did I not first think about it ?
So if you have the same problem, hopefully now you know how to fix it.
FH laboratories
Recent Comments »