Thought about a Qt port

[Dirk Hohndel]

Alberto Mardegan <mardy at users.sourceforge.net> writes:

> On 03/30/2013 07:40 PM, Dirk Hohndel wrote:
>> Someone else brought up this issue with respect to picking Qt5 over
>> Qt4...
>> 
>> We want to be able to support at least the following distros:
>> Fedora (under support, currently 17/18)
>> openSUSE (under support, 12.1-12.3)
>> Ubuntu (12.04, 12.10, 13.04)
>> Debian (Squeeze, Wheezy - we actually dropped Squeeze support for a
>> while - so that's not quite as critical as Wheezy will be out before we
>> are ready).
>> 
>> I don't think Qt5 is available for all those, is it?
>
> In Ubuntu 12.04 it's available under a PPA, in the others it should be
> already available.
> Anyway, I agree we can support Qt4 as well.
>
> Here's how I'd do it:
> https://github.com/mardy/subsurface/commit/407e8e831f6b75d4d27a54224b1429f72dcab586

I see some great work in there - but this is what I get, trying to
compile

gcc  -o subsurface main.o dive.o time.o profile.o info.o equipment.o divelist.o deco.o planner.o parse-xml.o save-xml.o libdivecomputer.o print.o uemis.o uemis-downloader.o qt-gui.o statistics.o file.o cochran.o device.o download-dialog.o prefs.o webservice.o sha1.o gps.o linux.o  -lxml2 -lz -lm -L/usr/lib64 -lxslt -lxml2 -lz -lm  -lQtGui -lQtCore   -lgconf-2 -lglib-2.0   /usr/local/lib/libdivecomputer.a -L/lib64 -lusb-1.0    -lzip -lz   -lpthread -lm -losmgpsmap -lgtk-x11-2.0 -lsoup-2.4 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgio-2.0 -lgobject-2.0 -lglib-2.0   -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lglib-2.0   
/usr/bin/ld: qt-gui.o: undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO /lib64/libstdc++.so.6 so try adding it to the linker command line
/lib64/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

linking with g++ solves that but then of course the resulting program
doesn't run...

I am happy to track things in a Qt branch in the official
repository. And I'm ok with things in that branch not working /
compiling at times. One thing that I do insist on are Signed-off-by:
lines for every commit...

> Changing topic: currently, there are three files which are used to
> implement the functions which read/write the application settings:
>   linux.c (GConf)
>   windows.c (registry)
>   macos.c (CFPreferences)
> Do we want to keep them, or use the QSettings class [0]? QSettings uses
> the Windows Registry in win32 and the CFPreferences API in OSX, and I
> believe it should be possible to configure the paths in such a way to
> match the current ones. However, in Linux it uses plain .ini files (by
> default, stored under ~/.config/<company>/<application>.conf, IIRC, but
> it can be changed).
> Given that subsurface isn't sharing its data with other applications, I
> don't see a strong reason to prefer using GConf (or GSettings) to
> ~/.config/subsurface.conf; however, we'd need to address the problem of
> migrating the existing user's configuration there (*if* it is a problem;
> maybe we can just apologize and ask the Linux users to reconfigure the
> app?).
> This probably is a bit premature, but it can have an impact on how the
> UI stores the configuration (in any case the C API in pref.h would stay,
> if it's used by other C files).

As Linus said - we are totally fine with switching to QSettings.

/D