Thought about a Qt port

[Alberto Mardegan]

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

We require the developer to have the Qt bin/ directory in the path, and
then we ask qmake about the Qt version; depending on that, we pick
different pkg-config modules (it may be that more things will have to
end up in that if/else switch, in the future).

[...]
>> Adding basic C++ and Qt support to the Makefile isn't difficult. Adding support 
>> for Qt resource files is also trivial, if that feature is ever needed. Support 
>> for moc and uic can be done, but without a good dependency scanner, subsurface 
>> will have to obey some strict rules about where the #includes can be placed 
>> for the generated files. Or manually adjust the Makefile to declare the 
>> dependencies.

Thiago, I would simply go for declaring the dependencies in the
Makefile. Something like:

OBJS = main.o ... qt-class.o qt-class.moc.o

and then have a rule

%.moc.cpp: %.h
    @echo '    MOC' $<
    @$(MOC) $< -o $@

(I didn't try this, but it should work)



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).

Ciao,
  Alberto

[0] http://qt-project.org/doc/qt-4.8/qsettings.html

-- 
http://blog.mardy.it <- geek in un lingua international!