From: stefan r. <fgf...@gm...> - 2012-07-21 20:46:41
|
Hi all! Let me quickly introduce myself, I'm a dutch software engineering student who has been lurking on this list for an embarrassingly long time (think pre FG 1.0...). Anyway, I'd like to get actively involved in FlightGear core development. It's obviously a long time wish to get rid of the PLIB dependency, and one of the main subsystems using it is the GUI. There are a couple of things lacking in possibilities with the current implementation: - Proper internationalisation. PUI doesn't support UTF-8, limiting i18n support tremendously. - Things like submenus - The code is pretty messy, by the looks of it mostly due to the oldness of PUI and its API So, a couple of possible alternatives: 1) Suck PUI into simgear and improve it in there. I believe James Turner suggested this a couple of months ago. 2) Switch to some other third party gui system (QT, or ceGui or something like that) 3) Integrate a browser (getting pretty popular at other projects) 4) Switch to osgWidget A couple of pros and cons with each of these (Warning: I'm obviously biased: see the title of this post :): 1) + This is obviously the least work short term (no need to port the current code) - It means taking over PUI maintenance altogether. (not that it is very well maintained now, but hey :) - Will require some serious code surgery to get it to support UTF-8 and to generally clean it up 2) + Probably a rather complete widget library - Means taking on yet another dependency (in most cases a rather hefty one) - Porting the existing code is a non-trivial undertaking 3) + Getting pretty popular, primarily because of the ease of ui creation and javascript integration - Doesn't fit well with FG's nasal, and the xml formats that are already there - Means taking on another hefty dependency (and the question rises: which browser? I don't know any major Linux distro shipping berkelium, for example) 4) +No extra dependency, since it is OSG native + Likely to get a lot of widget code into osg proper, and thus get rid of (a large part of) the maintenance burden. + UTF-8 support already there - Porting existing code is a non-trivial undertaking (especially since it's widget set is rather limited) Obviously, I think the best choice of these is to switch to osgWidget, and I'm willing to take that task upon me. I've made a clone on Gitorious, with a osgWidget MenuBar implementation. Its currently pretty quick and dirty, and looks absolutely horrible, but it (mostly) works. https://gitorious.org/~stefanriemens/fg/stefanriemens-flightgear Before pushing further with it, I'd like to hear other devs opinions on how to go forwards... Stefan |
From: James T. <zak...@ma...> - 2012-07-22 15:49:34
|
On 21 Jul 2012, at 21:46, stefan riemens wrote: > Obviously, I think the best choice of these is to switch to osgWidget, > and I'm willing to take that task upon me. > I've made a clone on Gitorious, with a osgWidget MenuBar > implementation. Its currently pretty quick and dirty, and looks > absolutely horrible, but it (mostly) works. > https://gitorious.org/~stefanriemens/fg/stefanriemens-flightgear > > Before pushing further with it, I'd like to hear other devs opinions > on how to go forwards... I've got about 25% of option 1) done in a private branch. I believe 4) (using osgWidget) is not great because osgWidget is essentially unfinished, unmaintained and has no examples of the kind of widgets we actually need - sliders, combo boxes, dials and so on. The great advantage of porting PLIB is that the we already use its API, and it already implements all the widgets we need :) I did start using osgWidget, and realised to create scrollbars, combo-boxes and sliders that work, and then port all the dialog / menu code to use the new API, was a huge amount of work, and would require updating all the dialog XML definitions. I am hopeful (though not sure) that I can make approach 1) and keep all the existing generic and aircraft-specific dialog XML files looking 'okay' and working as intended. My assumption is to make osgWidget do what we need, you will *have* to fork it (although you may be able to upstream the changes if they are generic enough) and will spend a lot of time creating all the widgets we need. If you disagree, I am more than happy to help and collaborate, but I'd like to see proof-of-concept code, say, a combo-box and scrollbar before agreeing you can do it :) James |
From: Thomas G. <to...@gm...> - 2012-07-22 20:40:55
|
Hi Stefan, Am 2012-07-21 22:46, schrieb stefan riemens: > It's obviously a long time wish to get rid of the PLIB dependency, and > one of the main subsystems using it is the GUI. There are a couple of > things lacking in possibilities with the current implementation: > - Proper internationalisation. PUI doesn't support UTF-8, limiting > i18n support tremendously. > - Things like submenus > - The code is pretty messy, by the looks of it mostly due to the > oldness of PUI and its API Have you seen my ongoing efforts towards a unified 2D drawing system called Canvas (http://wiki.flightgear.org/Canvas). It basically allows drawing 2D shapes (with OpenVG) and text (using osgText::Text). As it uses osgText for textrendering, supporting UTF-8 is very easy. I just tried it and with changing a single line of code now also using UTF-8 is supported. Currently only drawing inside an existing (PUI) dialog is possible, but the idea is to slowly implement the current functionally in Nasal and get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard interaction with Nasal will be needed. In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) this approach would give much more flexibility and also the means of modifying and creating new widgets without the need to touch any core code. With the Canvas system every type of widget would be possible, so that also things like submenus can be realized. Another advantage of the Canvas approach is that it is heavily using the property tree and therefore is already fully accessible from Nasal code and also configurable with the existing xml formats. Switching to another scripting language or adding support for a new one, I think would be far too much work and not worth the efforts. Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org ------------------------------------------------------------------------ Student of Computer Science @ Graz University of Technology ------------------------------- Austria -------------------------------- |
From: HB-GRAL <fli...@sa...> - 2012-07-22 22:42:37
|
Am 22.07.12 22:40, schrieb Thomas Geymayer: > Hi Stefan, > > Am 2012-07-21 22:46, schrieb stefan riemens: >> It's obviously a long time wish to get rid of the PLIB dependency, and >> one of the main subsystems using it is the GUI. There are a couple of >> things lacking in possibilities with the current implementation: >> - Proper internationalisation. PUI doesn't support UTF-8, limiting >> i18n support tremendously. >> - Things like submenus >> - The code is pretty messy, by the looks of it mostly due to the >> oldness of PUI and its API > > Have you seen my ongoing efforts towards a unified 2D drawing system > called Canvas (http://wiki.flightgear.org/Canvas). It basically allows > drawing 2D shapes (with OpenVG) and text (using osgText::Text). > > As it uses osgText for textrendering, supporting UTF-8 is very easy. I > just tried it and with changing a single line of code now also using > UTF-8 is supported. > > Currently only drawing inside an existing (PUI) dialog is possible, but > the idea is to slowly implement the current functionally in Nasal and > get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard > interaction with Nasal will be needed. > > In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) > this approach would give much more flexibility and also the means of > modifying and creating new widgets without the need to touch any core code. > > With the Canvas system every type of widget would be possible, so that > also things like submenus can be realized. > > Another advantage of the Canvas approach is that it is heavily using the > property tree and therefore is already fully accessible from Nasal code > and also configurable with the existing xml formats. > > Switching to another scripting language or adding support for a new one, > I think would be far too much work and not worth the efforts. > > Regards, > Tom > I don’t know what is it worth to think about a GUI inside fgfs at all sometimes. When I look to what can be done i.e. with the FGx launcher, properties and now HLA/RTI I’m thinking about trying to skip the built-in GUI at all ;-) Cheers, Yves |
From: Jacob B. <jmb...@gm...> - 2012-07-23 15:14:09
|
On Sun, Jul 22, 2012 at 6:42 PM, HB-GRAL <fli...@sa...> wrote: > Am 22.07.12 22:40, schrieb Thomas Geymayer: >> Hi Stefan, >> >> Am 2012-07-21 22:46, schrieb stefan riemens: >>> It's obviously a long time wish to get rid of the PLIB dependency, and >>> one of the main subsystems using it is the GUI. There are a couple of >>> things lacking in possibilities with the current implementation: >>> - Proper internationalisation. PUI doesn't support UTF-8, limiting >>> i18n support tremendously. >>> - Things like submenus >>> - The code is pretty messy, by the looks of it mostly due to the >>> oldness of PUI and its API >> >> Have you seen my ongoing efforts towards a unified 2D drawing system >> called Canvas (http://wiki.flightgear.org/Canvas). It basically allows >> drawing 2D shapes (with OpenVG) and text (using osgText::Text). >> >> As it uses osgText for textrendering, supporting UTF-8 is very easy. I >> just tried it and with changing a single line of code now also using >> UTF-8 is supported. >> >> Currently only drawing inside an existing (PUI) dialog is possible, but >> the idea is to slowly implement the current functionally in Nasal and >> get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard >> interaction with Nasal will be needed. >> >> In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) >> this approach would give much more flexibility and also the means of >> modifying and creating new widgets without the need to touch any core code. >> >> With the Canvas system every type of widget would be possible, so that >> also things like submenus can be realized. >> >> Another advantage of the Canvas approach is that it is heavily using the >> property tree and therefore is already fully accessible from Nasal code >> and also configurable with the existing xml formats. >> >> Switching to another scripting language or adding support for a new one, >> I think would be far too much work and not worth the efforts. >> >> Regards, >> Tom >> > > I don’t know what is it worth to think about a GUI inside fgfs at all > sometimes. When I look to what can be done i.e. with the FGx launcher, > properties and now HLA/RTI I’m thinking about trying to skip the > built-in GUI at all ;-) > > Cheers, Yves > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel Might be worth having a look at http://librocket.com, looks to be a very powerful and well done gui system. Uses html/css based files for creating, laying out, and styling the gui...has some support for interfacing script engines (ie nasal), localization, etc. This is the route I'd probably go personally if I were to do this...or any game/sim/3d project needing a gui... |
From: stefan r. <fgf...@gm...> - 2012-07-24 12:22:52
|
Hi all, 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. 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 ;) I must admit I forgot to look at the nasal API, am going to take a closer look at that shortly. 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. 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. Stefan 2012/7/23 Jacob Burbach <jmb...@gm...>: > On Sun, Jul 22, 2012 at 6:42 PM, HB-GRAL <fli...@sa...> wrote: >> Am 22.07.12 22:40, schrieb Thomas Geymayer: >>> Hi Stefan, >>> >>> Am 2012-07-21 22:46, schrieb stefan riemens: >>>> It's obviously a long time wish to get rid of the PLIB dependency, and >>>> one of the main subsystems using it is the GUI. There are a couple of >>>> things lacking in possibilities with the current implementation: >>>> - Proper internationalisation. PUI doesn't support UTF-8, limiting >>>> i18n support tremendously. >>>> - Things like submenus >>>> - The code is pretty messy, by the looks of it mostly due to the >>>> oldness of PUI and its API >>> >>> Have you seen my ongoing efforts towards a unified 2D drawing system >>> called Canvas (http://wiki.flightgear.org/Canvas). It basically allows >>> drawing 2D shapes (with OpenVG) and text (using osgText::Text). >>> >>> As it uses osgText for textrendering, supporting UTF-8 is very easy. I >>> just tried it and with changing a single line of code now also using >>> UTF-8 is supported. >>> >>> Currently only drawing inside an existing (PUI) dialog is possible, but >>> the idea is to slowly implement the current functionally in Nasal and >>> get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard >>> interaction with Nasal will be needed. >>> >>> In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) >>> this approach would give much more flexibility and also the means of >>> modifying and creating new widgets without the need to touch any core code. >>> >>> With the Canvas system every type of widget would be possible, so that >>> also things like submenus can be realized. >>> >>> Another advantage of the Canvas approach is that it is heavily using the >>> property tree and therefore is already fully accessible from Nasal code >>> and also configurable with the existing xml formats. >>> >>> Switching to another scripting language or adding support for a new one, >>> I think would be far too much work and not worth the efforts. >>> >>> Regards, >>> Tom >>> >> >> I don’t know what is it worth to think about a GUI inside fgfs at all >> sometimes. When I look to what can be done i.e. with the FGx launcher, >> properties and now HLA/RTI I’m thinking about trying to skip the >> built-in GUI at all ;-) >> >> Cheers, Yves >> >> ------------------------------------------------------------------------------ >> 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 >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > Might be worth having a look at http://librocket.com, looks to be a > very powerful and well done gui system. Uses html/css based files for > creating, laying out, and styling the gui...has some support for > interfacing script engines (ie nasal), localization, etc. > > This is the route I'd probably go personally if I were to do this...or > any game/sim/3d project needing a gui... > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2012-07-24 13:44:33
|
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 |
From: Thomas G. <to...@gm...> - 2012-07-24 15:52:27
|
Am 2012-07-24 15:43, schrieb James Turner: > 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. I have just experimented a bit with osgText and multi-line text. So far I didn't notice any problems. >> 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. But using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... I've done a quick proof of concept for a tabbed and scrollable widget (including some UTF-8 chars): http://youtu.be/1a6wtPVPWc4 https://gitorious.org/~tomprogs/fg/toms-fgdata/blobs/canvas/gui/dialogs/canvas-demo.xml Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org ------------------------------------------------------------------------ Student of Computer Science @ Graz University of Technology ------------------------------- Austria -------------------------------- |
From: James T. <zak...@ma...> - 2012-07-24 17:36:03
|
On 24 Jul 2012, at 16:45, Thomas Geymayer wrote: > I have just experimented a bit with osgText and multi-line text. So far > I didn't notice any problems. My concern was about calculating sane vertical heights allowing for line-wrap, but that appears to work, based on your demo below! > But using the Canvas also for the GUI would give us the advantage of a > unified rendering backend for any type of GUI/text rendering and also > the ability to use the same widgets everywhere - eg. use them also > inside aircrafts for CDU GUIs or other displays... > > I've done a quick proof of concept for a tabbed and scrollable widget > (including some UTF-8 chars): That's quite a convincing demo :) Especially since we'd factor the createXYZ functions into a helper, or even C++, depending on how much customisability we're looking for. I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI. Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) Stefan, what's your opinion? Obviously Thomas knows the Canvas code since he created it - I've looked at the source but not used it properly (and probably no-one else has a chance to either, yet), but it has the advantage that it's already checked in, and offers a very lightweight solution potentially. (We could could allow aircraft dialogs to include custom widgets, although that might be unwise for other reasons) James |
From: Thomas G. <to...@gm...> - 2012-07-24 22:11:14
|
Am 2012-07-24 19:35, schrieb James Turner: > Thomas, one issue I can guess at (though PLIB is also really bad at > it, and osgWidget is not much better!) - text selection. Do you think > you'd be able to handle a blinking insertion point and a standard > draggable text selection area in this approach? Obviously it might > need some additional C++ helpers but that's okay since text-editing > is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. > One goal of mine for the GUI is to get platform native copy-and-paste > working, BTW ;) This has already been on my wish/todo list :P > Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org ------------------------------------------------------------------------ Student of Computer Science @ Graz University of Technology ------------------------------- Austria -------------------------------- |
From: stefan r. <fgf...@gm...> - 2012-07-25 10:42:16
|
Hi Thomas, This is very convincing! Congratulations, that looks really neat. Having seen this, I think we'd better go with the canvas approach. It would require quite a lot of code to get osgWidget to produce that... Stefan 2012/7/25 Thomas Geymayer <to...@gm...>: > Am 2012-07-24 19:35, schrieb James Turner: >> Thomas, one issue I can guess at (though PLIB is also really bad at >> it, and osgWidget is not much better!) - text selection. Do you think >> you'd be able to handle a blinking insertion point and a standard >> draggable text selection area in this approach? Obviously it might >> need some additional C++ helpers but that's okay since text-editing >> is a pretty specialised behaviour. > > Yes :) > > http://youtu.be/CIS8UyuJLgM > > I have just added some property change listeners to get the position of > the next character at a given position. The highlighting happens only > from Nasal. What is currently missing is the possibility to also change > the color of the selected text and to actually get the selected text, > but this shouldn't be too hard to implement. > >> One goal of mine for the GUI is to get platform native copy-and-paste >> working, BTW ;) > > This has already been on my wish/todo list :P > >> Obviously Thomas knows the Canvas code since he created it [...] > > Currently documentation is not too detailed, but looking at the > different demos and maybe also the Nasal API and source code should > help. If not, don't hesitate to ask :) > > Regards, > Tom > > -- > Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org > ------------------------------------------------------------------------ > Student of Computer Science @ Graz University of Technology > ------------------------------- Austria -------------------------------- > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: ys <fli...@sa...> - 2012-07-24 23:43:07
|
Hi Thomas, Hi James This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is "inside" the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window "view" and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. Cheers, Yves Am 25.07.2012 um 00:11 schrieb Thomas Geymayer <to...@gm...>: > Am 2012-07-24 19:35, schrieb James Turner: >> Thomas, one issue I can guess at (though PLIB is also really bad at >> it, and osgWidget is not much better!) - text selection. Do you think >> you'd be able to handle a blinking insertion point and a standard >> draggable text selection area in this approach? Obviously it might >> need some additional C++ helpers but that's okay since text-editing >> is a pretty specialised behaviour. > > Yes :) > > http://youtu.be/CIS8UyuJLgM > > I have just added some property change listeners to get the position of > the next character at a given position. The highlighting happens only > from Nasal. What is currently missing is the possibility to also change > the color of the selected text and to actually get the selected text, > but this shouldn't be too hard to implement. > >> One goal of mine for the GUI is to get platform native copy-and-paste >> working, BTW ;) > > This has already been on my wish/todo list :P > >> Obviously Thomas knows the Canvas code since he created it [...] > > Currently documentation is not too detailed, but looking at the > different demos and maybe also the Nasal API and source code should > help. If not, don't hesitate to ask :) > > Regards, > Tom > > -- > Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org > ------------------------------------------------------------------------ > Student of Computer Science @ Graz University of Technology > ------------------------------- Austria -------------------------------- > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: HB-GRAL <fli...@sa...> - 2012-07-25 08:40:09
|
Just to illustrate what I mean actually ... Current situation: http://maptest.fgx.ch/screens/current-screen.png New GUI with separated menus/dialogs, viewer in a separate window: http://maptest.fgx.ch/screens/one-screen.png Or new GUI with two screens setting, where one screen is the view only: http://maptest.fgx.ch/screens/two-screen.png Regards Yves Am 25.07.12 01:42, schrieb ys: > Hi Thomas, Hi James > > This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is "inside" the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window "view" and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. > > Cheers, Yves > > > > > > > > > Am 25.07.2012 um 00:11 schrieb Thomas Geymayer <to...@gm...>: > >> Am 2012-07-24 19:35, schrieb James Turner: >>> Thomas, one issue I can guess at (though PLIB is also really bad at >>> it, and osgWidget is not much better!) - text selection. Do you think >>> you'd be able to handle a blinking insertion point and a standard >>> draggable text selection area in this approach? Obviously it might >>> need some additional C++ helpers but that's okay since text-editing >>> is a pretty specialised behaviour. >> >> Yes :) >> >> http://youtu.be/CIS8UyuJLgM >> >> I have just added some property change listeners to get the position of >> the next character at a given position. The highlighting happens only >> from Nasal. What is currently missing is the possibility to also change >> the color of the selected text and to actually get the selected text, >> but this shouldn't be too hard to implement. >> >>> One goal of mine for the GUI is to get platform native copy-and-paste >>> working, BTW ;) >> >> This has already been on my wish/todo list :P >> >>> Obviously Thomas knows the Canvas code since he created it [...] >> >> Currently documentation is not too detailed, but looking at the >> different demos and maybe also the Nasal API and source code should >> help. If not, don't hesitate to ask :) >> >> Regards, >> Tom >> >> -- >> Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org >> ------------------------------------------------------------------------ >> Student of Computer Science @ Graz University of Technology >> ------------------------------- Austria -------------------------------- >> >> ------------------------------------------------------------------------------ >> 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 >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: James T. <zak...@ma...> - 2012-07-25 09:28:27
|
On 25 Jul 2012, at 00:42, ys wrote: > This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is "inside" the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window "view" and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. This is an orthogonal issue - it can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port. Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases). So, this is a desirable feature, but doesn't dictate the choice of GUI technology. And can be done as a separate step from replacing PLIB. James |
From: James T. <zak...@ma...> - 2012-07-25 09:49:20
|
On 24 Jul 2012, at 23:11, Thomas Geymayer wrote: >> Do you think >> you'd be able to handle a blinking insertion point and a standard >> draggable text selection area in this approach? Obviously it might >> need some additional C++ helpers but that's okay since text-editing >> is a pretty specialised behaviour. > > Yes :) > > http://youtu.be/CIS8UyuJLgM > > I have just added some property change listeners to get the position of > the next character at a given position. The highlighting happens only > from Nasal. What is currently missing is the possibility to also change > the color of the selected text and to actually get the selected text, > but this shouldn't be too hard to implement. Videos convince me very easily! I think we need a bit of discussion about the architecture for this approach, especially to define a widget abstraction (maybe C++, maybe nasal) so dialog authors can't break widget functionality unintentionally, but aside from that I can't see many potential problems; Nasal can already process the GUI files since they're property lists. (I'm imagining a C++ factory function that takes a property node and builds a widget - this would be exposed via a Nasal API - and even if it called back to a Nasal definition for each widget type, would still allow us to build custom widgets using the C++ canvas API if required) The map-widget, route-manager waypoint list and airport-list widgets would need some porting, but that's all pretty valuable anyway - especially for the map-widget. As you say once it's done it would be re-usable for in-cockpit displays which is all good. Since I created the Map-widget I've added a whole bunch of Nasal APIs to query the navDB so that part of the map-widget is doable without C++ now too. Oh, and we need the option to keep the native menu-bar on Mac of course ;) James |
From: Martin S. <Mar...@mg...> - 2012-07-25 10:17:13
|
HB-GRAL wrote: > New GUI with separated menus/dialogs, viewer in a separate window: > http://maptest.fgx.ch/screens/one-screen.png Someone please buy me a display *that* wide so I can still afford using space lateral to the viewer for the menu ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: ys <fli...@sa...> - 2012-07-25 10:36:35
|
Hey Martin, you can get mine and I take (all) yours when FlightGear keeps that all in one window approach for the next ten years. But maybe the width is not that exact, I didn't measure my screen size for this 5 sec. scribble, sorry for that. Just wanted to keep file size small and clipped height for all the ML readers with 640 x 480 and modem connection. Cheers, Yves Am 25.07.2012 um 12:17 schrieb Martin Spott <Mar...@mg...>: > HB-GRAL wrote: > >> New GUI with separated menus/dialogs, viewer in a separate window: >> http://maptest.fgx.ch/screens/one-screen.png > > Someone please buy me a display *that* wide so I can still afford using > space lateral to the viewer for the menu ;-) > > Cheers, > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -------------------------------------------------------------------------- > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2012-07-25 11:43:31
|
On 25 Jul 2012, at 11:42, stefan riemens wrote: > This is very convincing! Congratulations, that looks really neat. > Having seen this, I think we'd better go with the canvas approach. It > would require quite a lot of code to get osgWidget to produce that... Indeed! Thomas, can we have a discussion about a sensible roadmap for this, and what parts myself or Stefan could help with? I'm aware you've made some progress on this locally (based on some wiki pages), but apparently not discussing it here - could you summarise how you see this working so Stefan and I can review it? In particular I'm interested to see what aspects of XML -> building canvas elements are common between 2D panels, the GUI dialogs and HUD code. I'm also anxious that the 'front-end' XML and Nasal stays clean, i.e we have sufficient abstraction when creating dialogs and UI that we can vary the widget implementations without breaking existing dialogs. (This is effectively theming / styling) James |
From: James T. <zak...@ma...> - 2012-07-25 11:43:33
|
On 25 Jul 2012, at 11:42, stefan riemens wrote: > This is very convincing! Congratulations, that looks really neat. > Having seen this, I think we'd better go with the canvas approach. It > would require quite a lot of code to get osgWidget to produce that... Okay, I think Stefan and I are convinced :) Thomas, I have the impression you've been working on this stuff for a while, could you please summarise how you see it developing so Stefan and I can see where we might help. I'm pretty concerned to keep the Nasal code sufficiently structured that we vary the widget implementation without updating the dialogs. In particular, I'm concerned that we don't end up with inline Nasal dialog XML which depends on the widget implementation internals, simply because that's convenient in Nasal. (for example, the current dialog XML files don't know anything about 'mouse-handling', they work exclusively in bindings, and that's a good separation of UI events from semantic behaviours) I'd also like to see / understand how we manage XML / property-list file processing in a nice way, to support the various formats we want to create canvas elements from - GUI dialogs, 2D panels and HUDs. So, yes, if you could explain your plan here, and where people could help, that would be useful. Regards, James |
From: Martin S. <Mar...@mg...> - 2012-07-25 11:44:00
|
James Turner wrote: > Or to put it another way - the actual hard part is running the > widgets in the main OpenGL window - which *is* a requirement for > full-screen apps and multi-monitor setups. (Some people have claimed > otherwise, but I believe we need the option of 'in-window' UI for > many cases). I object - at last I can't envision a case where running the UI inside a separate window in front of a (full-screen) viewer is inferior to an in-window UI. All supported window systems provide the required information on screen/window-geometry or -placement to position a separate UI-window wherever you like. For the die-hards just think of a menu bar positioned in front of the upper left corner of the viewer-screen or -window having just very thin borders. From my perspective that's a pretty appealing approach because running the UI outside the viewer and probably/hopefully outside the main program could lead to a consistent management-/ control-interface in FlightGear. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Tim M. <tim...@gm...> - 2012-07-25 12:09:14
|
On Wed, Jul 25, 2012 at 1:43 PM, Martin Spott <Mar...@mg...> wrote: > James Turner wrote: > >> Or to put it another way - the actual hard part is running the >> widgets in the main OpenGL window - which *is* a requirement for >> full-screen apps and multi-monitor setups. (Some people have claimed >> otherwise, but I believe we need the option of 'in-window' UI for >> many cases). > > I object - at last I can't envision a case where running the UI inside > a separate window in front of a (full-screen) viewer is inferior to an > in-window UI. All supported window systems provide the required > information on screen/window-geometry or -placement to position a > separate UI-window wherever you like. > One avoids OpenGL rendering to more than one window if possible because graphics context switches are "expensive." I have no idea if this would affect normal FG usage. Portions of the OpenGL window buffer that are obscured by other windows are not guaranteed to be rendered correctly or at all, and in most implementations are not. This is less of an issue in newer OpenGL versions that support frame buffer objects and can do multi-pass rendering in an off screen buffer. > For the die-hards just think of a menu bar positioned in front of the > upper left corner of the viewer-screen or -window having just very thin > borders. From my perspective that's a pretty appealing approach > because running the UI outside the viewer and probably/hopefully > outside the main program could lead to a consistent management-/ > control-interface in FlightGear. A system menu bar is a slightly different. By definition it is not obscuring the main rendering window, and it is not updated unless the user interacts with it. It might be possible to simulate the same thing in FG with a menu bar in a separate window, but it would be very complicated to manage updating those windows differently from the main simulation window. I agree that separate user interface windows would be nice in several interesting use cases, but I don't think the default single-screen case is one of them. Tim > > Cheers, > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -------------------------------------------------------------------------- > > ------------------------------------------------------------------------------ > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Martin S. <Mar...@mg...> - 2012-07-25 11:48:43
|
ys wrote: > Am 25.07.2012 um 12:17 schrieb Martin Spott <Mar...@mg...>: >> HB-GRAL wrote: >> >>> New GUI with separated menus/dialogs, viewer in a separate window: >>> http://maptest.fgx.ch/screens/one-screen.png >> >> Someone please buy me a display *that* wide so I can still afford using >> space lateral to the viewer for the menu ;-) > Hey Martin, you can get mine and I take (all) yours when FlightGear > keeps that all in one window approach for the next ten years. The above has been a joke. I did *not* express my support for the current "all in one window" approach, but there are more options than just the two "all in one window" and "lateral to the viewer" :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: James T. <zak...@ma...> - 2012-07-25 14:35:39
|
On 25 Jul 2012, at 12:38, James Turner wrote: > Okay, I think Stefan and I are convinced :) Apologies for send 'the same email' twice, I'm on an erraitc connection and thought the first one had managed to not send, but also be deleted from my outbox, drafts /and/ sent mail folder. So I re-typed it, and then both turned up on the list! James |
From: Thomas G. <to...@gm...> - 2012-07-25 16:27:27
|
2012/7/25 James Turner <zak...@ma...>: > Thomas, I have the impression you've been working on this stuff for a while, > could you please summarise how you see it developing so Stefan and I can see > where we might help. I think it now slowly reaches a state where everything starts to stabilize. The API is really easy to use and most things should be already possible without any modification to the C++ code. Now we need to extend the API, create some helper functions/classes and have a look what is possible and what is still missing. > I'm pretty concerned to keep the Nasal code sufficiently structured that we > vary the widget implementation without updating the dialogs. In particular, > I'm concerned that we don't end up with inline Nasal dialog XML which > depends on the widget implementation internals, simply because that's > convenient in Nasal. > > (for example, the current dialog XML files don't know anything about > 'mouse-handling', they work exclusively in bindings, and that's a good > separation of UI events from semantic behaviours) I have based the implementation on many ideas from different existing technologies and projects. The most important are the Javascript DOM API and some Javascript/SVG/drawing APIs (eg. jQuery SVG [1]). For mouse handling I like the idea of having event handlers (eg. click, drag, hover, etc.). So instead of just one property holding the events of the whole dialog/canvas I want to forward the event to the according element by using picking or maybe for a first step just bounding box checking with the current mouse position. It would still just set the three properties like before (button, x, y) but we could add an helper function which adds a listener to the button property and calls a function with all three parameters if the event was triggered. (I always want to keep the basic idea of only communicating via the property tree). > I'd also like to see / understand how we manage XML / property-list file > processing in a nice way, to support the various formats we want to create > canvas elements from - GUI dialogs, 2D panels and HUDs. We could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser. > So, yes, if you could explain your plan here, and where people could help, > that would be useful. Missing things: - Documentation: Read, ask questions, extend. I haven't done too much documentation (apart from inline documentation) just due to the reason that the API is not completely stable yet. You could also try different use-cases and maybe find some examples where the API lacks some features. - Clipping: For different reasons we will need to be able to clip some elements to certain regions. It should work with specifying either a clipping rectangle or by using a path. OpenVG seems to have support for it, although I haven't looked into it too deep. We also need to ensure that it also works with text. - Geographic Mapping: It's very experimental, missing different projection modes (eg. vertical projection) and especially the Nasal API feels very hackish. - Picking: For mouse handling some kind of picking would be nice. As already mentioned, at least bounding box intersections will be needed. - Animations: I don't know if we should do animations just be using interpolator and settimer from Nasal or if we should implement some time-based animations directly in C++. At least we need some helper functions (eg. for blinking elements -> cursor, fading, ...) - Improve PUI to allow eg. receiving mouse over events. - Improve the Nasal API: Add some helper functions for animating different glass cockpit displays (I have already some basic code, but it needs some generalization). - Implement some widgets in Nasal. - Check what is missing to implement the different hardcoded instruments. - Allow placing images inside the canvas. - Maybe support displaying shapefiles. - I also want to unify the canvas creation a bit, such that canvases can be moved seamless between the different placements (gui, model, hud, etc.). The normal model placement is great but the gui widget placement needs to be able to also use an already existing canvas. - Support copy&paste: I'm working on the selection part, but have no clue yet on how to access the system clipboard. - Find more work I've currently forgotten about :) Please also have a look at the wiki [2]. There is already plenty of brainstorming outcome and also information about some current features. Regards, Tom [1] http://keith-wood.name/svg.html [2] http://wiki.flightgear.org/Canvas |
From: Thomas G. <to...@gm...> - 2012-07-25 21:43:11
|
I have now added some more thoughts about the GUI implementation and support of the current xml files to the wiki: http://wiki.flightgear.org/Canvas_Widgets#Fully_Canvas_based_implementation_.28planned.29 Regards, Tom |