Re: removing Marble traces from the Subsurface tree
> On Aug 24, 2017, at 8:55 PM, Miika Turkia wrote: > > On Thu, Aug 24, 2017 at 11:49 PM, Lubomir I. Ivanov > wrote: >> with the new map widget we started phasing out the Marble globe... >> the transition is smooth in the lines of using NO_MARBLE as toggle - >> i.e. it either uses Marble or QtLocation. >> >> we should probably start removing it as a dependency from both c++, >> cmake and build scripts (i might needs some help for the later). but >> the question is - should we? do we want to keep it? >> >> i got no issue reports about the new Map widget which means all is good with >> it. > > Any idea about the following error message? > > qrc:/MapWidget.qml:45: Error: Cannot assign [undefined] to > QDeclarativeGeoMapType* > qml: MapWidget.qml: cannot find a plugin with the name 'googlemaps' It's exactly what it says. It can't find the plugin. No one has dealt with the case where the plugin isn't installed system wide on Linux. I simply haven't had the time to look at it. I think I have both the Windows and Mac package working. And Linux works IFF you install the googlemaps plugin systemwide. But if it's only in install-root, we don't pick it up when running the local binary. We did a lot of copying stuff around for Marble to deal with exactly the same problem, but we need to replicate that for this plugin. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: removing Marble traces from the Subsurface tree
On Thu, Aug 24, 2017 at 11:49 PM, Lubomir I. Ivanov wrote: > with the new map widget we started phasing out the Marble globe... > the transition is smooth in the lines of using NO_MARBLE as toggle - > i.e. it either uses Marble or QtLocation. > > we should probably start removing it as a dependency from both c++, > cmake and build scripts (i might needs some help for the later). but > the question is - should we? do we want to keep it? > > i got no issue reports about the new Map widget which means all is good with > it. Any idea about the following error message? qrc:/MapWidget.qml:45: Error: Cannot assign [undefined] to QDeclarativeGeoMapType* qml: MapWidget.qml: cannot find a plugin with the name 'googlemaps' I am currently getting no map when compiling myself. I am pretty sure it did work earlier with this laptop, but not anymore. But then again, it might have been different laptop where the new map was working. miika ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
removing Marble traces from the Subsurface tree
with the new map widget we started phasing out the Marble globe... the transition is smooth in the lines of using NO_MARBLE as toggle - i.e. it either uses Marble or QtLocation. we should probably start removing it as a dependency from both c++, cmake and build scripts (i might needs some help for the later). but the question is - should we? do we want to keep it? i got no issue reports about the new Map widget which means all is good with it. so, if we want to remove Marble i can start doing the above within a new PR with 2-3 patches. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: map: PR for language support and new cache folder
> Am 24.08.2017 um 22:38 schrieb Lubomir I. Ivanov : > > my vote is yes. +1 Robert ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: map: PR for language support and new cache folder
On 15 August 2017 at 02:58, Lubomir I. Ivanov wrote: > On 12 August 2017 at 18:33, Lubomir I. Ivanov wrote: >> >> the plugin itself needs 2 small patch to enable support for a >> PluginParameter for language and to enable Road map language support: >> vladest/googlemaps#12 >> > > vladest merged the above in the plugin upstream: > https://github.com/vladest/googlemaps/pull/12 > bump for this too, the map plugin upstream is ahead of our fork by a couple of patches. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: map: PR for language support and new cache folder
On 12 August 2017 at 18:33, Lubomir I. Ivanov wrote:
>
> one side effect here is that if the user has already cached road map
> tiles in one language, by switching the Subsurface language from
> Settings, the plugin will start downloading tiles in another language
> and it would end up with a mixture of tiles with different
> languageswe might want to clear the tile cache if the Subsurface
> language changes, but i would leave that to discussion,.
>
bump on this. should we clear the tile cache if the user switches languages?
my vote is yes.
how would that affect actual users, e.g. would a diver switch his
languages during offline mode while on a dive and would clearing the
cache create troubles ("my offline map is gone now").
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem
> On Aug 24, 2017, at 7:06 AM, Jef Driesen wrote: > > On 2017-08-23 06:43, Dirk Hohndel wrote: >>> On Aug 22, 2017, at 7:55 AM, Jef Driesen wrote: >>> I don't understand what you gain with those comments. I mean it's just >>> comments. Don't you need this kind of info at runtime instead? >> Yup - I simply have a tool that parses the source to give me the >> information that I want. > > Well, that's a pretty ugly and error-prone hack. You hard-code everything in > the application, based on whatever version that was used at build time (which > may not even be the same as at runtime). But the reason why that table > exists, is to let applications populate the list of supported devices > dynamically at runtime! And by doing it this way, you also depend on some of > the libdivecomputer internals. > > If we're adding this kind of annotations, then I prefer to make this > information available through the api. That will be a lot more useful, and > may also benefit other applications. That's ok, I didn't expect you to take the changes, which is why I didn't bother sending them to the libdivecomputer mailing list. I needed to get something that worked for our use case, and I needed it soon. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: RATIO iX3M DEEP computers compatibility and connection/configuration problem
On 2017-08-23 06:43, Dirk Hohndel wrote:
On Aug 22, 2017, at 7:55 AM, Jef Driesen
wrote:
I don't understand what you gain with those comments. I mean it's just
comments. Don't you need this kind of info at runtime instead?
Yup - I simply have a tool that parses the source to give me the
information that I want.
Well, that's a pretty ugly and error-prone hack. You hard-code
everything in the application, based on whatever version that was used
at build time (which may not even be the same as at runtime). But the
reason why that table exists, is to let applications populate the list
of supported devices dynamically at runtime! And by doing it this way,
you also depend on some of the libdivecomputer internals.
If we're adding this kind of annotations, then I prefer to make this
information available through the api. That will be a lot more useful,
and may also benefit other applications.
Something like what I proposed for the I/O refactoring:
For the I/O refactoring, I'm already planning to add an extra field
with the transport type. Since some devices support multiple
transports, the transport type will need to change into a bitfield. So
something like this:
{"Shearwater", "Petrel 2", DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},
Which doesn't tell me if this is an FTDI chip - which is one of the
things that I need to know.
That's quite easy: Suunto (solution, eon, vyper and d9), Oceanic (vtpro,
veo250 and atom2), HW (frog, ostc and ostc3) and Cressi (leonardo)
backends use an FTDI chip. You don't need to annotate each device for
that. Just check the family type.
Note that the usb-serial chipset is often not integrated in the dive
computer, but in the external PC interface. So there is not always a
nice one-to-one relationship. For example the official Suunto PC
interface uses an FTDI chip, but there are also third-party interfaces
available using a Silicon Labs chip (and those are quite common). And
some really old models still have a real serial port, and thus the user
can use any usb-serial dongle.
Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
