[Marble-devel] RFC: Layer Management Class, Marble Qt-style Painter API, DGML 2.0

[Andrew Manson]

Hi Torsten,

Well the two bugs that i noticed are quite linked to your last 
sentiment, about breaking stuff unintentionally ( and hence i point no 
fingers ) . Currently when the GPS is enabled within the globe 
projection it floats on top using the flat projection rendering, which i 
would attribute to whatever you guys did to be able to merge the two 
projections in runtime. So my first job is to figure it out and fix it, 
i presume that it won't be too hard ;) the second bug is more simple, 
that the GPS doesn't render in flat map mode ( and in that mode it 
should currently be right. ) but that should be easily fixed if i fix 
the first one.

As for the AbstractLayer classes, i agree with your need to hide the 
internal workings from any potential implementers and realise now that i 
was not working along the most optimal use case ( possibly because of my 
recent training in Software Engineering ). And i think that once the new 
framework is in palace GPS support should become a plugin, giving the 
added benefit that gpsd will no longer be needed to build marble. But 
obviously this is later down the line.

So for now my jobs are to fix the bugs, enable the GUI and possibly look 
at the mechanism used to "get" the GPS data, I will have a look at 
possibilities when i resume my work. As for the Gui, could you please 
suggest what functionality we want to make available for the end user? 
At the current time ( probably ) anything you name i can implement with 
minimal effort because of the way that my work over the summer was 
structured so something to work towards will be much appreciated. In 
fact any help with the UI will be much appreciated and if anyone revamps 
the UI i will plug in the back-ends, but suggestions will be helpful too.

Before i sign off i do have a few questions. first off what is the story 
about marble compatibility? i know that we wanted to keep it compatible 
to qt 4.2 and also to KDE (4.0) but i wonder now have we updated the 
minimum requirements to QT 4.3? secondly, when is the KDE 4.0.2 tag? i 
have been looking around to find this for a while but cant seem to see 
anything anywhere, is there an updated release schedule since 4.0? and 
lastly, I'm just curious about this one but why is the reply-to header 
in Marble-Devel set to sender and not to sender and group? its not 
really important but i like to keep discussions in the open personally.


Torsten Rahn wrote:
> Hi Andrew :-)
>
> On Tuesday 29 January 2008 16:22:34 you wrote:
>   
>> upcoming challenge. I have been improving my skills lately and will hope
>> that by the end of this coming college year i might be a much more
>> useful member of the marble team having furthered my learning in a lot
>> of new fields.
>>     
>
> ... that being said we were pretty happy with your work during GSoC. 
>
>   
>> I have planned to get back into marble development ( and fix the 2 bugs
>> that i found with the GPS stuff in the KDE 4.0 release )
>>     
>
> Which 2 bugs are those? I'm not aware of bugs in the GPS stuff.
> Additionally we need to enable GPS in the GUI. In trunk we are heading towards 
> Marble 0.6 already. If you'd like to make any changes it's a good time to 
> mess around in SVN right now ;-)
>
>   
>> As for the Layer Management Class, i will be glad to attempt to help out
>> considering that this was mostly my motivation to include the
>> AbstractLayer Classes during the Summer. 
>>     
>
> That's great to hear!
>
>   
>> I understand that in my absence 
>> the concept was not followed through on my part but i plan to rearrange
>> my time a little better so that i can help out in an effective way.
>>     
>
> Well, with the most recent changes and while talking to someone who is making 
> actually use of the MarbleWidget it became more and more apparent to me which 
> requirements are mandatory for proper layer management. Additionally I had to 
> look through your code and while doing so I realized the shortcomings of the 
> current AbstractLayer code. There's nobody to blame here -. after all I have 
> refactored many of my own parts in Marble myself - one of the most 
> embarrassing examples being the MapTheme class which I wrote originally and 
> which needs to get completely refactored now as it IMHO starts to fall apart 
> already under the weight of what we are trying to accomplish.
>
> I think the approach outlined in the layermanagement.txt document is a bit 
> less complex and easier to get than the current AbstractLayer stuff that 
> hides its own functionality within deep levels of inheritance. 
> However concerning the Layermanagement-RFC nothing is set in stone yet and 
> we've still got to make sure that it will work for GPS and other use cases as 
> well.
>
>   
>> I presume that none of the code in AbstractLayer will be needed after
>>     
>
> I'm not sure about that yet.
>
>   
>> this new layer management class, so i can hope to move the GPS
>> implementation across in the near future?
>>     
>
> I'd suggest that we move the AbstractLayer directory over into the gps 
> directory soon. Until we've finished our work on the layer management class 
> our GPS support can still rely on the "old" AbstractLayer concept. Once 
> everything is complete we can refactor it to make use of the new classes and 
> concepts. Eventually the backend should also get refactored to either use 
> QSocketNotifier or maybe GeoClue (if it makes sense).
>
>   
>> Once again i am sorry that i have not been available but i am back to
>> stay now ( at least after my exams ) so feel free to call on me to
>> implement anything or help out ok?
>>     
>
> No problem and your presence and help is very much appreciated.
> The only thing I'd like to ask you is this: For future final releases (this 
> includes minor releases, like 4.0.2) make sure that you test the GPS source 
> code right before tagging and please also make sure that there are no 
> embarrassing bugs left :-) 
> In a project such as Marble where it's easy to break stuff unintentionally due 
> to its size and complexity this is something that needs to be done.
>
> Best Wishes,
>
> Torsten
>
>   
>> Andrew
>>
>> Torsten Rahn wrote:
>>     
>>> Hi Everybody,
>>>
>>> With Marble 0.6 we'd like to introduce several aspects which will make it
>>> easier to extend Marble further and to make it more flexible.
>>> Additionally it will give 3rd party developers a nice API to draw their
>>> own features in Marble and to create their own plugins:
>>>
>>> 1.) A Layer Management Class which allows for Qt-Plugins to be used for
>>> Layers.
>>>
>>> 2.) A Qt-style API which will allow you to paint geographic features on
>>> the MarbleWidget with ease.
>>>
>>> 3.) A revised much more sophisticated version of our map storage format,
>>> called DGML. DGML is basically the integrative file format that takes
>>> KML. GPX and possibly other formats and merges their contents into
>>> Marble's map. Additionally DGML and the other formats are meant to get
>>> parsed by the QXmlStreamReader based geodata library.
>>>
>>> Currently we are still at planning stage - well, actually we have started
>>> with some aspects already, like the legend section. But there's a lot of
>>> work ahead.
>>>
>>> If you are using Marble or the MarbleWidget to create your own maps then
>>> it would be nice if you could have a look at our proposal. If you feel
>>> that something is missing or wrong, please speak up.
>>>
>>> http://websvn.kde.org/trunk/KDE/kdeedu/marble/docs/layermanagement.txt?re
>>> vision=766731&view=markup
>>>
>>> Given that implementing the whole spec is expected to be quite some work,
>>> we'd be happy about anyone volunteering to help out. Much of the work
>>> doesn't require math skills or a deep understanding of Marble code. Most
>>> of it just requires some experience with Qt.
>>>       
>
>
>
>