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.


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Flightgear-devel mailing list

Reply via email to