Using a PUI CanvasWidget as a Canvas.Window ?

[Hooray]

I looked at the Window.new() ctor and cannot seem to find anything that would allow me to easily turn an existing Canvas into a "Window" ?
The rationale being that we're in the process of turning our map-canvas.xml dialog into a generic, and reusable, widget for $FG_ROOT/Nasal/canvas/gui/widgets - the widget is using the new Layout engine to align other widgets (checkboxes & buttons for now). And one of our goals is to also modernize airports.xml (the airport selection dialog) such that it can use MapStructure. The simplest way would be to simply turn the PUI CanvasWidget into a Canvas.Window() so that layouting etc works as expected, and so that we can simply show the new scripted MapWidget there.

I know that PUI is going to be phased out sooner or later - but that will undoubtedly still take a while, and porting the whole dialog will be more work than just embedding an existing widget

Any ideas/suggestions ?

[TheTom]

Window.setCanvas?

[Hooray]

ok, that was embarrassing - I looked in the completely wrong place, and I think we're even using this in several places (e.g. the ND). Thanks though!

[Hooray]

Looking at it, I still think that I need to either customize canvas.Window.new() or provide an alternate ctor for existing canvases, because I end up with another/second window once I just use .setCanvas(), whereas I really only want the CanvasWidget to be treated as a window for layout handling. What is that I am missing this time ?

[TheTom]

What does your code look like?

[Hooray]

if I don't touch/modify gui.nas, I am just doing the equivalent of canvas.Window.new() and then .setCanvas( canvas.get(cmdarg() ) which works (as can be seen above), but works in the sense of having another "windowed" placement next to the actual PUI/CanvasWidget (which kinda makes sense given that I allocate a new window!). Which is why I have edited gui.nas::Window.new() now - but I guess I am simply missing something (again).

[TheTom]

But that's exactly the way it should work? You create a canvas and display it inside a PUI dialog and additionally show it inside a Canvas window. If you don't want a PUI window, don't open one. Showing a Canvas inside a window does not affect any other placement.

[Hooray]

Right, but the point was that we want to JUST show an existing Window-oriented "Canvas Widget" in a PUI/CanvasWidget so that it can be treated as a Canvas.Window, and use layouting/widgets etc - without requiring a separate "real" Canvas.Window. Like I said earler, the thing works (see above), but we WANT the PUI widget, MINUS the native Canvas.Window. The use-case should be valid actually, because that's conceivably how we could implement individual widgets (e.g. PUI button=>Canvas button/checkbox) and still use them in PUI dialogs while phasing out PUI. So that's why I am asking. The whole point is treat a CanvasWidget area like a Window so that we can use widgets/layouting, without requiring a separate Canvas.Window being shown.

[TheTom]

Ah, thats the other way round^^ If you don't want a window, don't create one Layouts don't require windows, you can apply a layout to any canvas. Window.setLayout just forwards it to Canvas.setLayout (although I forgot to expose this to Nasal -> me going to push^^)

edit: Just keep in mind that there will be no support for mouseover/hover events.

[Hooray]

but I can explicitly enable mouse events, right ? Otherwise, the whole exercise would be kinda pointless, because all our nice new toys (widgets) wouldn't work then ...

[TheTom]

Mouse clicks/wheel/drag work, but there is no support for mouse move in PUI.

[Hooray]

thanks again for your help, and sorry for the misconception (at least it wasn't a dumb mistake on my part... ) - it now works exactly like I intended, including checkbox widgets responding to clicks (which should suffice for now, not sure how difficult it would be to pass mouse-move events from PUI onto Canvas, I guess we would have to sub-class some lower-level class or provide our own-probably not worth the hassle)

[Hooray]

regarding mouse/event handling, I assume that the above use-case was kinda unforeseen probably and that some Widget-specific stuff need to be better encapsulated to get rid of the assumption that all mouse events are always available/supported ? Specifically, I am seeing an error like the following that only occurs when in PUI/CanvasWidget "mode":

Code: Select all

Nasal runtime error: No such member: _focused_widget
  at /home/hooray/sources/fgroot/Nasal/canvas/gui/Widget.nas, line 85
  called from: /home/hooray/sources/fgroot/Nasal/canvas/gui/Widget.nas, line 152


Would you agree that we'll want to continue supporting this as a use-case, e.g. to incrementally port PUI widgets to Canvas step by step ? I think things like a label, button, checkbox should be straightforward to port already, and it would allow us to easily phase out PUI by simply using a CanvasWidget that uses the new Canvas widgets. What do you think?

[TheTom]

regarding mouse/event handling, I assume that the above use-case was kinda unforeseen probably and that some Widget-specific stuff need to be better encapsulated to get rid of the assumption that all mouse events are always available/supported ? Specifically, I am seeing an error like the following that only occurs when in PUI/CanvasWidget "mode":

There is nothing unforeseen involved, just a missing check if a member exists Should be fixed now.

Would you agree that we'll want to continue supporting this as a use-case, e.g. to incrementally port PUI widgets to Canvas step by step ?

There is no problem in supporting this use-case, although I don't like the idea of mixing PUI and Canvas with widgets for anything else than some experiments. We already have enough inconsistency with mixing PUI dialogs and Canvas windows. Just imagine the mess if we would additionally mix the two styles of widgets within single dialogs. Either a dialog is rewritten to only use Canvas or it has to wait until PUI XML files are parsed into Canvas dialogs.

[Hooray]

ok, that makes sense - I was really just thinking in terms of things like the canvas widget in the airport selection dialog, where porting the whole dialog would be more work than necessary, and we should get there once we re-implement the dialog parser, after we have canvas equivalents of the main PUI widgets, and some wrapper that converts the existing layouting markup to the new canvas layout engine.

For now, adding Canvas checkboxes to the canvas widget is obviously easier than separately handling PUI checkboxes...