-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Albrecht,
> Having a closer look, a few more questions came up: > - should some of the non-standard formats be included in the gdal build > (<http://www.gdal.org/formats_list.html>)? For me, I added Jasper > (JPEG2000 support) which also comes with a free license. ECW also looks > interesting, but I don't understand the license to be honest... Yes, ECW is important, especially as this might be the format of my next GPS. ;) I never understood their license in detail, too. It's something like: It's proprietary code, and as long as you register and compile that stuff for your private use, it's ok to us. If you distribute you have to talk with us. Don't know how they are concerned about commodity libs packaged with opensource applications. > - I noticed that some of the gdal tools are called. Isn't it possible > to use library calls instead? Otherwise that means that proj4, gdal and > all dependent libs and resources have to be packaged separately and > installed in /usr/local. Of course, the deploy tool should *not* pull > in those libs. Possible, but I'll have to look into that. Hmmm.... GT uses gdalwarp and gdal_translate for referencing maps. And GPSBabel for reading other formats than GPX and QLB. It would have taken a lot more time to sink into the GDAL API to do it the clean C way. Usually I prefer that way, but in this case wrapping system calls was much easier. For GPSBabel there is no library by intention of the author Robert Lipe. And pay attention! GDAL is not only the libs, it's all those text files containing the parameters for correction, too. If the libraries fail to load these referencing will go bad. GDAL/Proj4 is really tricky, that's why I simply install FWTools on Win32. > - Are there any other apps QLandkarteGT calls and that would have to be > packaged? I found gdal_translate, gdalwarp and gpsbabel. The latter > seems to be optional, right? They are all three optional. Referencing maps will not work if you drop gdalwarp and translate. as far as I recall it's just those three. > >> I think you have to enforce transparent background for >> QStyleOptionMenuItem in void CMegaMenu::paintEvent(QPaintEvent *e) > > That's unfortunately not the full story. The Painter and Style are only > hints to the theme engine. And the MacOSX theme engine seems to enforce > the background pixmap to menu items, hiding the background, even if I > configure colour and brush hints properly. But that's *really* > cosmetic. The ugly workaround is to run with "-style motif". :/ bad. Maybe you just switch off the big background icon for OSX and add a small one to the menu heading like in old QLandkarte. That would look less like a bad hack. Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAktFosEACgkQhhhJXTUlePpa+gCfb2W6eLQvcHAcyZ6Zy1BKVewi TfkAniSyEtzbRSgRaTyqWUjmaqj+FvOK =17HF -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ QLandkarte-users mailing list QLandkarte-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qlandkarte-users
