Re: [Flightgear-devel] Switching from PUI to osgWidget

[James T. <zak...@ma...>]

On 24 Jul 2012, at 13:22, stefan riemens wrote:

> Thanks for the feedback, and especially thanks to James for the offer!
> I think your request for POC code is very reasonable, so let me get
> back to you on that when I have some (although a combobox is already
> almost there, as it is basically just a menu with a changing header).
> Obviously, it will take a lot of time to implement all the needed
> widgets, but I don't think it will be necessary to create a complete
> osgWidget fork. From what I've seen it's pretty flexible (just lacking
> a lot of widgets ;). My hope is to be able to upstream most of the
> yet-to-be-made widgets.

Okay - my personal feeling was it's flexible but some of the design choices make a few things harder than they need to be. Again, I've made slow progress on porting PUI, so if you have proof-of-concept stuff for some widgets already, you can convince me quite easily :)

Oh, I remembered the other 'difficult' widget - the scrolling lists and (related) multi-line text. My feeling was that osgText was going to handle multi-line text fairly badly, and this might be an issue. We don't have many multi-line text widgets, but they're some useful ones - e.g. the Nasal console.

> 
> My hope is to keep at least the current gui xml format, which I think
> should be doable. Failing that, let's at least have the changes
> scriptable ;)

Keeping the current XML format is really a requirement - improving that format, especially handling of layouts, is another task, but there's too many existing dialogs to really break compatibility.

> I must admit I forgot to look at the nasal API, am going to take a
> closer look at that shortly.

I don't think there's a major issue here - so long as you keep XML compatibility most of the current Nasal interaction with the GUI will work. There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.

> Regarding canvas, I think that that is definitively the way to go for
> stuff like the map widget, but to be honest I have my doubts whether
> it would be suitable for the entire gui. I must admit though, so far
> I've only read the documentation on the wiki, so I haven't played
> around with it yet.

Right, canvas makes more sense for the map-widget and replacing the old OpenGL calls in the HUD is my feeling; to build something compatible with the current GUI using the canvas might be possible, but is a lot of work.

> 
> Regarding librocket, that would mean adding another dependency to
> FlightGear. I thought the consensus was that that is not something to
> be taken lightly. And then again, it would require updating all of the
> gui definitions.

Agreed on all counts - of course it should be possible to support the current XML syntax using any toolkit, it just's a question of how hard it is.

James