[Portland] Project Portland, RuDI and the Generic desktop adapter

[Lars Knoll]

On Saturday 10 December 2005 15:40, you wrote:
> Lars Knoll wrote:
> >On Friday 09 December 2005 16:54, you wrote:
> >>nf2 wrote:
> >>>Lars Knoll wrote:
> >>>>The other problem is interoperability between different major
> >>>>versions of the same library (Qt3 vs Qt4, Gtk2 vs a future Gtk3).
> >>>>These usually define similar sets of symbols which could lead tod
> >>>>larger problems when loading them into the same address space.
>
> I thought about that again and i believe that different major versions
> of Qt and Gtk but also KDE and GNOME should be able to live in the same
> process anyway. 

Sorry, but that's wishful thinking. The realities are different. Different 
major versions of the same library cannot live in the same process space. 
Reason is that they have common symbols while the implementation is usually 
different. Try with whatever library you want: gtk 1/2, freetype 1/2, Qt 
2/3/4, etc. Trying to use them together is just asking for trouble.

> The main reason is migration. KDE3 applications should 
> be able to run on a KDE4 desktop and use KDE4 infrastructure (like a new
> KIO for instance).

Migration doesn't mean they have to link against all libs. All you need 
is to be able to integrate into the desktop. project portland is meant to 
help achieving exactly this goal.

> So i suppose QT4 and KDE4 should use a namespace that doesn't conflict
> with QT3 and KDE3.

Which is not done as you want to offer an easy migration path (ie. be source 
compatible to a large extend).

> For Gnome/Gtk+ this will be harder, because C doesn't have namespaces.
> (perhaps using "gtk3_" as prefix in function names instead of "gtk_").
>
> >Another problem is that libraries expect certain global objects/data to be
> >initialized. These objects will be different in the different libraries,
> > so you'd have to make sure they get initialized on the fly. Unfortunately
> > that is a non trivial problem to solve as well.
>
> I think that's mainly a problem of Qt/KDE, because of this subclassing
> of QApplication, which is not a good approach IMHO. The global data of
> QTCore/Qt/KDE should live in seperate objects and not as an instance of
> a single monolithic class.

I agree, and we're about to fix this for KDE4 (ie. get rid of KApplication). 
Still this doesn't solve all issues, as you have to be rather careful to 
initialize everything when you load a plugin. We've done it before, but it's 
tedious and prone to hard to debug errors.

Lars

> I think GNOME has a more modular approach here. AFAIK you can call:
>
> g_main_context_default ()  // creates the global data of the default
> main loop context if it doesn't exist.
> gnome_vfs_init()
> gtk_init()
> gnome_init()
>
> in any sequence, because they all use seperate global variables.
>
> Perhaps QT4 and KDE4 should be modularized, similar the GNOME platform.
>
> Just my thoughts. :-)
>
> Cheers,
> Norbert