Board index FlightGear Support Flying

Annoying bug

Controlling your aircraft, using the autopilot etc.

Annoying bug

Postby RJ5576 » Wed Jun 06, 2018 1:00 am

If I drag the mouse over a dialog box while holding down the right mouse button, or click in a dialog box while in look-around mode, I cannot get out of look-around mode without resetting the simulator.
RJ5576
 
Posts: 88
Joined: Wed Feb 20, 2013 3:24 am
Location: Between KSEA and KPDX
Callsign: RJ5576
Version: 2018.1.1
OS: Linux Mint Sylvia

Re: Annoying bug

Postby V12 » Wed Jun 06, 2018 4:25 am

And FG version ?
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 638
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: Annoying bug

Postby wkitty42 » Wed Jun 06, 2018 5:14 am

@V12: his profile box on the right says he's using 2018.1.1...

@RJ5576: IIRC, this has been fixed in 2018.3.0... i think it has also been backported to 2018.2.2...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4739
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Annoying bug

Postby RJ5576 » Wed Jun 06, 2018 6:33 am

I haven't updated my profile, but I have recently updated to FG 2018.2.1.
RJ5576
 
Posts: 88
Joined: Wed Feb 20, 2013 3:24 am
Location: Between KSEA and KPDX
Callsign: RJ5576
Version: 2018.1.1
OS: Linux Mint Sylvia

Re: Annoying bug

Postby wkitty42 » Wed Jun 06, 2018 4:24 pm

there was an attempt to fix it for 2018.2.1 but that worked only partially... some more work on it was done and should be available, as noted, in 2018.2.2...

FWIW: part of this be due to the work being done to remove PUI and replace it with something modern and future-proof... part of the work, as i understand it, is ""conversion wrappers"" that take the PUI calls and convert them to the new stuff... this way folks are not hampered by the changes and their existing PUI code and menus will still work... later the wrappers may be removed and the whole new system exposed so that devs can (finally) switch to the new methods... by then, PUI should be gone... it hasn't been maintained or updated in a long time...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4739
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Annoying bug

Postby Hooray » Sat Sep 15, 2018 5:48 pm

wkitty42 wrote in Wed Jun 06, 2018 4:24 pm:part of this be due to the work being done to remove PUI and replace it with something modern and future-proof... part of the work, as i understand it, is ""conversion wrappers"" that take the PUI calls and convert them to the new stuff... this way folks are not hampered by the changes and their existing PUI code and menus will still work... later the wrappers may be removed and the whole new system exposed so that devs can (finally) switch to the new methods... by then, PUI should be gone... it hasn't been maintained or updated in a long time...


that's a pretty accurate summary - the work will normally involve coming up with a parser (or preferably, hooking into the existing hard-coded one, that's known to work), and writing a corresponding wrapper to map known PUI features to the corresponding new technology stack.

There is still quite a bit of legacy OpenGL code in FlightGear that also hasn't been maintained/touched in years, i.e. not just the PUI based GUI, but also stuff like the HUD code or the 2D panels code.
James suggested on several ocassions that for these legacy features (GUI, HUD and 2D panels), a Nasal based wrapper could/should be written to phase out the underlying C++ code without deprecating existing functionality.

Thus, reviewing the Canvas system to extend it so that such features can be ported/re-implemented using native Canvas hooks, will also be a major step towards unifying the 2D rendering back-end in FlightGear (which is to say that there will be additional benefits in terms of compatibility, performance and stability, because everything is going through a single OSG-enabled layer): http://wiki.flightgear.org/Unifying_the ... via_canvas

I've previously prototyped a Nasal space wrapper demonstrating how a scripting space Nasal/Canvas layer can be used to interpret/re-implement existing PUI dialogs without requiring any C++ changes, and without going through the legacy PUI engine at all, while this was only intended to be a proof-of-concept demonstrating a fast track concept to get rid of PUI, it's been shown to work for fairly complex PUI dialogs that contain tons of embedded Nasal blobs, including even those using an embedded Canvas (e.g. map-canvas.xml):
http://wiki.flightgear.org/Howto:Proces ... ing_Canvas
Image

Notably, the same mechanism could also work for a Canvas-enabled Phi back-end:
http://wiki.flightgear.org/Read_canvas_image_by_HTTP
Image

For anyone interested in the nitty gritty details, James recently laid out the technical steps in a discussion about phasing out the hard-coded C++/HUD component by creating a scripting space wrapper in Nasal that maps HUD primitives to Canvas primitives, and also suggested doing that with the 2D panels subsystem.
James Turner wrote:https://sourceforge.net/p/flightgear/ma ... /36399261/
I would recommend:

- replace the HUD (HUD.cxx and related code) with a Canvas implementation. This is a confusing scheme, since we have ‘old’ and ‘new’ C++ HUDs (but I recall I unified their rendering some years ago), and some aircraft already using ‘custom Canvas HUDs’, i.e totally independent of the ‘built-in’ HUD.

To be clear, this is the HUD you get by pressing ‘h’ key in the sim. It’s configured by an XML file: FG_DATA/Huds/default.xml - and you can see in that directory, other configs are possible - the ‘new C++ HUD’ layer allows arbitrary placement of HUD elements defined by these XML.

Some* aircraft, but I don’t know how many, use the C++ HUD system, but replace the default HUD with their own - see the F16 example file also in FG_DATA/Huds for example.

The aim would be to replace the C++ code with a Nasal HUD layer, likely in FG_DATA/Canvas/Hud - with one Canvas HUD item per each of the current C++ HUD items (ladder, tape, dial etc). Each one should be fairly easy to build with some path, text and group commands.

Then we need to write an XML loader in Nasal, possibly one line of C++ to trigger loading, and we can remove the C++ HUD code in favour of the Canvas implementation.

Of course, probably it’s not so simple but this is the concept!

https://sourceforge.net/p/flightgear/ma ... /36401850/
If the new impl defines each HUD component with the same features as the C++ implementation, it should work as a drop-in replacement for the old system. (Honestly it may be the case that some features supported in C++ are not used by any aircraft out there, but as ever with FG, we have no way to capture the set of in-use features).

If you look at say HUD_tape.cxx - which is one of the more complex ones - it’s some fairly ‘simple’ (but verbose) code to draw either a horizontal or vertical tape. Mostly it comes down to many draw_line calls which ultimately do the OpenGL - you can replace the draw_line calls in a Nasal version with appending a moveTo,lineTo onto a Canvas path.

And the constructor for HUD::Tape::Tape shows you the XML config properties for the tape which are supported.
[...]
Once we are happy that the Canvas impl works correctly, it should be visually identical to what we have now, and the native impl can be dropped.

https://sourceforge.net/p/flightgear/ma ... /36406449/
if we are to move beyond the legacy C++ code, we need a layer (in Nasal or C++) that parses the existing HUID XML, and looks/works close-to-identical to the current version.

https://sourceforge.net/p/flightgear/ma ... /36401971/
There’s nothing per-se about doing a HUD via Canvas, that requires this - I’m guessing the Canvas-HUD-that-replaces-the-C++-one would appear the same way Canvas tooltips / popups do. (or Canvas dialogs, or…)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11164
Joined: Tue Mar 25, 2008 8:40 am


Return to Flying

Who is online

Users browsing this forum: No registered users and 3 guests

cron