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 ------------------------------------------------------------------------------ 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
