Board index FlightGear Development Canvas

canvas vs. on-screen messages - 1:0

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.

canvas vs. on-screen messages - 1:0

Postby Thorsten » Fri Jul 01, 2016 2:07 pm

Some odd interference I've been observing:

I've added the option to replicate two MDU displays into full canvas windows, so you can monitor flight performance while in outside or FG HUD view.

The code to do that seems simple enough:

Code: Select all
var create_MDU_clone = func (index) {

if (index == 0) {string = "CDR1";}
else if (index == 1) {string = "CDR2";}

var window = canvas.Window.new([512,512],"dialog").set("title", string);

var canvas_clone = SpaceShuttle.MDU_array[index].PFD._canvas;
window.setCanvas(canvas_clone);

}


Works like a charm. However, when I have such windows active, the on-screen messaging system breaks and reports an error from screen.nas about 'trim' not being a valid member. So... it seems something here interferes badly.

To replicate:

* start SpaceShuttle-orbit
* use SpaceShuttle -> clone CDR-1 MDU to get the canvas window open
* press 'd' to disconnect the ET (that triggers a message) - watch the message not appear and the console error
Thorsten
 
Posts: 10939
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas vs. on-screen messages - 1:0

Postby Hooray » Fri Jul 01, 2016 2:11 pm

popups are canvas based - and Canvas interacts with PUI, in the sense that it is taking precedence, most legacy tooltips are using invisible/transparent PUI dialogs, so that is certainly where the conflict comes from.

The summary is that Tom and James are well aware of this, but James discouraged any attempts to fix this, because he wanted to get rid of PUI in favor of the Canvas UI - since then (mid 2012), he focused on Qt5 instead - so that the Canvas/PUI interoperability has not been getting much attention

There is a statement in the archives where Tom basically said that he wasn't prioritizing doing this, because James agreed to yank PUI entirely - over the last couple of years, some of the priorities have obviously changed.

The details are covered in the canvas event hanlding docs: http://wiki.flightgear.org/Canvas_Event_Handling


It would make sense to use the Canvas tooltip framework and adapt the screen.nas code accordingly: http://wiki.flightgear.org/Tooltips

EDIT: I may have misunderstood: Are you referring to PUI dialogs or just Canvas code ? If it's the latter, I'd check the namespace, or dump/re-assign the me reference to see if that's what's going on
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas vs. on-screen messages - 1:0

Postby Thorsten » Fri Jul 01, 2016 2:23 pm

I'm referring to statements like

Code: Select all
setprop("/sim/messages/copilot", "Main engine ignition!");


which break - no idea what this internal workings are. They work find as long as canvas is rendered on the in-cockpit screens, just rendering into separate canvas windows breaks them.
Thorsten
 
Posts: 10939
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas vs. on-screen messages - 1:0

Postby Hooray » Fri Jul 01, 2016 4:44 pm

yes, that's what I was referring to: basically, Canvas event handlign conflicts with PUI event handling in the sense that it takes precedence - there never really was the intention to fix that, because all the people involved in the original discussion ended up agreeing that PUI should be retired ASAP, i.e. it would not be worth the hassle to make PUI<->Canvas event handling work more properly.

For the corresponding background info refer to the links I posted - but it's really not a new thing, and is indeed explicitly mentioned in the Canvas docs - however, most people will be unaware of the back-end (like you say), i.e. the corresponding messages basically being transparent PUI dialogs (IIRC), so that the corresponding limitations apply, without people necessarily being aware of the culprit.

I cannot find the docs at the moment, but I once added a little text to the wiki explaining how this whole thing works by going through the PUI dialog-new and dialog-show fgcommand API.
EDIT: Here's the article: http://wiki.flightgear.org/GUI_Messages

For the record, this will/would also be automatically handled (fixed) by adopting the pui2canvas approach, because it works transparently behind the scenes in the form of overriding these exact fgcommands and dispatching all such calls to the parser, which would then render such dialogs as native Canvas windows - at which point there would no longer be any conflicts between live PUI widgets and Canvas windows/widgets.

In other words, even procedurally generated PUI dialogs can be handled by the pui2canvas approach - e.g. see AndersG's wildfire dialog (wildfire.nas) below:
Image
Internally, it is using the exact same fgcommands that the screen.nas logic is going through.

The short term solution would be fixing up screen.nas to use native Canvas dialogs instead of PUI (as per tooltip.nas)
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas vs. on-screen messages - 1:0

Postby Thorsten » Fri Jul 01, 2016 6:39 pm

Thanks for the context... my priority for fixing this is low as the use case is a tad exotic, and if pui2canvas does it anyway, I guess there's no real point in trying.
Thorsten
 
Posts: 10939
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas vs. on-screen messages - 1:0

Postby Hooray » Fri Jul 01, 2016 6:58 pm

yeah, pui2canvas will/would do it once/if it is adopted, i.e. by re-implemting a handful of fgcommands that are then dispatched to use native Canvas APIs instead of the legacy PUI stuff - however, for that to happen, the pui2canvas effort still needs some TLC.
Regarding this particular use-case, the really good thing is that everything needed is already there, because a tooltip (or on-screen message) really is nothing more than a text/label widget rendered to a transparent window/dialog without any window decoration (as in close button, title bar) - thus, there really isn't much/anything missing in terms of functionality, apart from providing pui2canvas as an actual option at startup/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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas vs. on-screen messages - 1:0

Postby Thorsten » Sat Jul 02, 2016 5:08 am

I think the status is that since there has not been a fundamental objection against this on the mailing list and several people have said they can live with the option as long as it remains an option, I will commit pui2canvas to FGData in the form of a Nasal module that gets loaded 'on demand' dependent on a set property (similar to AW).

We'll then see whether people find it more widely useful etc. and whether FG more generally relies on it for fixing such bugs/issues or not.
Thorsten
 
Posts: 10939
Joined: Mon Nov 02, 2009 8:33 am

Re: canvas vs. on-screen messages - 1:0

Postby Hooray » Sat Jul 02, 2016 1:07 pm

That sounds like a reasonable plan, I think we can work out making this entirely optional in the form of a Nasal submodule that is loaded/unloaded on demand, with the default setting being "disabled" (via preferences.xml).
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: 11329
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests