From: James T. <jam...@kd...> - 2017-10-08 09:53:07
|
> On 7 Oct 2017, at 21:02, Florent Rougon <f.r...@fr...> wrote: > Wow. When you say "PUI replacement UI", is it Canvas replacing PUI, or > Qt? Does it count menus and dialogs... or did I misunderstand > completely? :) Qt replacing PUI, but I already coded up a Canvas QtQuick item (needs testing) since something like the map dialogs, makes no sense to do a new API for. So I expect we’ll use Qt fo the main UI (menus, dialogs, buttons, overlays like the MP pilot list) and emulating PUI, but we have the option to embed pieces of canvas - for things like fuel / payload screens, map views or whatever. I don’t think doing most of the UI in canvas makes sense, since it means lots of Nasal structure and it’s very unique to FG - whereas QtQuick is very easy and friendly to hack on. (There’s even some tooling!) Of course just as now I can’t prevent people doing Canvas UIs, I just think it’s bad for the simulator’s usability - eg QtQuick supports accessibility which people have been asking about, Canvas UI can never do this. Parts of the launcher will also become QtQuick based (like the aircraft list already did) so they can be used directly in the sim. > I vaguely seem to recall that some people with two screens use the 2D > panel on one of the screens, but it's quite possible I confused this > with FGPanel (different things, right?). FGPanel is a separate implement of the 2D panel logic, indeed. As I said I have a partial implementation using canvas (which could then work over remote-canvas!), but since almost no one uses 2D panels, I didn’t have much motivation to push forward that work. If anyone would like to continue it, it’s a fun little project. > >> Finally, we need JS, although that is very tiny. And at least in the case of >> JS, there’s some bug-fixes it would be nice to get in. So, I propose we put >> plib inside the flightgear/3rdparty dir, and give the parts we need a CMake >> build system. Then we can apply the fixes there. > > Yup, at last this would allow to apply fixes. For the CMake build > system, what Clément did at [1] should be a good starting point, I > suppose. > >> The distro maintainers might object, since at least for the JS code, we would >> move it under src/Input and fork it. > > Possibly, but on the other hand, assuming we don't change any interface, > it would maybe be possible to let distros continue to use their plib as > long as they want, managing its security centrally[2] while keeping > the existing bugs... I mean, some CMake switch to build and link against > either "fgplib" (shipped in our repo) or plib (classical plib). Okay I was assuming the API would change, if it doesn’t then indeed we can add a —system-plib option But, JS is is a special case because it will need to remain forever, and we would probably start to almost re-write it once it lived in our tree (I’d move the files into src/Input) And, FNT is basically three files - so I think it’s really only PUI and the SG code it needs we’re talking about. > Dunno... On Debian stable, its reverse depends are: > > % apt-cache rdepends libplib1 > > libplib1 > Reverse Depends: > libplib-dev > torcs > stormbaancoureur > crrcsim > openuniverse > flightgear > libplib-dev > libplib1-dbgsym > Wow, that is more that I expected indeed! A lot of ancient+slow OpenGL code out there :) Kind regards, James |