Board index FlightGear Development Canvas

Phasing out MapWidget post 3.2

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Phasing out MapWidget post 3.2

Postby Hooray » Tue Jun 24, 2014 2:18 pm

This is just a "meta" topic to keep track of work that remains to be done to extend the Canvas/MapStructure side of things so that the PUI/C++ MapWidget can be phased out, as per:

Subject: How to display Airport Chart?
zakalawe wrote:Looking good, can you get this working so we can replace the map-widget for 3.0?


Specifically, there are some C++ data structures that still need to be exposed to Nasal via cppbind so that we can implement features available in the Map dialog and the hard-coded ND
http://wiki.flightgear.org/Canvas_GUI#PUI_Widgets

And then there's labels/decluttering that will be useful at some point:

Subject: Canvas: Label uncluttering
TheTom wrote:
zakalawe wrote in Wed Sep 19, 2012 12:34 pm:Deciding an API for limiting symbols / databoxes is going to be very important - the NavDisplay and MapWidget already have different solutions for that. In particular there's a notion of symbol priority - basically I sort the available symbols by priority, and the display can be limited to the most important 10/50/100. This is also the approach taken by some real world map displays.

I've already had a look at this and seems like it already works not too bad ;) But I'd like also to try oder variants and methods. What I think would improving is grouping together similar items and only split them based on their distance/displayed size. I've also talked to a friend who is developing a new flightmap system and we came up with an idea to preprocess static parts of the map and calculate good placements possibly with a non realtime algorithm and only place the dynamic data (mainly aircraft) during runtime.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Hooray » Wed Jun 25, 2014 6:02 pm

I looked through Tom's GUI commits (MessageBox & AircraftCenter dialogs) and played around with turning our ~20 lines of MapStructure code (in map-canvas.xml) into a generic Canvas Widget so that it can be easily used in dialogs (including support for multiple widgets per dialog!) - this no longer uses any PUI/XML, and the checkboxes can be linked to MapStructure layers, i.e. to hide/show layers (I am not yet using any layouting here, which is why things are rendered to the same group currently) But overall, it's pretty promising, and it should allow us to easily reuse MapStructure as a widget in other dialogs (e.g. route manager, ATC):
Image

We'll probably want to extend the MapWidget.new() ctor such that people can directly request certain layers - and extend each lcontroller file to contain GUI labels for the corresponding checkboxes. With some wrappers, we could probably even expose styling to the GUI and allow things to be styled at run-time. :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Philosopher » Wed Jun 25, 2014 6:38 pm

Haha, GUI for customizing the "internal" values would be great :D (and a good test of whether the symbols actually support it – with the StyleableCacheable I believe being so dynamic would be supported)

If you want to push what you have now, I would love to help finish it (as a good exercise for reviewing the layouting for me :)). We probably can add a mask to the map, if that isn't already supported by the layout. Btw, much as his help benefits us here, Tom mentioned that his C-130J will need a map one day, in fact one really like MapStructure now provides (from what I saw in the pictures), as well as other layers (shapefiles?), so we are also helping him out here, particularly since the layers will be styleable and will hopefully adapt easily.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Phasing out MapWidget post 3.2

Postby Hooray » Wed Jun 25, 2014 6:56 pm

this should all be supported as is already - I am just having to do quite some reverse-engineering here, because these are all "uncharted waters" - and we also have some "hard-coded" assumptions in MapStructure that we need to get rid of, i.e. stuff like canvas.get(view[x])/2 :D
But overall this is pretty cool stuff. And the amount of code is surprising small.
MapStructure-wise, we should add a "GUI" hash that contains a label and a tooltip field, so that we can procedurally create the corresponding tooltips.
Making styling completely procedural, i.e. creating a dialog to allow styling to be customized and saved via userarchive, would be pretty fancy - but would require some metaprogramming, i.e. we would need to validate fields and make sure that they're available. I guess that would touch the realms of gen.nas :D

And yes, the layouting stuff is neat - and we have a few things that would benefit from being turned into "proper" Canvas widgets, such as your REPL (once it uses Tom's ScrollArea) or some of D-LEON's work.

Totally agreed regarding MapStructure/ND stuff - it's becoming as generic as it gets meanwhile, so that Gijs' original code can now be re-used in a ton of places, which really is kinda cool and proves the whole point about "framework-centric" development.

Eventually, supporting shapefiles/GIS formats would be really awesome, because we could do pretty sophisticated stuff then. I may look into it at some point if nobody beats me to it...
I can push what I've got now, but please keep in mind that it's mostly copy/paste & reverse engineering, all based on going through the recent GUI/Aircraft Center commits, so my degree of "understanding" is still fairly ... humble :-) Given me a few hours to clean it up a little bit and you'll see for yourself!
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Hooray » Wed Jun 25, 2014 7:31 pm

Philosopher wrote in Wed Jun 25, 2014 6:38 pm:If you want to push what you have now, I would love to help finish it (as a good exercise for reviewing the layouting for me :)).


ok, I have removed the non-working stuff and committed a very basic version to the canvas-hackers team clone - this still needs the checkboxes to be hooked up to each layer's show/hide method, and clipping/masking needs to be implemented like you say - but I guess correct layouting should handle that (gotta look at ScrollArea.nas).

Also, I have copied several methods from ScrollArea.nas that should probably be just implemented as interfaces - i.e. stuff for resize() handling.
If you are going to touch this, just let me know what you'd like to play with - so that I won't touch the same stuff :D

https://gitorious.org/fg/canvas-hackers ... for-canvas
https://gitorious.org/fg/canvas-hackers ... 2b0370f385

Like I said, I'd probably extend each lcontroller file with a GUI hash that contains label & tooltip for each checkbox, so that we can procedurally create a proper checkbox for each layer.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Hooray » Wed Jun 25, 2014 9:47 pm

ok, I've pushed a few more changes and prototyped the whole label/tooltip thing - I think this is what we'd basically need to also create styling-related dialogs procedurally, i.e. to affects colors, line width, font etc - for that, we'd need a handful of validation routines and helpers to ensure that each "styleable" attribute is handled properly, e.g. stuff like 1) filename (SVG/PNG), 2) font, 3) colors, 4) fonts, 5) size/scale - I think we can reuse the helpers that your created for options & style handling, i.e. some kind of default hash that is processed and which gets "type" information for each attribute so that a dialog can be procedurally built, including the validation routines. We could probably even provide a live preview.

But for now, I find it more interesting to get the layout/clipping stuff to work properly - i.e. things should become really generic once we can easily show multiple independent widgets per dialog. And I think, I'll change the code to render all those checkboxes as part of the actual widget, so that each widget gets its own control buttons. That would then also allow us to easily show a few tabs with pre-selected map profiles, i.e. different layers shown/active.

Being able to reload & re-initialize running MapStructure layers at run-time will be the next cool thing for RAD :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Hooray » Sat Jun 28, 2014 9:51 pm

Philosopher wrote:We probably can add a mask to the map, if that isn't already supported by the layout.

I haven't checked if there's any flag to do so automatically, but like you said, it works when done explicitly (which is also the method used by Tom's own ScrollArea code in DefaultStyle.nas):

Image

But like you said, it would probably be a good idea to add some optional flag for making this the default behavior.

MapStructure-wise, I still have to check if the bounding box info is sufficiently sane to be used for centering the map when clipping is applied, or if we need to look at the tf/transformation properties, which will be important for complex displays that may have multiple maps active.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby onox » Mon Dec 15, 2014 2:24 am

How's the pure Canvas map going? I noticed a couple of bugs in the Canvas-in-PUI map in 3.3 git:

  1. The VOR radial is always true. It doesn't listen to the "Magnetic headings" checkbutton. In northern part of Canada true heading is used (because of the extreme magnetic variation), but anywhere else magnetic.
  2. When I click "Aircraft heading up", the radial of the VOR doesn't get rotated.
  3. I cannot click and drag the map.
  4. The blue "flight history" line is very thick.
  5. When I zoom in, the map moves and display certain symbols to the edges for a split second, but then hides them. It should instead hide them before doing the translation of the symbol.
  6. The map hides too much symbols at the edges in any case. It should be more like the PUI map IMHO, which displays a symbol if it could be visible in the GUI widget.
  7. When I zoom in or out, the relative location of various symbols changes. For example, go to CYRB and zoom in on the map. The VOR seems to be between the 2 NDB's. If you zoom all the way out, the VOR moves to the left of the 2 NDB's. The old PUI map doesn't have this problem.
  8. Sometimes labels of waypoints are difficult to read.

Since the old PUI map doesn't support new-navradio, I'm just hoping the Canvas-in-PUI or pure Canvas map can be improved a little and made more smooth.
onox
Retired
 
Posts: 431
Joined: Fri Jun 20, 2014 2:45 pm

Re: Phasing out MapWidget post 3.2

Postby Hooray » Mon Dec 15, 2014 2:49 am

Here's an update, I recently sent to a few contributors, in response to Zakalawe's recent posting on the devel list:

Hooray (via PM) wrote:Referring to: http://wiki.flightgear.org/MapStructure ... map_dialog

Hi Zakalawe, I'd suggest we move this discussion over to the Canvas sub-forum: neither of the people involved in this particular effort (porting the MapWidget code to Canvas/Nasal) are regular/active posters on the devel list (as can be seen by the lack of feedback) - and there are a few other issues that you seem to be unaware of, especially a few ones on the C++ side, where you could probably help getting things reviewed/commited:

For example, Gijs has recently added additional support for pole projections to the Map dialog, which would make sense to add to the corresponding Canvas projection helpers, as we originally discussed in the gitorious merge request (which you reviewed/committed back then) - absent that, there would be a pretty serious regression.

Equally, there are some other performance-related things that would require tweaking before the hard-coded dialog gets phased out, most of which we have already discussed/prototype-d on the forum. For instance, we also keep talking about label-decluttering (again, see the Canvas sub-forum).

For now, I'd suggest to leave the hard-coded Map dialog alone, as phasing it out now would reflect badly upon both, Nasal & Canvas.
The other issue that is a fairly recent discovery is that PUI dialogs seem to have fairly serious performance implications in and of themselves - thus, it would make sense to use native Canvas Window, like we discussed a while ago:

Subject: Phasing out MapWidget post 3.2
Hooray wrote:Image
ok, I have removed the non-working stuff and committed a very basic version to the canvas-hackers team clone - this still needs the checkboxes to be hooked up to each layer's show/hide method, and clipping/masking needs to be implemented like you say - but I guess correct layouting should handle that (gotta look at ScrollArea.nas).

Also, I have copied several methods from ScrollArea.nas that should probably be just implemented as interfaces - i.e. stuff for resize() handling.
If you are going to touch this, just let me know what you'd like to play with - so that I won't touch the same stuff :D

https://gitorious.org/fg/canvas-hackers ... for-canvas
https://gitorious.org/fg/canvas-hackers ... 2b0370f385

Like I said, I'd probably extend each lcontroller file with a GUI hash that contains label & tooltip for each checkbox, so that we can procedurally create a proper checkbox for each layer.


Obviously, this still needs a little TLC - but the restrictions mentioned on the devel list are fairly minor actually - I guess we could finish this within 3-4 weekends if we should happen to agree on what's "important" to get right...


Note that I haven't tracked FG/SG development recently, so I might be unaware of recent commits and some of my comments might thus be obsolete - I'd just to tread carefully here - because there's other stuff that we'd like to unify eventually (think airport-selection dialog), but there's still missing C++/Nasal tweaks in quite a few places - and it seems the main people involved in these efforts are currently short on time unfortunately.

In general, I'd suggest to either use the forum, the issue tracker or the wiki to keep everybody "in the loop" - especially given that this may take another 1-2 release cycles until this gets sufficiently addressed. In addition, there are also other fgdata/core committers making commits complicating/conflicting with said efforts unfortunately...


@onox:Regarding your comments: 1-6 should be mostly solvable in scripting space unless I missed something ?
Concerning new-navradio, that as well, should be possible to support.
For better performance, there are some additional C++ hooks/tweaks needed - there's at least a handful of possible/straightforward optimizations that we aren't yet using - some of which we've discussed already.

In general, I'd suggest to use the issue tracker and/or add your feature requests to the wiki - ideally, marking any items that you'd be interested in exploring.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Philosopher » Mon Dec 15, 2014 3:04 am

I'm currently really busy with RL and another project, but I would be willing to make time as soon as I can to help out and check bugs. Just not right now :( It definitely needs some optimization and I'll have to help finish it.

Re magnetic headings: IIRC it's not implemented, because I just copied the button over. But it shouldn't affect the VORs, correct? They should stay at the same heading?

Re VOR rotation: I don't remember anymore if I fixed the bug that they didn't rotate at all... If I did I must've used the wrong property, but I remember a point where the headings would just swing around.... maybe I asked Tom if he would add a special heading property to elements too.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Phasing out MapWidget post 3.2

Postby Hooray » Mon Dec 15, 2014 3:14 am

most of these changes should be straightforward to make, and even optimizations should be relatively simple to implement - but as was mentioned on the devel list already, it seems fairly late for the upcoming release, so we will probably have to revisit this for the following release, and try to create a list of "todos" and prioritize items accordingly.
Personally, I am also still hoping to port Stuart's airport selection dialog to use the MapStructure framework, at which point MapStructure should be fairly complete, and all the original MVC stubs (*.draw et al) could be safely removed.
But for the time being it seems that the main people familiar with Nasal/Canvas and MapStructure/ND are busy with other things, and nobody else seems to be around to implement the existing roadmap, which already contains a fair number of pointers. Admittedly, MapStructure itself is a bit more sophisticated than our average Nasal code, but at least it's generally well-encapsulated, i.e. self-contained, so there really isn't much else that needs to be understood to make working changes. And the fancy Nasal stuff involving compile/call/bind/closure/caller should usually only be relevant for structural changes, which should not be required anytime soon. So someone familiar with Nasal + Canvas, and OOP should be able to work through our docs and get started making tiny modifications pretty quickly.

As long as those changes are getting discussed upfront here, I can also help getting things in shape.

Regarding onox's list: most of these are not "bugs" per se, but were simply never intended/implemented - equally, quite a few stylistic issues are easy to change by editing the lcontroller/draw files and the df_style hash there, or overriding these things via the ctor call.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Phasing out MapWidget post 3.2

Postby Hooray » Thu Feb 26, 2015 6:58 pm

Also see:
Subject: My hunting for some bugs on ATI
Hooray wrote:
Bug Bunny wrote in Wed Feb 25, 2015 5:18 pm:New Canvas map is not working properly (I guess), You cannot move inside it, and there is lacking text data that is in simple map). I've tried to zoom in but no text info like in simple map. Screenshot:
Image


  • mouse panning isn't implemented
  • equally, certain labels are not implemented

For a summary, see: http://wiki.flightgear.org/Canvas_MapSt ... map_dialog
Feel free to make feature requests (via the tracker or the wiki) or simply get involved directly (it's just Nasal coding after all)

People already familiar with a simple programming language like JavaScript can easily add both features in 45-90 minutes, by using at existing examples and docs.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: ronh and 1 guest