Tag: qt
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
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
Qt supports most types for most compilers…… but long double. I do not know why. When asking on #qt (IRC), people say that nobody seems to care. Well… I do. long double have some use in scientific software at least. If you ever need to use long double in QTest, you will need to add this somewhere in some of your headers used by unit tests.
This is tested with Qt 4.4.2 and 4.5, on linux(gcc 4.3.3) and windows (mingw/gcc 3.4.5).
Once you have this code, you can do things like QCOMPARE() between long double and so on.
namespace QTest {
template <>
inline char *toString<long double>(const long double &t)
{
char *msg = new char[128];
::snprintf(msg, 128, "%.123Lg", t);
return msg;
}
static inline bool qFuzzyCompare(long double p1, long double p2)
{
return (qAbs(p1 - p2) <= 0.00000000000001 * qMin(qAbs(p1), qAbs(p2)));
}
template <>
inline bool Q_TESTLIB_EXPORT qCompare<long double>(long double const &t1,
long double const &t2, const char *actual, const char *expected, const char *file, int line)
{
return qFuzzyCompare(t1, t2)
? compare_helper(true, "COMPARE()", file, line)
: compare_helper(false, "Compared long doubles are not the same (fuzzy compare)",
toString(t1), toString(t2), actual, expected, file, line);
}
}
Opale was an application written using koffice that I use to handle my personal accounts. Long ago I have dropped support for koffice (mainly because of the crappy/undocumented/buggy chart API) and since then opale was a kde-based application.
One year ago, i have started porting it to kde4, and, meanwhile, made it a Qt4 application. Using configuration, you can now have either a qt4 or a kde4 application. Actually, I have to say the kde4 stuff is not thoroughly tested. Anyway, the qt4 port is done and I now have Opale working under windows. Not that I really care, but that can be useful for others.
It was not until few weeks ago that kde4 was good enough for me (copyright me) so I can actually use this version of opale (yes, I know about running kde4 application under kde3, but no, thanks). Now that this version is tested enough, i release it as 0.9.
The roadmap for 0.10 is
One of the great things about Qt is that you can compile the code under esoteric OSs (mmh?) like Windows or MacOS. Although I’ve almost never used windows, I did the packaging of yzis. I used the Nullsoft Installer, which is ok.
I had several issues with static linking, and thought maybe some of you could give some help about it. Don’t ask why I want static link, this is not the issue here.
Problem #1:
The most important one is Qt itself. I expected that to be easy, but it is not. The FindQt4 shipped with cmake 2.4.8 or 2.6 is not really aware of static lib, or is it ? Nor is the one from kde svn. I’ve tried using the one from quassel-irc, but it fails as well. If you can help me with this, the code is available.
It seems (according to #qt on irc) that it makes sense to have two different Qt installed, one static and one shared. I did that (double the space used…) and in one of them did “configure -static” and recompiled qt. Now the *.a are much bigger, and though qyzis links against those *.a, it still depends on the DLLs, according to “dependencies walker”. Gr…
Problem #2:
Then, there is the problem of gnuwin32 tools. In the lib/ directory, you can find for example
And the DLL (libintl3.dll) is in the bin/ directory. I need to ship the DLL with qyzis, because cmake found the dll, and linked against libintl.dll.a. In a perfect world, I would like cmake to use the libintl.lib and have a static link, but i dont know how to convince cmake of doing that. Do you know ?
Problem #3:
How do you find out what kind of library a file is ? According to what I’ve found googling the web, libraries can have a wild number of different names (libX.dll, libX.dll.a, libX.lib, libX.a, all of this without the lib prefix and so on…). Even worse : libX.a for example, could be either a static lib or the stub for the DLL. Do you have clarifications about this ? Do you know of a reliable way to know which kind of library it is ? (DLL, DLL stub, or purely static).
FH laboratories
Recent Comments »