On Saturday, 29 June 2013 10:26:26 CEST, Pali Rohár wrote:
- What's the point of storing the plugin path in the settings?
Check how the localization is loaded to see what I mean with
the path discovery.
I see that trojita loading localization from PKGDATADIR. But I do
not see where it is defined. PKGDATADIR in autoconf/automake
systems points somewhere to /usr/share/<program>/ but for storing
libraries it is better to use system /usr/lib (or other dynamic
linker path like /usr/lib/x86_64-linux-gnu/ on multiarch).
Library path can be reused from cmake.
Ah, I missed this mail when I did the review in my today's mail -- sorry
about that.
You've found a bug -- the PKGDATADIR used to be set by qmake (see commit
9adbd5d690e42b98ea091bfba58d88f03a4e9d77), but I forgot to port this when
switching to cmake -- filed as [1]. The idea is that this points to
$PREFIX/share/trojita which is determined at build time.
At runtime, "/locale" is appended to that path and .ts files are looked up
in there. I was hoping that the plugins could be looked up from
PKGDATADIR/plugins. Perhaps that's a wrong path -- it sounds like a bad
idea to place binaries in there, after all.
The general point is still valid, IMHO -- the path to use for plugin lookup
shall IMHO be specified at build time. Perhaps it will be something like
/usr/lib/trojita/plugins. Either way, the places to look for plugins shall
IMHO be limited to:
a) the directory determined at build time,
b) application's applicationDirPath() + "/plugins"
- The signal/slot signatures in connect(...) are not
normalized
Do you mean this?
http://marcmutz.wordpress.com/effective-qt/prefer-to-use-normalised-signalslot-signatures
Yes.
This will not work, because in class is full QPointer object -
not pointer or reference.
My bad, sorry.
- What is the NullAddressbookCompletionJob and why is it
returning bogous data?
Plugin for testing if interface, plugin loader and completion in
gui working. Nothing for users.
I'd like to have this information in the doxygen docs. I know that some
classes in Trojita which I wrote are not exactly a perfect example in this
discipline, so sorry for applying double standards here.
Anyway, unless you're going to use some of these classes in the automated
tests (you probably should, at least for the password operations), the null
classes shall probably be removed.
Now I have problems with cmake. It does not autogenerate two moc
files, so I had to add QT4_GENERATE_MOC to force cmake for manuall
generation. Another problem is that all plugins not compiling
without adding line "#include "file.moc" at end of plugin cpp file.
I assume that this is now fixed, right? I don't see anything like that in
current pali-gsoc-merge.
Another problem could be qt5. My linux distribution does not have
qt5 yet. What do you use for compiling with qt5? I can use
virtualized system in qemu, but need to know which distribution
have qt5 out-of-box and working fine.
Getting it building was a lot of work for me (manual builds from git on
Gentoo). I know that Gentoo has some packages, but some pieces like qttools
are still missing (and Trojita needlessly depends on that, unfortunately).
I don't know how much work is to get another branch from another repo being
checked by KDE's Jenkins. Perhaps the easiest way is to get you push access
to the repo at github which is set to perform CI using Travis, some hosted
CI solution. That way you can know whether your branch at least builds.
Under the hood, Travis uses Ubuntu 12.04 and the Qt comes from some
third-party PPA -- see .travis.yml in Trojita's source tree.
Any KDE plugin has to be disabled when building with Qt5 as you can't have
both Qt4 and Qt5 linked into the same object. The other plugins should
still work, though.
[1] https://bugs.kde.org/show_bug.cgi?id=323197
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
