On Wed Sep 11 2013 at 10:09:44 PM, tsteven4 <tsteven4@gmail.com> wrote:
I've looked at some other distros today and Qt5 doesn't seem widely incorporated at this point, but that is not a reason to not support it if we can do it without too much pain while continuing to support Qt4.

They don't move very fast.  Another reason why I was treating Qt5 kind of like C++11 - good to know about, but it's out of practical reach for now.

I did install the pre-built Qt 5.1.1 on Fedora 18.  It works like the one I built except I needed a '-Wl,-rpath,/path/to/steves/install/lib'.  Its nice to

In some world, that's supposed to be handled for us, but I don't recall the details.  Maybe if we used qmake to generate the executable?  Maybe we "just" need to add more gunk to configure.in to special case this.  Not sure.

configure has two issues related to qmake/lupdate/lrelease, one is renaming of qmake/lupdate/lrelease that the redhat based distros like to do. 
Gross. I wish they'd quit that.
Another is the path.  Today the three executables are all treated
independently.  I am actually happy that we can set the correct answer as options passed to configure.  Note that the assumption all 3 executables are in the same place isn't always valid, e.g. this isn't true in the Fedora 18 mingw32 case. 

I recall building the GUI with mingw32 was painful enough that I ultimately gave up and just cranked up a VM and did it with QMake.  

Teaching configure about mingw32 is possible, but probably ultimately a distraction.  Certainly running lupdate and lrelease in such a configuration is just kind of a distraction.

Another issue is the renaming of the Qt libraries in Qt5.  qmake -query doesn't help there.  We could run qmake on a test .pro file and get it to

Is there a qmake-qt5-fedora-random-name that is more helpful?

I am still holding onto makelinuxdist.sh.in, it does seem to help me a bit with testing.

If it's valuable to you, that's fine.  It's dead to me. :-)
I made the change to optionsdlg you requested.  I have tried testing with 'export LANG=fr_FR.utf8'.  While it is sort of fun not much gets translated:(

French is indeed not very translated.  See http://www.gpsbabel.org/tips/translate.html for an approximation of just how translated it isn't.

You can see the results of thorough translations at http://www.gpsbabel.org/screenshots.html

Knowing what you know about how the GUI works, you know why the the "Format" spinners aren't translated.    I just checked and it's not like French is particularly obscure in our user base - it's our fourth most popular language - but when it comes to translations, nobody complains, offers help, or responds to direct requests to help with the translations.   {shrug}  I really thought that would be a _huge_ thing with GPSBabel 1.4.4 but mostly it was wasted effort from what I can tell.

In case you're into data-based decisions, of our last 10,000 GUI users the breakdown looks something like:

34.44000 English
15.94000 German
12.77000 Spanish
6.19000 French
4.96000 Russian
4.53000 Italian
3.14000 Dutch
2.84000 Chinese
2.50000 Portuguese
2.07000 Japanese
1.91000 Polish
1.13000 Czech

[ clipped at 1% ] 

So over the last few years, LOTS of speakers of these languages have looked at somewhat broken or non-existent translations and we've not been able to capture their interest in helping improve that.

If you have any ideas how to improve that, please speak up.



On 9/11/2013 8:02 PM, Robert Lipe wrote:

On Wed Sep 11 2013 at 7:14:49 PM, tsteven4 <tsteven4@gmail.com> wrote:
This patch seems to allow Qt5 to be used with the gui.  I have only
tested on linux.  With Qt5 I only have an installation I built myself.
Both the cross and native versions of Qt5 on Fedora 18 seem to have bits
missing that we need.  This patch is compatible with Qt4.  It would be
nice if we could test it with some more standard installation of Qt5.

I've consciously stayed away from Qt5 so far to avoid making the Qt4 users (you in particular :-) crazy, but this is pretty minor, so if it makes it easier for someone, OK.

 I have
found I need to use
./configure .... QMAKE=xxx  LUPDATE=yyy LRELEASE=zzz
where xxx, yyy, and zzz are the Qt5 versions of the above programs.
Then I have to edit the Makefile and change QtCore to Qt5Core
and add -fPIE to GBCFLAGS or set QT_LIBS and EXTRA_CFLAGS appropriately
on the make command line.

This seems to hint that qmake -query isn't doing its thing or we're not looking for it hard enough.  It should hock up a set of tuples for things like QT_INSTALL_BINS:/usr/some/screwy/path/that/varies/between/every/stupid/OS and you should be able to find LUPDATE in QT_INSTALL_BINS.  At a glance, configure.in isn't using it as aggressively as it could; it seems to hope that LUPDATE and LRELEASE are in your $PATH.

It's probably worth saying that I'm not really certain the top level configure/make thing and the gui level play as well with each other as they could.

Unless makelinuxdist.sh.in solves some problem for you, I think we can drop it.  None of the Linux distros seem to use our packaging; they all want to do their own thing.

It does catch my eye that we're probably misusing tr() in optionsdlg.  tr really needs to be called on something resembling a string literal; the toAscii() here is papering over that problem, but there's no way that a translation will work there.  Please drop the tr and the .toAscii().data() stuff completely before committing.

Localizations is something I was really exicted about for 1.4.0 and something we put a lot of time into.  Except for outright bugs during the early betas that resulted in NO strings being found, I'm surprised at how little feedback we've gotten in terms of new translations.  We admittedly have a weird mismash of English-only in the core (which we could address, but I'm not sure it's wise - I don't _want_ command line arguments or error messages changing and the reality is we display little else) and localized text in the GUI.   This is about the same balance as, say, the Linux or OS/X kernel vs. the GUI and for similar reasons.

Other than that little tweak, commit away.

Thanx for working this out.

Other than these changes in the gpsbabel directory all the changes I
needed for the gui are in the patch (and r4600).

I think we need to continue to support Qt4, but if we can support Qt5 at
the same time then that seems like goodness.


How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
mailing list  http://www.gpsbabel.org