[Marble-devel] Review Request: add APRS data display to marble

Mon May 10 17:44:46 CEST 2010

> On 2010-05-08 12:54:38, Bastian Holst wrote:
> > According to http://code.google.com/p/qextserialport/ the qextserialport library is BSD license. That would be ok for marble, BUT in general copying a library into the applications source code would result into a lot of maintaining work (checking for updates, etc.).
> > IIRC the qextserialport is only needed for the serial port support, right? Couldn't we then simply have qextserialport as an optional depency and make the serial port support optional?
> > IMHO that would be the best option.
> 
> Torsten Rahn wrote:
>     Well, there is a catch with this solution that we need to be aware of:
>     
>     - Distributors might make qextserialport a hard dependency when installing Marble. With increasing dependencies this would make it less likely that Marble would get added to a LiveCD.
>     
>     - Distributors might create the package without the qextserialport dependency. In that case all ham-radio users would have to compile their own binary which would make it unlikely that it would get widely used together with the ham device. 
>     
>     I'd be very careful with depending on more libraries if you just want to borrow from a single case.
>     
>     In this case I'd prefer copying the code since it's only about a single class.
>     
>     A proper solution for this problem at a later stage could be to have a marble-extra-plugin package which would contain plugins with more special use cases (like ham radio support) and which would require qextserialport as a package then. That wouldn't harm Marble deployment and wouldn't affect the APRS plugin negatively. But so far we haven't tackled the modularization problem yet and I wouldn't want to jump the gun for it just because of this single plugin :-)
>
> 
> Torsten Rahn wrote:
>     > I'd be very careful with depending on more libraries 
>     > if you just want to borrow from a single case.
>     
>     That was meant to read:
>     
>     I'd be very careful with depending on more libraries if you just want to borrow from a single class.
>

Well, I believe in google they had to pick a license and thus picked BSD as it was the cheapest.  The author that I spoke with, however, indicated they were striving for as free as possible hence the "public domain" statement.

No packing of it exists anywhere, as far as I can tell.  In fact their distribution contains only files without anything else (not even any sort of build system at all).  It's intended, I believe, to be dropped into each application as needed.  I'm not sure that's how I would have done it (in fact, it isn't) but that's what they did.

So my choices forward (and this is the stumbling block that's really prevented me from updating the patch as I feel stuck):

1) remove serial port support from my patch and release "the full patch" somewhere else.  Not the ideal choice since I agree that without it being distributed in the base it would require third-part compilation.  I'd likely try to release binaries too but I don't want to have a pseudo-fork under my possession.  I have enough OSS packages I'm responsible for already!

2) leave it in but don't compile it by default, which really isn't any better

3) leave it in and have it compiled by default.

When thinking of things like this my default point-of-view for all the other packages I work with is "what's best for the user".  In this case, what is best for the user is certainly #3 but I understand it may not be possible.  Many times "what's best for the user" simply can't be done due to restrictions we put on ourselves.  The icons would be best distributed as well (or redrawn) but I can't get a license statement for those at all even though if I could contact the original author and follow-on contributors they'd be more than happy to re-release them (they're already being re-included into multiple other projects, including xastir, which is GPLv2+).

Anyway, let me know which of the above you'd prefer and I'll create another patch that meets it.

- Wes

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3843/#review5515
-----------------------------------------------------------

On 2010-05-04 02:54:40, Wes Hardaker wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3843/
> -----------------------------------------------------------
> 
> (Updated 2010-05-04 02:54:40)
> 
> 
> Review request for marble.
> 
> 
> Summary
> -------
> 
> Adds support for displaying HAM radio aprs data to the map pulled from three different possible sources.  The TCP/IP source is the default that is enabled and usable by everyone.  The others would require special sources and default to off.  The icons, which are binary files, can be found at:  http://www.hardakers.net/code/marble/aprs-icons.tar.gz
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsFile.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsFile.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/data/CMakeLists.txt 1121250 
>   trunk/KDE/kdeedu/marble/src/plugins/render/CMakeLists.txt 1121250 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsConfigWidget.ui PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsGatherGen.pl PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsGatherer.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsGatherer.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsGatherer_mic_e.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsObject.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsObject.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsPlugin.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsPlugin.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsSource.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsSource.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsTCPIP.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsTCPIP.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsTTY.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/AprsTTY.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/CMakeLists.txt PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/GeoAprsCoordinates.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/GeoAprsCoordinates.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/posix_qextserialport.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/qextserialport.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/qextserialport.cpp PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/qextserialport_global.h PRE-CREATION 
>   trunk/KDE/kdeedu/marble/src/plugins/render/aprs/win_qextserialport.cpp PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/3843/diff
> 
> 
> Testing
> -------
> 
> 
> Screenshots
> -----------
> 
> screenshot of california with data
>   http://reviewboard.kde.org/r/3843/s/378/
> 
> 
> Thanks,
> 
> Wes
> 
>