View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0007976ardourbugspublic2020-04-04 14:502020-06-03 14:50
Reporterjohne53 Assigned Tox42  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformWindows 10OSWindowsOS Version10
Product Version6.0-pre1 
Summary0007976: Mixer window isn't getting shown any more when a session gets loaded
DescriptionThis has been reported a few times on the Mixbus forum but I only just noticed it happens with Ardour too…

Whenever you load a session (in Windows) the Editor window gets displayed but not the Mixer window. I happen to use Ardour on a dual-monitor system but I've a feeling it also affects single-monitor systems.
Steps To ReproduceSimply launch Ardour (or Mixbus) and load any session.
Additional InformationThe session's 'instant.xml' file contains an entry for the Mixer window. If I change its 'visible' property to "1” (with the session unloaded) and then I load the session, the Mixer window does get shown. But closing the session (regardless of whether or not I save it first) will always change the value back to visible=“0”.

There's also been a report that this doesn't affect Linux so it might only be affecting the Windows build.
TagsNo tags attached.

Activities

johne53

2020-04-04 17:25

reporter   ~0021167

When loading 'instant.xml' I can set a conditional breakpoint at this line in 'WindowProxy::set_state (const XMLNode& node, int /* version */)':-

    child->get_property (X_("visible"), _visible);

I can set the breakpoint to trigger when the node name is "Mixer" && '_visible == 1'. And sure enough it'll trigger if it's set to '1' in instant.xml.

But if I set a breakpoint at the corresponding line in 'WindowProxy::get_state ()' it never triggers (because '_visible' is never == 1). At first I assumed that the problem must lie here, a few lines earlier:-

    _visible = vistracker->partially_visible ();

but in fact '_visible' == 0 both before and after the call. So I'm not quite sure what's setting it to 0

Will try again tomorrow if I get some free time.

johne53

2020-04-04 17:34

reporter   ~0021168

In fact AFAICT nothing significant has changed in either 'libs/gtkmm2ext/window_proxy.cc' or 'libs/gtkmm2ext/visibility_tracker.cc' for well over a year.

johne53

2020-04-05 07:26

reporter   ~0021175

Here's the problem !!!

The c'tor for VisibilityTracker contains a line like this:-

    , _visibility (GDK_VISIBILITY_FULLY_OBSCURED)

which got changed on 23-Sep-2018 (commit #d48dd0ccd5). It previously looked like this:-

    , _visibility (GdkVisibilityState (0))

In other words, windows are now initialised to fully obscured. And the window state gets changed here:-

bool
VisibilityTracker::handle_visibility_notify_event (GdkEventVisibility* ev)
{
    _visibility = ev->state;
    return false;
}

BUT... I placed a breakpoint in that function and on Windows, it never seems to get called. So the window state will be permanently set to GDK_VISIBILITY_FULLY_OBSCURED. And reverting commit #d48dd0ccd5 does fix the problem (although the real problem is the fact that the notify events aren't happening...)

johne53

2020-04-05 10:16

reporter   ~0021176

Some more info - I just found this at:- https://developer.gnome.org/gtkmm/stable/classGtk_1_1Widget.html

signal_visibility_notify_event() will be emitted when the widget's window is obscured or unobscured.
Deprecated:
Modern composited windowing systems with pervasive transparency make it impossible to track the visibility of a window reliably, so this signal can not be guaranteed to provide useful information.

x42

2020-04-05 14:31

administrator   ~0021177

Nice work tracking this down.

Keep in mind that gtkmm/stable is 3.x and not relevant for our codebase. The code under the hood has changed significantly from gtk-2.x.
Check https://developer.gnome.org/gtkmm/2.24/classGtk_1_1Widget.html

The signal is still emitted on Mac and Linux. It would be interesting if this signal can was emitted on Windows in older builds, or only worked because visibility wasn't initially set to GDK_VISIBILITY_FULLY_OBSCURED

johne53

2020-04-05 16:05

reporter   ~0021185

My understanding is that rather than being a Gdk issue, it was the OS functionality which changed (very likely only in Windows) and therefore the notifications couldn't be relied upon any more for all OS's. So if that's the case, there's a good chance it was already unreliable in ver2 - even if they didn't get around to deprecating it until ver3 (all guesswork of course - just hunches!!)

But yes I tend to agree that previously, it perhaps worked in (say) Windows XP - but for the more modern Windows it just gave the appearance of working because we weren't initializing with GDK_VISIBILITY_FULLY_OBSCURED. If that's the only option that'll work for the other platforms could we maybe do something like this?

#ifdef PLATFORM_WINDOWS
    , _visibility (GdkVisibilityState (0))
#else
    , _visibility (GDK_VISIBILITY_FULLY_OBSCURED)
#endif

johne53

2020-04-06 09:55

reporter   ~0021205

Just found something else that helps...

    Window->Preferences->Show->Appearance->Quirks->Use visibility information provided by your Window Manager/Desktop

If that option is left unchecked it restores the expected functionality (I've tested on Win8.1 and also Win10).

So maybe we could remove that option in the Windows build (or simply advise Windows users to leave it unchecked) ?

johne53

2020-04-16 10:52

reporter   ~0021364

JFI - over on the Mixbus forum this was reported yesterday for OS-X Yosemite (i.e. it's not purely a Windows issue). And unchecking the 'visibility' preference fixed it there too. AFAICT Linux distros seem to work as intended.

paul

2020-04-17 19:26

administrator   ~0021376

It seems as if we should disable that option for macOS and Windows.

x42

2020-04-19 17:01

administrator   ~0021402

Proposed change was applied in 6.0-rc1-9-g498a58bd25

anonymous

2020-06-03 14:50

viewer   ~0024368

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2020-04-04 14:50 johne53 New Issue
2020-04-04 17:25 johne53 Note Added: 0021167
2020-04-04 17:34 johne53 Note Added: 0021168
2020-04-05 07:26 johne53 Note Added: 0021175
2020-04-05 10:16 johne53 Note Added: 0021176
2020-04-05 14:31 x42 Note Added: 0021177
2020-04-05 16:05 johne53 Note Added: 0021185
2020-04-06 09:55 johne53 Note Added: 0021205
2020-04-16 10:52 johne53 Note Added: 0021364
2020-04-17 19:26 paul Note Added: 0021376
2020-04-19 17:01 x42 Assigned To => x42
2020-04-19 17:01 x42 Status new => resolved
2020-04-19 17:01 x42 Resolution open => fixed
2020-04-19 17:01 x42 Note Added: 0021402
2020-06-03 14:50 anonymous Note Added: 0024368
2020-06-03 14:50 anonymous Status resolved => closed