Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iconize event triggered when switching workspaces with Ctrl+Alt+[Arrow Key] #10973

Open
wxtrac opened this issue Jul 7, 2009 · 15 comments
Open

Iconize event triggered when switching workspaces with Ctrl+Alt+[Arrow Key] #10973

wxtrac opened this issue Jul 7, 2009 · 15 comments

Comments

@wxtrac
Copy link
Collaborator

@wxtrac wxtrac commented Jul 7, 2009

Issue migrated from trac ticket # 10973

component: GUI-generic | priority: normal | keywords: iconize, event, workspace, hide

2009-07-07 22:20:20: Marcell created the issue


The main window of the affected application registers the Iconize event as follows:

BEGIN_EVENT_TABLE(CamuleDlg, wxFrame)
// ...
EVT_ICONIZE(CamuleDlg::OnMinimize)
// ...
END_EVENT_TABLE()

The problem is that OnMinimize() gets called when the window is NOT(!) minimized and the workspace is switched using the key combination Ctrl+Alt+[Left Arrow] and Ctrl+Alt+[Right Arrow].
The result is that the window gets minimized when the workspace is switched.

I don't expect the OnMinimize() event to be called in such a situation.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Jul 31, 2009

2009-07-31 23:07:36: Marcell changed priority from normal to high

2009-07-31 23:07:36: Marcell changed status from new to confirmed

2009-07-31 23:07:36: Marcell changed type from defect to enhancement

2009-07-31 23:07:36: Marcell commented

Further investigations revealed that switching the workspace (using the keyboard or the mouse) always triggers the OnMinimize() event. There is no chance to distinguish between these two events.

In my opinion there should be an extra event that occurs if the workspace has been switched. This lets the application react accordingly.

The main problem behind this is that there is an option in the application whether the window should be hidden when minimized. This currently also happens when the workspace is switched and the small thumbnail in the workspace area disappears. It shouldn't.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Aug 1, 2009

2009-08-01 15:38:12: @vadz changed priority from high to normal

2009-08-01 15:38:12: @vadz commented

It would be great to fix this, it's indeed very annoying that iconize events are generated when the window is not really minimized. OTOH I have my doubts about whether this is possible at all as, from what I know, the WM does basically the same thing (unmaps the window) both when minimizing it and when switching workspaces. But maybe there is still some way to distinguish between them, would anybody know more about this?

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Aug 1, 2009

2009-08-01 22:55:35: Marcell commented


Yes, I also suppose that the window manager "minimizes" the windows when the workspace gets switched. But it should theoretically be possible to have an extra event for this. It would enable the developer to distinguish between only minimizing the window or also changing the workspace.

Sorry for setting the priority to high. I know that it's not something that helps, I must have been frustrated, because there was no reply in over 3 weeks.

Thank you for your reply, I really appreciate it and hope there will be an improvement in this matter soon.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented May 22, 2010

2010-05-22 17:38:27: @vadz commented


Unfortunately I won't have time to do anything about this before 2.9.1 so resetting milestone. Somebody else would need to debug this if it still happens...

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Oct 23, 2010

2010-10-23 22:39:54: Marcell commented


It still does happen. I tested it with the trunk version of wx.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Oct 23, 2010

2010-10-23 23:53:19: @vadz commented


Thanks for testing. Unfortunately I still don't know how to fix this and still hope that someone else can find a way to distinguish between really minimizing the window and just getting it out of the way to switch to another virtual desktop.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Oct 27, 2010

2010-10-27 19:01:08: roebling (Robert Roebling) changed status from confirmed to accepted

2010-10-27 19:01:08: roebling (Robert Roebling) commented

We need to connect to

http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#GtkWidget-window-state-event

and check for the

http://library.gnome.org/devel/gdk/unstable/gdk3-Event-Structures.html#GdkWindowState

event flag. No idea when this was introduced.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Oct 27, 2010

2010-10-27 21:42:39: RR commented


(In [65932]) Use window-state-event to send ICONIZE events under GTK+, probably fixes #10973: Iconize event triggered when switching workspaces with Ctrl+Alt+[Arrow Key]

2010-10-27 21:42:39: RR changed status from accepted to closed

2010-10-27 21:42:39: RR set resolution to fixed

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 15, 2010

2010-11-15 19:02:34: Marcell changed status from closed to reopened

2010-11-15 19:02:34: Marcell changed resolution from fixed to **

2010-11-15 19:02:34: Marcell commented

Unfortunately the issue is not fixed.

The event handler registered using EVT_ICONIZE() is still called when the user switches the workspace using [Ctrl] + [Alt] + [Arrow Key].

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 15, 2010

2010-11-15 20:29:38: roebling (Robert Roebling) changed status from reopened to infoneeded_new

2010-11-15 20:29:38: roebling (Robert Roebling) commented

On my systen, the if-clause of the new gtk_frame_window_state_callback() in src/gtk/toplevel.cpp is only called when I iconize the frame, not when I switch desktops.

Could you set a printf() there (line 383) to check that your system reports the GTK+ event differently (which is possible)?

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 17, 2010

2010-11-17 21:48:34: Marcell changed status from infoneeded_new to new

2010-11-17 21:48:34: Marcell commented

I got the following information using 'printf("changed_mask: %d\n", event->changed_mask);':

changed_mask: 2
changed_mask: 1
changed_mask: 4

This was when I switched to another workspace from the particular one where the application window was visible.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 21, 2010

2010-11-21 12:42:04: roebling (Robert Roebling) changed status from new to infoneeded_new

2010-11-21 12:42:04: roebling (Robert Roebling) commented

This is obviously the cause of the problem - I don't get the "2" here and actually not the "4" either. I'm using a standard and rather old GNOME system and I can imagine that this is very much window manager dependent.

Currently, I don't see any way to correct this for your system since I think the current code is correct in the sense of using the GTK+ API, but please test what normal iconification gets for results and if we/you might use the pattern to send the events correctly.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 21, 2010

2010-11-21 22:50:48: Marcell commented


Replying to [comment:12 roebling]:

This is obviously the cause of the problem - I don't get the "2" here and actually not the "4" either. I'm using a standard and rather old GNOME system and I can imagine that this is very much window manager dependent.

Currently, I don't see any way to correct this for your system since I think the current code is correct in the sense of using the GTK+ API, but please test what normal iconification gets for results and if we/you might use the pattern to send the events correctly.

Please elaborate: "what normal iconification gets for results and if we/you might use the pattern to send the events correctly". I don't think I understand what I should/can do.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 22, 2010

2010-11-22 18:26:09: roebling (Robert Roebling) changed status from infoneeded_new to new

2010-11-22 18:26:09: roebling (Robert Roebling) commented

Record with the printf() what sequence of change values in event->changed_mask and ->new_value you get. maybe the sequence after changing the desktop is "2","1","4" and the sequence for normal iconification is different (maybe just "1") so when ever a "1" is reported you wait until idle and (if until idle) no "4" has arrived then it was an iconification, otherwise a change of desktop.

The problem is that this approach is likely to fail on other systems, of course.

@wxtrac
Copy link
Collaborator Author

@wxtrac wxtrac commented Nov 28, 2010

2010-11-28 20:36:43: Marcell commented


Forgive my misleading information. The "1" and "4" result from the application calling Show()/Hide() to minimize itself to the tray icon (meaning the window should not be visible in the task bar).

So my problem still persists that OnMinimize() - the eventhandler registered for the ICONIZE event - is being called when the workspace is switched. This is the "changed_mask" value "2" which is returned on both cases: the window is actually minimized and when the workspace is switched. Thus I can't distinguish between the two events.

I believe that the window manager minimzes the window when the workspace is switched, virtually creating the workspaces whilst every window is still there, but hidden. Therefore it's quite understandable that OnMinimize() is called in this situation. But it leads to the undesired result that my application always minimizes itself, even if it should remain shown.

To clarify some things I want to add the following:
I noticed the behaviour by watching the small workspace areas in the task bar panel in ubuntu. I see my applications window disappear on workspace one when I switch to workspace two. This doesn't happen with other applications like firefox. So I figured it is not normal. But I am not sure if I have to do something about this myself, but I suppose I can't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant