Now the only other similar regression is see is the initial lack of colorization for the atlas map theme. Might be a nice follow-up issue to look into if you feel like it ;)
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Aug 31 2017
Thanks a lot! I've just tested it and it works nicely indeed (also for the other vector-based maps).
Aug 28 2017
Looks very good to me.
Aug 21 2017
Looks nice to me in general.
Looks nice to me in general.
Aug 20 2017
Any further updates? :)
Aug 14 2017
Looks good to me in general. I guess the only other consideration that we can postpone for now is binary compatibility.
Jul 2 2017
Jun 12 2017
May 15 2017
Dec 17 2016
I don't see the big advantage of this approach. Both approaches have their advantages and disadvantages: For the inverted approach you have flicker for coast- and sea areas (which looks equally bad and odd to me). Implementing the inverted approach will have a slight performance advantage if we don't manage the background color in a more sophisticated way. Implementing the inverted approach means on the other side that we have to develop a special dedicated plugin that will paint the pole caps blue - to avoid landmass-white circular polecaps beyond +/-85 degs latitude.
Dec 11 2016
Dec 10 2016
Dec 9 2016
Dec 8 2016
Dec 7 2016
Dec 5 2016
Dec 4 2016
Dec 3 2016
Dec 2 2016
I've tested you patch and the only thing left to complete this task seems to be the compilation warning above. Apart from that it looks great.
Sorry, still a nitpick: during compilation I get this:
Nice, still some minor nitpicks.
Dec 1 2016
In D3563#66539, @Rakete1111 wrote:Didn't know about isEmpty(), but should have, I feel bad now...
If by OSD you mean the notifications from KDE, I don't think it is necessary: Unix users can always look at the debug output, just Windows users would have to debug the application to get those messages, so that's why a QMessageBox is better for them I figure.
Nice start :-) I guess that's a successful liftoff for our rocket!
Nov 30 2016
Nov 29 2016
Nov 28 2016
Nov 27 2016
Nov 26 2016
Nov 23 2016
I've taken the low-hanging fruit:
So I benchmarked the Mercator projection on my desktop PC. AbstractProjection::geoCoordinates() uses MarbleMath::gd() while AbstractProjection::screenCoordinates() uses its inverse MarbleMath::gdInv().
Since screenCoordinates is used by far most of the time we put our focus on gdInv: