Howto:Processing legacy PUI dialogs using Canvas: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 14: Line 14:
{{Canvas Navigation}}
{{Canvas Navigation}}
{{FGCquote|1= Qt widgets can be drawn into OpenGL buffers. That doesn't change the fact that it would be a great deal of work to port our GUI to Qt, and it would introduce a very large external dependency. Having seen the fit pitched when I started using boost... Now, big projects can get done, and motivated individuals with time on their hands can work wonders. We should keep in mind the relative importance of the GUI system to the whole flying experience and judge whether it would be worth the effort to do a huge rewrite in this area.|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/24467194/  | title  = <nowiki>Re: [Flightgear-devel] GUI dialogs suck</nowiki>  | author = <nowiki>Tim Moore</nowiki>  | date  = Jan 30th, 2010  }}}}
{{FGCquote|1= Qt widgets can be drawn into OpenGL buffers. That doesn't change the fact that it would be a great deal of work to port our GUI to Qt, and it would introduce a very large external dependency. Having seen the fit pitched when I started using boost... Now, big projects can get done, and motivated individuals with time on their hands can work wonders. We should keep in mind the relative importance of the GUI system to the whole flying experience and judge whether it would be worth the effort to do a huge rewrite in this area.|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/24467194/  | title  = <nowiki>Re: [Flightgear-devel] GUI dialogs suck</nowiki>  | author = <nowiki>Tim Moore</nowiki>  | date  = Jan 30th, 2010  }}}}
As of 05/2017, James is still very much undecided about which technology to use for in-sim GUI, he is somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is James is fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy my ideas about how simple + robust such an API should be, James needs to evaluate if the current API can be improved or needs to be drastically changed. The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes me nervous about multi-window setups and other more esoteric OSG configs.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35863607/
  |title  =  <nowiki> Re: [Flightgear-devel] KBOS runway list? are there 10 or are there
12? </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  May 28th, 2017
  |added  =  May 28th, 2017
  |script_version = 0.40
  }}</ref>


FlightGear's rudimentary gui ([[PUI]]) is written all in opengl so it works fine in full screen and doesn't need tricky interactions with the underlying OS (the details of which often vary wildly from one OS or window system to the next.)  Qt has taken great strides in lowering this barrier and James is a Qt expert, but it's still a massive amount of work with a lot of build/dependency implications to convert a whole gui system (and test all the edge cases.)<ref>{{cite web
FlightGear's rudimentary gui ([[PUI]]) is written all in opengl so it works fine in full screen and doesn't need tricky interactions with the underlying OS (the details of which often vary wildly from one OS or window system to the next.)  Qt has taken great strides in lowering this barrier and James is a Qt expert, but it's still a massive amount of work with a lot of build/dependency implications to convert a whole gui system (and test all the edge cases.)<ref>{{cite web

Navigation menu