Canvas GUI: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Update forum links)
Line 22: Line 22:
== Status 07/2013 ==
== Status 07/2013 ==
Before creating new widgets please have a look at Tom's fgdata branch: http://gitorious.org/~tomprogs/fg/toms-fgdata/commits/canvas-gui-demo
Before creating new widgets please have a look at Tom's fgdata branch: http://gitorious.org/~tomprogs/fg/toms-fgdata/commits/canvas-gui-demo
Tom is currently working on creating a standard widget and layout system (similar to eg. Qt). At the moment there only exists a button widget (but already with focus, and hover/press effects) [http://flightgear.org/forums/viewtopic.php?f=24&p=186563#p186563].
Tom is currently working on creating a standard widget and layout system (similar to eg. Qt). At the moment there only exists a button widget (but already with focus, and hover/press effects) [http://forum.flightgear.org/viewtopic.php?f=24&p=186563#p186563].
Specifically, see [https://gitorious.org/~tomprogs/fg/toms-fgdata/trees/canvas-gui-demo/Nasal/canvas/gui $FG_ROOT/Nasal/canvas/gui].
Specifically, see [https://gitorious.org/~tomprogs/fg/toms-fgdata/trees/canvas-gui-demo/Nasal/canvas/gui $FG_ROOT/Nasal/canvas/gui].



Revision as of 19:03, 25 October 2013


Background

In order to eventually phase out PUI completely, we need to stop adding PUI dependencies to the source tree. We now have the Canvas system, and there’s a formal decision to modernize the GUI using the Canvas, and completely replace PUI sooner rather than later.

The shortcomings of our GUI, and PUI in particular, have been repeatedly brought up on the devel list over the years.

It was a lot of work to get rid of hard-coded PUI dialogs, and we still have a bunch of hard-coded PUI widgets – as long as we have those, getting totally rid of PUI will be increasingly difficult, because each hard-coded widget will either need to be phased out or manually ported.

Which is exactly the reason why adding additional PUI widgets to the source tree is a really bad idea and counter-constructive to accomplish our long-term goal of phasing out PUI completely.

We should really work out a plan to get rid of hard-coded PUI widgets and re-implement them using canvas-driven widgets, and extend the canvas as we go. Once that is accomplished, completely replacing PUI will become much more straightforward, because it will basically boil down to writing a parser in Nasal to turn our existing dialogs into canvas widgets.

Adding more and more hard-coded PUI widgets to the mix will make our work increasingly difficult, especially if they implement important and useful features that we really want.

We really need to keep the total picture in mind, or we are growing our todo lists with stuff that wasn’t really necessary in the first place.

This discussion is solely focussed on providing a sane migration path, with the ultimate goal of getting totally rid of PUI.

Given that we have agreed to depreciate PUI, there's simply no reasonable reason to keep on adding PUI widgets/dependencies to the source tree - we need to stop doing that right now. Instead, we need to identify required Nasal/Canvas enhancements, in order to allow these widgets to be implemented outside C++ space.

Status 07/2013

Before creating new widgets please have a look at Tom's fgdata branch: http://gitorious.org/~tomprogs/fg/toms-fgdata/commits/canvas-gui-demo Tom is currently working on creating a standard widget and layout system (similar to eg. Qt). At the moment there only exists a button widget (but already with focus, and hover/press effects) [1]. Specifically, see $FG_ROOT/Nasal/canvas/gui.

Before we can replace PUI with a Canvas based GUI a lot work has to be done. Tom is currently working on extending the current canvas windows manager to also become a simple decorator engine which will allow creating unified window decorations and handling like dragging/resizing/closing windows. When this is done we can think of creating simple dialogs. And then we can start creating different widgets and see how to implement a layouting engine. And only then we can start thinking about replacing PUI dialogs with Canvas dialogs. (We may also need a fallback for older hardware as render-to-texture probably won't be supported).

So in the current state it would bring us much benefit to create a separate canvas dialog showing log messages without being able to show it in normal PUI dialogs. Later if we have got a list widgets it will be very easy to just print the log messages to this list widget.

PUI Widgets

Canvas dialogs are definitely the way to go, as they are far more flexible and will replace PUI in the future. Since I think FG 2.11 you can create canvas dialogs with window decoration, including a title bar allowing to drag the window around and a close icon:

var dlg = canvas.Window.new([400,300], "dialog")
                                    .set("title", "My Canvas Dialog...");

The existing XML dialogs can still be used and will also be usable in the future (by a backwards compatibility layer or some migration path).

Implementing all our existing PUI/XML-based dialogs is almost certainly going to be more work than providing a Nasal-space migration path/wrapper that reads the old dialogs and turns them into "modern" canvas windows, possibly by just overwriting the dialog-show fgcommand via the new removecommand/addcommand APIs. And phasing out canvas widget should be fairly straightforward too, because those can be directly mapped to embedded/nested canvas textures, so I wouldn't worry too much ...

All standard widgets (textbox, label, radio button, checkbox etc) can be provided by a Nasal parser that turns the existing GUI XML into canvas widgets - our hard-coded widgets however, need to be separately re-implemented. Here's a list of custom, hardcoded, PUI widgets which we will need to re-implement using the Canvas, based on $FG_SRC/GUI:


In order to re-implement these using the Canvas system, we need to identify Nasal APIs that are currently missing, and which need to be provided via the cppbind framework.

This way, C++ developers can concentrate on providing the missing Nasal/C++ hooks, whereas Nasal developers can provide the required widgets.

Replacing native PUI widgets with Canvas widgets

  • provide a PropertyList-XML file that specifies the canvas to be put into $FG_ROOT/gui/widgets
  • provide a Nasal implementation to be put into $FG_ROOT/Nasal/canvas/widgets
  • modify all existing uses of the hardcoded widget

For example, to replace the loglist widget (prototype available at: https://gitorious.org/~hooray/fg/hoorays-fgdata/commits/topics/canvas-loglist ) :

canvas loglist prototype

Provide an PropertyList-XML that declares the canvas and its default settings, including a Nasal section that implements the logic, saved as gui/widgets/loglist.xml:

<?xml version="1.0"?>
<PropertyList>
               <name></name>
	       <logclass></logclass>
               <valign>fill</valign>
               <halign>fill</halign>
               <stretch>true</stretch>
               <pref-width>400</pref-width>
               <pref-height>200</pref-height>
                <nasal><load><![CDATA[
                print("canvas loglist running!");
                ]]></load></nasal>
</PropertyList>

Instead of embedding all code inline, you can also include an external Nasal by using:

io.load_nasal( getprop("/sim/fg-root") ~ "/Nasal/canvas/widgets/loglist.nas" );

To implement the widget-specific logic, you can access the parent canvas using the cmdarg() API:

var my_canvas = canvas.get( cmdarg() ); # this will get a handle to the parent canvas 

var root = my_canvas.createGroup();
var text = root.createChild("text")
.setText("some custom canvas widget")
.setTranslation(10, 30)
.setAlignment("left-top")
.setFontSize(20)
.setFont("LiberationFonts/LiberationSans-Regular.ttf")
.set("max-width", 380)
.setColor(1,0,0);

For handling mouse/GUI events, see: Canvas - Event Handling.

Next, replace the original <loglist> in all dialogs in $FG_ROOT/gui/dialogs

<loglist>
                <halign>fill</halign>
                <valign>fill</valign>
                <stretch>true</stretch>
                <pref-width>450</pref-width>
                <pref-height>200</pref-height>
                <padding>6</padding>
</loglist>

And include the corresponding canvas file instead:

<canvas include="gui/widgets/loglist.xml"> <!-- see $FG_ROOT/Docs/README.gui for details -->
	        <logclass>nasal</logclass>
                <halign>fill</halign>
                <valign>fill</valign>
                <stretch>true</stretch>
                <pref-width>450</pref-width>
                <pref-height>200</pref-height>
                <padding>6</padding>
</canvas>