On Monday 05 August 2013 18:25:23 Jan Kundrát wrote: > 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-nor > > malised-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. >
I will convert null plugins into tests. > > 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. > Yes, It is fixed. > > 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 Ok. -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
