Menu GUI dialogs not closing

[daviduu]

I hope this is in the right section - please let me know if not. I have three monitors networked to three computers. A master instance of Flightgear Barcelona running on a Windows 10 i7 laptop with NVIDIA 550 graphics and two slaves (left & right views) are each running Flightgear which are Windows 7 i4 machines with Radeon HD5570 GPU. I have single camera views with fustrums set up on each machine and the display is absolutely fantastic albeit ~20fps which is entirely acceptable.

My problem is with the GUI menu on the master machine (which is in a separate window to the camera view) in that it does not close it's dialog boxes - they freeze open and won't close although other dialogs can be opened and selected until there is an overlay of open dialog boxes in the window. When I click on a *close* key or the top right hand *close* button they *depress* visually and stay that way without doing anything. Switch to the camera view window and the simulator still works fine but the only way I can get the menu dialogs to close is to hit the top RHS "X"tab of the Menu window which quits Flightgear altogether.

It is a bit beyond me as to why this is happening although I suspect it has something to do with bindings of keys.

I have set up the Master machine as follows:

The *preferences.xml* has been copied to the flightgear.org folder in *user* directory and the following code has been entered just after the <rendering> section heading at the top of the file;

Code: Select all

<camera-group>
      <window>
         <name type="string">Front View</name>
         <host-name type="string"></host-name>
         <display>0</display>
         <screen>0</screen>
         <fullscreen type="bool">false</fullscreen>
      </window>

      <camera>
         <window>
            <name>Front View</name>
         </window>
         <viewport>
            <x>0</x>
            <y>0</y>
            <width>1920</width>
            <height>1200</height>
         </viewport>
         <view>
            <heading-deg type = "double">0</heading-deg>
            <roll-deg type = "double">0</roll-deg>
            <pitch-deg type = "double">0</pitch-deg>
         </view>
         <frustum>
            <top>0.082</top>
            <bottom>-0.070</bottom>
            <left>-0.136</left>
            <right>0.136</right>
            <near>0.2</near>
            <far>120000.0</far>
         </frustum>
      
      </camera>
      <gui>
         <window>
            <name type="string">GUI</name>
         </window>
      </gui>

</camera-group>

In the *Cockpit View* section further down the file I have done <internal type="bool">true</internal> - by default it was false. I did this because the cockpit didn't display when I moved the *preferences.xml* to the *user* directory.

The problem happens irrespective of the slaves being connected or not. If I start Flightgear without the above <camera-view> code in *preference.xml* I get a single window with the forward cockpit view with the GUI menu along the top. The dialogs behave as they are meant to and don't lock up. But when the camera view code is re-entered the GUI gums up. I don't know enough about programming to even begin to troubleshoot this.

Does anyone have any idea what is happening please? I am sure it would be easy to replicate doing the above steps. If further information could be useful let me know.

[daviduu]

Updating my post from last night. Both Slaves exhibit the same behavior with the menu GUI as the Master - I didn't notice this before as the camera view is all I use at full-screen. I did notice that the information block at the top of the Slave GUI windows (ie "You are on runway 20. Welcome aboard! Need help? Use 'Help -> Tutorials'.) is rendered twice on top of each other one line offset. Also bringing up the property explorer and trying to move it leaves a trail of staccato dialog boxes filling the screen. This makes me think the local Slave fdm is interfering with the network data from the Master instance. I thought selecting --fdm="null" stopped anything like that. Obviously not.

For the technically minded I copied all the settings in --sim/gui with the <camera-group> code in and again with it removed and compared the two files.
I'm sorry I cannot highlight the differences so have placed each relevant section under each other for easy reference.

With code

Code: Select all

   canvas
        size 1024
        size[1] 741
        style
            colors
        window
            capture-events 0
            fill rgba(255,255,255,0.8)
            size 300
            size[1] 100
            source
            visible false
            z-index 2


Without code

Code: Select all

    canvas
        size 1024
        size[1] 737
        style
            colors
        window
            capture-events 0
            fill rgba(255,255,255,0.8)
            size 300
            size[1] 100
            source
                bottom 1
                normalized true
                right 1
            visible false
            z-index 2

With code

Code: Select all

overlay-select-1
            dialog
                dialog-name overlay-select-1
                group
                hrule
                layout vbox
                list
                    binding
                        command dialog-apply

Without code

Code: Select all

 overlay-select-1
            dialog
                dialog-name overlay-select-1
                group
                hrule
                layout vbox
                list
                    binding

With code

Code: Select all

overlay-select-3
            dialog
                dialog-name overlay-select-3
                group
                    button
                        binding
                            command nasal
                            script gui.Dialog.instance["overlay-select-3"].close()
                        border 2
                        default 1
                        keynum 27
                        legend
                        pref-height 16
                        pref-width 16
                    empty
                        stretch 1
                    empty[1]
                        stretch 1

Code: Select all

overlay-select-3
            dialog
                dialog-name overlay-select-3
                group
                    button
                    empty
                    empty[1]
 

Needless to say I wouldn't know where to start to see where and how these differences happen and if they even have any bearing on the visual results so I experimented.

I removed the <camera-group> tags entirely on the Master machine. Now instead of getting two windows I get a single view window with the menu along the top *AND* it closes dialogs properly. I've decided to leave it like this as it hasn't affected the view flow to the left and right monitors. I can live with the menu on the master but I don't want the menu's showing on the slaves so I will leave the <camera-group> tags in place on those. All environment settings and airport locations for all monitors can be controlled from the master menu so I don't need the menu's on the Slaves anyway - unless someone knows if they can be hidden. I'm sure there is a tag somewhere that does this but it has taken me several weeks to get to this point and I just want to get in and start using the simulator without being distracted by technical issues.

It would be nice to know why it has exhibited this behavior though so I welcome anyone with the time and expertise to investigate a little further

[Hooray]

Just briefly:
the PUI/GUI code predates the multi-view/screen/OSG (cameras) code by several years, and never has been well integrated, so that there are a number of such shortcomings/mutual incompatibilities - Curt once wrote a detailed posting, refer to the devel list for details

Note that this applies particularly to master/slave setups, which use yet another system to sync views - predating the OSG port by over a decade IIRC

PUI is scheduled to be phased out - for details, search the wiki for PUI - so I would not bother spending too much time with troubleshooting PUI related issues.

[daviduu]

Thank you for the heads up Hooray That all makes perfect sense.