Opened 10 years ago

Closed 7 years ago

#4127 closed bug (fixed)

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

Reported by: diver Owned by: leavengood
Priority: normal Milestone: R1
Component: Applications/Deskbar Version: R1/Development
Keywords: gci2011 Cc:
Blocked By: Blocking: #4206
Has a Patch: no Platform: All


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

Attachments (2)

hidden window.png (60.4 KB) - added by diver 10 years ago.
00.png (26.4 KB) - added by x-ist 7 years ago.
Two ghost entries.

Download all attachments as: .zip

Change History (15)

Changed 10 years ago by diver

Attachment: hidden window.png added

comment:1 Changed 10 years ago by axeld

Resolution: fixed
Status: newclosed

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).

comment:2 Changed 10 years ago by axeld

Resolution: fixed
Status: closedreopened

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

comment:3 Changed 10 years ago by axeld

Blocking: 4206 added

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

comment:4 Changed 9 years ago by diver

Still here in hrev35570.

comment:5 Changed 9 years ago by diver

Version: R1/pre-alpha1R1/Development

comment:6 Changed 9 years ago by diver

Still here in hrev38300.

comment:7 Changed 7 years ago by ctbeiser

Still exists in hrev 43475

comment:8 Changed 7 years ago by ctbeiser

Keywords: gci2011 added

comment:9 Changed 7 years ago by 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;

Changed 7 years ago by x-ist

Attachment: 00.png added

Two ghost entries.

comment:10 Changed 7 years ago by 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.

comment:11 Changed 7 years ago by leavengood

Owner: changed from axeld to leavengood
Status: reopenedin-progress

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.

comment:12 Changed 7 years ago by 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.

comment:13 Changed 7 years ago by leavengood

Resolution: fixed
Status: in-progressclosed

Fixed in hrev44520.

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

Note: See TracTickets for help on using tickets.