[Deskbar] shows "Tracker Status" if you hide tracker's window

[diver]

Open Home floder from Desktop
Press Ctrl+Alt+H to hide this window
Go to Deskbar->Tracker
Screenshot attached
Tested in hrev31799 in virtualbox

[axeld]

Ctrl-Alt-H hides the application, not the window; Ctrl-Alt-M minimizes a single window.

Anyway, the problem should be fixed in hrev31012, although I'm not sure about the consequences yet (couldn't find anything harmful yet).

[axeld]

This caused indeed a problem with how CL-Amp opens its windows (they are minimized first, and shown afterwards).

[axeld]

(In #4206) Indeed, this is a duplicate of #4127, even though it has the better (more generic) description.

[diver]

Still here in hrev35570.

[diver]

Still here in hrev38300.

[ctbeiser]

Still exists in hrev 43475

[x-ist]

It's not even needed to open a Tracker window. Click on the desktop and press CTRL+ALT+H. In case the Tracker Preferences window has been opened once (then closed) "Tracker preferences" is listed in the menu as well.

The shortcut seems to modify those two windows, such that they pass the filter method in WindowMenu.cpp:

bool TWindowMenu::WindowShouldBeListed(uint32 behavior)
{
  if(behavior == kNormalWindow || behavior == kWindowScreen) 
    return true;
  ...
}

[x-ist]

Two ghost entries.

[leavengood]

x-ist, you don't quite have it right, but you were on the right track ;)

This is essentially impossible to fix with the current handling of the window_info.show_hide_level. It is set to 1 if the window is hidden within the app_server, and 0 if not. But when the window is minimized, it is also hidden.

But this is different than the hiding within BWindow, which is based on fShowLevel. When fShowLevel becomes zero or less (by calling Hide()), the window is hidden, and when it becomes 1 or more (by calling Show()) the window is shown. IsHidden() in BWindow is then simply fShowLevel <= 0. The window being minimized is a completely different boolean state.

I'm not sure why the show_hide_level is done this way, not only is it completely opposite of fShowLevel, it is barely representative of it.

Now where all this meshes with this bug in the Deskbar is the logic for showing windows: it is based on the window feel (as shown by x-ist above), but also on the show_hide_level and is_mini, which is a boolean in window_info indicating whether a window is minimized. The Deskbar logic is to add the window to the list if show_hide_level <= 0 (the window is showing) OR is_mini is true (the window is minimized.) Well guess what? If you minimize a hidden window it then passes this test (since it is then hidden and minimized). But if you take out the check for is_mini, then minimized windows are never shown, because they are also hidden (within the app_server, but not in BWindow.) And of course taking out the check for hidden always shows hidden windows.

So for this to really be fixed, the show_hide_level in the app_server needs to match fShowLevel in BWindow. This will also then make show_hide_level not a weird backwards variable.

[leavengood]

I quickly implemented some basic syncing of the BView fShowLevel with a new fShowLevel in the app_server Window class, and then implemented window_info.show_hide_level in terms of that. When I changed Deskbar to check if show_hide_level was > 0 to include windows in the list, this bug is fixed.

Since I'm not fully aware if changing the show_hide_level meaning has other implications, I'll wait before committing the fix.

Taking ownership.

[leavengood]

Actually this could still be fixed without changing the current backwards meaning of show_hide_level. The main fix is just maintaining the fShowLevel in the app_server and not using the window's hidden state to set the value of show_hide_level.

But if we can do it safely, I would like to make show_hide_level match fShowLevel.

[leavengood]

Fixed in hrev44520.

For now I have kept the confusing backwards definition of show_hide_level, but added a comment.