Qt Divelist sorting..

Dirk Hohndel dirk at hohndel.org
Fri May 24 06:38:14 PDT 2013


On Fri, 2013-05-24 at 10:56 +0200, Henrik Brautaset Aronsen wrote:
> On Fri, May 24, 2013 at 10:29 AM, Sergey Starosek
> <sergey.starosek at gmail.com> wrote:
>         I think using sat maps (Google) is the only right way for
>         Subsurface.
>         
>         Neither of other maps provide good aerial images of shoreline.
>         Just
>         try to find Blue Hole (Dahab) on any of the stock maps.
>         
>         Could that be an installer to deliver/download restricted maps
>         and put
>         them into $XDG_DATA_HOME/marble/maps ?

> 
> We could also just drop Marble and embed Google Maps
> directly: http://stackoverflow.com/questions/8515598/how-to-add-google-maps-in-my-application-in-qt/10806964#10806964

What Marble gives us is the beautiful globe (remember Linus complaining
loudly that the Gtk maps didn't realize that Fiji and Hawaii were next
to each other), the cool animations and all that. So I don't want to
drop Marble. The legal concerns mentioned by the Marble team about
bundling Google maps support appear to be very much about some other
things you can do using marble (including navigation) which are clearly
not allowed by the terms of use. After reading through all this a third
time it became clear to me that all the things that we may or may not be
in violation of we also are in violation of with Subsurface 3.1 - namely
the caching. So I definitely want to bring in Google maps into the
marble Globe and that will look amazing.

The big issue is that the packaging for Marble on various OS is...
challenging. On Fedora it brings in 40+ unrelated packages. On Arch
Linux there is no libmarble and instead you need to install a random
educational app and that magically installs all the dependencies that
you need. On Mac it appears to build more than a hundred other
components. I haven't even tried to build this for Windows, yet :-(

We definitely need to engage with the Marble developers and I'm secretly
considering doing the same thing we do with libdivecomputer: drive the
packaging as a project specific to Subsurface and compile it in the way
it creates the least amount of dependencies.

But I'll cross that bridge when I get to it. First we need the Qt
version to close all the feature gaps that we still have.

BTW: over the past two weeks we have made tremendous progress. There are
a few gaping holes (no preferences dialog, so you need to set your
default file and units and things by hand in the config file -- I think
we'll get this fixed today; download from divecomputer fails even though
all the pieces should be there -- I wanted to fix that last night but
instead spent 5+ hours getting the equipment editing to do what I wanted
it to do), but overall it looks amazing. I'd love to see more people
play with it and tell us what you think.

We obviously know about all the pieces that aren't implemented. Check
the bugs filed on trac.hohndel.org and if you find a piece that isn't
implemented and that isn't mentioned there, please add a bug against
Qt-UI.

But we also want to make sure we find the bugs / issues in the things
that have been implemented. Patches welcome (Henrik has been sending
some), or file bugs on trac.hohndel.org

And we want to discuss some of the work flow decisions that we made. I
really like the way editing works now (click on something in the Notes
tab and you start editing - same for equipment). There are a few rough
edges and missing pieces of course, but I think it's a massive
improvement.

Anyway, please come join us and help us out - with code, with bug
reports, with comments.

/D

/D




More information about the subsurface mailing list