App for vector renderer maps, using OpenGL ES 2.0 - Page 9 - maemo.org

Active Topics

Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 4 days, 12 hrs ago
Handbook (2)
to Maemo 7 / Leste by teroyk - 5 days, 11 hrs ago
more...

Page 9 of 13

Thread Tools

Zeta	2017-09-27 , 21:05
Posts: 339 \| Thanked: 1,623 times \| Joined on Oct 2013 @ France	#81

I have just published the first draft of the sources I am working on.

It is on github here : https://github.com/Sagittarii/IVI_HUD

I made a custom minimal dark style, reduced to only what matters while driving (so I kept only building outlines, removed everything related to water, beaches, ...). Colors are not great but were picked close to randomly for the tests.

I took a screencast to show what I have done so far with your package: https://youtu.be/dQsj-n-3JNo

The screen casting takes a lot of resources on my not so beefy desktop, so there is so lag introduced in the video that doesn't exist in the real usage.

You can see however the route in overview flat mode, and the seamless transition to the zoomed and tiled view for navigation (I have not yet added the behavior to have the smooth transition for the margin).

I put the destination of the route on the left double click, and the source on the right double click for those tests, using the tag property you added when requesting the screen coordinates.

When you look at it at this stage, there is almost no code on my side !

I have not found problems, missing API, or API that are difficult to use so far. Good work !

I will now work on integrate the GPS info on it, and turn-by-turn information from the OSRM data.

Quote & Reply |

The Following 4 Users Say Thank You to Zeta For This Useful Post:
Amboss, olf, PamNor, rinigus

Zeta	2017-09-27 , 21:15
Posts: 339 \| Thanked: 1,623 times \| Joined on Oct 2013 @ France	#82

Originally Posted by rinigus

Any ideas? If we go with the library approach, how do I register it in the QML to make it available?

I am no specialist of Python, so I took a look on the net, and saw that some people are registering objects to QML from python, like we do in C++:

Code:

QtDeclarative.qmlRegisterType(Graph, 'myPyQtGraph', 1, 0, 'PyQtGraph')

(Exemple taken from https://stackoverflow.com/questions/...nerated-window)

Wouldn't that be enough ?

Originally Posted by rinigus

PS: Zeta, margins are now a property through QRectF class.

Good ! I will take a look !

Quote & Reply |

The Following 2 Users Say Thank You to Zeta For This Useful Post:
Amboss, PamNor

	otsaloma	2017-09-27 , 21:49
	Posts: 141 \| Thanked: 1,530 times \| Joined on May 2011 @ Finland	#83

Originally Posted by Zeta

I am no specialist of Python, so I took a look on the net, and saw that some people are registering objects to QML from python, like we do in C++: [...] Wouldn't that be enough ?

Nope. We're not using PySide. We're using PyOtherSide, which is just a very thin bridge between QML and Python, no access to non-QML Qt at all (that's what makes it fast).

As to the original question, I'd strongly prefer a QML type, it's just so much more convenient. That of course is a problem Jolla Store wise, but I'm beginning to think that's not a big problem anymore as SFOS is not really a consumer OS anymore either. I do think we should try to get Jolla to change store policies, maybe introduce a beta "channel", but that's another story.

Quote & Reply |

The Following 3 Users Say Thank You to otsaloma For This Useful Post:
Amboss, rinigus, Zeta

MartinK	2017-09-27 , 21:58
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#84

Originally Posted by rinigus

Now the question from my side: how to make it simple to use the developed QML extension?

For C++ - based projects, its all trivial. We could just include corresponding library as a subproject in git and merge with the C++ project build system. As soon as QtLocation is allowed, all these projects are also Harbour-proof.

For Python-based map applications (Poor Maps and modRana), situation is not that simple. Its either I have to somehow make QML type available as a library or these applications would have to be converted to C++ in small parts (probably just to register type and define main). I presume that having extra lib requirement would make the application non-Harbour proof. The library has a small chance to be integrated into device either, since its LGPL3 (I used parts of the code from current QtLocation, hence the license).

Any ideas? If we go with the library approach, how do I register it in the QML to make it available?

Is there some technical difference why it can not be done in the same way as with PyOtherSide ? That is also a C/C++ codebase and is perfectly useable from Python via QML:

Code:

import io.thp.pyotherside 1.5

Actually there should be no real difference if the application is using Python or not if it goes via QML.

Or do you mean interacting with the widget directly from Python ?

__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)

Quote & Reply |

The Following User Says Thank You to MartinK For This Useful Post:
Amboss

MartinK	2017-09-27 , 22:00
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#85

Or are there some issues with distributing the QML plugin due to Harbour restrictions ? IIRC there have been some weird and rather stupid rules related to QML plugins.

Quote & Reply |

The Following User Says Thank You to MartinK For This Useful Post:
Amboss

	otsaloma	2017-09-27 , 22:16
	Posts: 141 \| Thanked: 1,530 times \| Joined on May 2011 @ Finland	#86

PyOtherSide provides a QML type, yes, but, PyOtherSide is part of SFOS and on the Jolla store whitelist of QML imports. Getting on that whitelist is unlikely and also store apps probably can't ship QML types for other apps to use, which means the library would need to go via Mer to SFOS?

Quote & Reply |

The Following 3 Users Say Thank You to otsaloma For This Useful Post:
Amboss, olf, rinigus

MartinK	2017-09-27 , 22:36
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#87

Originally Posted by otsaloma

PyOtherSide provides a QML type, yes, but, PyOtherSide is part of SFOS and on the Jolla store whitelist of QML imports. Getting on that whitelist is unlikely and also store apps probably can't ship QML types for other apps to use, which means the library would need to go via Mer to SFOS?

Oh I think I get it now - another unintended victim of the infamous Harbour policies I guess. But if I understand it correctly it should not be an issue when distributing via OpenRepos for the time being, right ?

Later one I guess we can try reaching out to Jolla for a solution - and if that fails we can probably do that packaging hack as well, but it sounds pretty horrendous to me.

Would be good if the trick reported by Zetta works - then people can just install a MapBoxGL "app" - like they already do with the OSMScoutServer plugins - and that would be it. No unholly packaging madness needed.

Quote & Reply |

The Following 3 Users Say Thank You to MartinK For This Useful Post:
Amboss, olf, rinigus

taixzo	2017-09-28 , 00:03
Posts: 958 \| Thanked: 3,426 times \| Joined on Apr 2012	#88

Still a relative QML newbie here - is it possible to have an optional dependency on a QML plugin, such that an app could import it and draw maps if the user has it installed but work fine (without that UI component) otherwise?

__________________
Saera: A Siri clone for the N900, N9(50) and Jolla

Follow me on Twitter: twitter.com/taixzo

Quote & Reply |

The Following 2 Users Say Thank You to taixzo For This Useful Post:
Amboss, rinigus

MartinK	2017-09-28 , 03:01
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#89

Originally Posted by taixzo

Still a relative QML newbie here - is it possible to have an optional dependency on a QML plugin, such that an app could import it and draw maps if the user has it installed but work fine (without that UI component) otherwise?

Yeah, that's possible at the cost of some additional code complexity:

https://github.com/M4rtinK/modrana/b...Screen.qml#L32

Basically just try to load the element dynamically and handle the failure gracefully. Alternatively you can have a fake element that does nothing that you will load instead of the one that failed to load:

https://github.com/M4rtinK/modrana/b...ation.qml#L108

Of course everything would be much simpler if QML supported conditional imports like Python does.

Quote & Reply |

The Following 4 Users Say Thank You to MartinK For This Useful Post:
Amboss, olf, rinigus, taixzo

rinigus	2017-09-28 , 06:53
Posts: 1,414 \| Thanked: 7,547 times \| Joined on Aug 2016 @ Estonia	#90

Zeta, otsaloma, MartinK, and taixzo: thank you very much for the discussion, its very helpful!

I will look into how to register QML type in the library and make it available for all apps. Probably would ask for technical pointers in devel list, that may save some time.

Converting Poor Maps and modRana to C++ shell will through out lots of neat packaging work done already, make it harder to compile/distribute (noarch vs arch-compiled apps) and is just plain untidy. If we will have to get apps out of the store, so be it. Maybe we could also negotiate with Jolla - in the end its a small community and these map apps are "must have" from user's point of view, I believe.

Edit: Zeta, thank you very much for the podcast and the code! Note that we now have an access to the map style editors that are quite good and simple to use. So, it should be simple to make new styles - much easier than it was with the Mapnik solution used by OSM Scout Server.