[Marble-devel] Qt namespace patch

Martin Koller kollix at aon.at
Fri Sep 26 07:01:54 UTC 2014

Hi Dennis,

On Friday 26 September 2014 05:45:47 Dennis Nienhüser wrote:
> Hi Martin,
> I see the problem you're facing and appreciate the work you put into the 
> patch. However I am concerned about maintaining (read: not breaking) it 
> in the future.

Breaking it is not a problem, since when I hit such a situation, I can simply
send you another patch. For everybody else, it does not make any difference.
But it would be simply much more work on my side if my changes do not get integrated
at all, since I would need to keep the patches up to date locally over the whole marble
codebase over and over again.

> The real problem IMHO is that Qt does not (really) use namespaces in the 
> first place. The ability to change that dynamically with a configure 
> option seems insane to me and asks for trouble (like here, shifting 
> additional work on Qt dependent libraries).

There is a very good reason to be able to define a namespace at configure time,
and in fact this is exactly what we need and why we (the company I work for)
use it in our commercial product, namely:

The operating system (e.g. a Linux distribution) already ships Qt (without a namespace).
Our product is also using Qt, but we use and distribute the Qt libs with the product
and do not use the system installed ones (because sometimes we get patches from Digia
which have not been integrated into the mainline or because the Qt version we compile
against is a newer one than the one of the Linux distribution - which is usually the case
when you look at the enterprise Linux distributions).
Also, our product contains a Webbrowser plugin, which is a shared lib, linked against Qt,
loaded by some webbrowser - and here you have the problem: the webbrowser already uses
the system installed Qt libs, and our shared lib is then loaded into the same process
but is linked against a different version of Qt being already in memory ... and that
The solution is: use a namespace for the Qt libs we deliver

> Regards,
> Dennis
> Am 12.08.2014 15:49, schrieb Martin Koller:
> > Hi,
> > 
> > to be able to compile the (Qt-only) marble lib when using a 
> > self-compiled
> > Qt5 which was configured with a namespace (configure -qtnamespace
> > MyNameSpace ...)
> > one has to use the Qt macro QT_FORWARD_DECLARE_CLASS when forward
> > declaring a Qt class
> > (or directly including the class header), so e.g. instead of
> > class QString;
> > one needs to write
> > 
> > Note that using this macro makes sure it compiles with or without 
> > namespace.
> > 
> > The attached patch does this for all marble files
> > (some files needed to be tweaked manually as the
> > QT_FORWARD_DECLARE_CLASS macro needs to be known
> > by a header, so sometimes it's simpler to just include the Qt header
> > directly instead of doing an include
> > of the header containing the macro and then using 
> > 
> > Hope you can integrate it.
> > 
> > _______________________________________________
> > Marble-devel mailing list
> > Marble-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/marble-devel

Best regards/Schöne Grüße

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at

More information about the Marble-devel mailing list