[Marble-devel] splitting marble and marblewidget

[Torsten Rahn]

Hi Kishore,

Ok, I only now figured that my suggestion below doesn't fully resolve the 
problem. Some .ui files -- especially the plugin-settings dialog --- need some 
additional .cpp and .h implementation magic in order to make the .ui files 
contents fly ;-)

So even if we expose the .ui files to the outside then there's still a problem 
there about how we share the backend-logic that is part of the accompagning .cpp 
and .h files. Right now I don't know a good solution to solve this. So any 
suggestions welcome :-)

Best Regards,

Torsten



On Freitag 29 Januar 2010 21:06:05 Torsten Rahn wrote:
> Hi Kishore,
> 
> This is a tricky situation indeed.
> 
> From what I recall the situation is like this:
> 
> For the settings dialog there are two versions:
> 
> * A Qt-Only version
> * A KDE version
> 
> Both versions use the very same nice .ui files for the tabs.
> There's a significant difference indeed between both:
> 
> * The Qt version gets linked together on the library level via
> src/lib/QtMarbleConfigDialog.cpp. This doesn't pose a problem.
> 
> * The KDE version however is creating the dialog inside the Marble - KPart
> component (which is also meant to be shared by applications -- but so far
> no other application except for Marble itself really makes use of it).
> See:
> 
> http://techbase.kde.org/Development/Architecture/KDE4/KParts
> 
> The KDE version is reusing the very same .ui files that are accessible to
> the Qt version. See:
> 
> http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT
> 
> Usually this technology would make it more easy to write settings dialogs.
> However we are making rather use of it in order to provide a higher level
> of KDE-integration.
> 
> 
> Now if we basically assume that the KPart would become part of the "Marble
> KDE integration layer" (which would for now get shipped together with the
> Marble KDE Application) then we'd still need to have some access to the
> .ui files from outside the libraries.
> 
> Hence the .ui files would need to get installed in a similar way as the
> header files of the library are installed.
> 
> I think this is what it boils down to: the .ui-files need to get installed
> in a similar fashion as the header files in order to let the Marble KPart
> reuse it.
> 
> Do you think this is feasible? :-)
> 
> Best Regards,
> 
> Torsten
> 
> On Freitag 29 Januar 2010 17:39:21 Kishore wrote:
> > While attempting to split marble and marblewidget so that the widget
> > could go into kdesupport I experienced a few issues.
> > 
> > Most issues were related to marblewidget in its current CMakeLists.txt,
> > installing header files being used by marble application. This i work
> > around by installing them.
> > 
> > Header files in marblewidget, used by marble in turn include the UIC
> > generated headers. This breaks the build. I have worked around this by
> > moving the inclusion into the respective cpp file and  only forward
> > declaring in the header.
> > 
> > Here is now where i am stuck. There are some UIC generated files of
> > marblewidget (code inside src/lib) that are being included directly by
> > code in marble. For example, marble_part.cpp includes
> > ui_MarbleViewSettingsWidget.h. Does anybody have a suggestion for working
> > around such requirements?
> > 
> > It seems to me that marble application has intimate knowledge about
> > marblewidget and this bond would need to be broken for a proper split.
> > Necessary functionality would have to be added to the widget to make it
> > usable by marble.
> > 
> > Any suggestions?
> 
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel