Opened 12 years ago

Last modified 11 years ago

#10973 new enhancement

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

Reported by: Marcell Owned by:
Priority: normal Milestone:
Component: GUI-generic Version: stable-latest
Keywords: iconize, event, workspace, hide Cc:
Blocked By: Blocking:
Patch: no

Description

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.

Change History (15)

comment:1 Changed 12 years ago by Marcell

  • Keywords hide added
  • Priority changed from normal to high
  • Status changed from new to confirmed
  • Type changed from defect to enhancement

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.

comment:2 Changed 12 years ago by vadz

  • Milestone set to 2.9.1
  • Priority changed from high to normal

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?

comment:3 Changed 12 years ago by Marcell

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.

comment:4 Changed 11 years ago by vadz

  • Milestone 2.9.1 deleted

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

comment:5 Changed 11 years ago by Marcell

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

comment:6 Changed 11 years ago by vadz

  • Version changed from 2.8.10 to 2.9-svn

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.

comment:7 Changed 11 years ago by roebling

  • Owner set to roebling
  • Status changed from confirmed to accepted

comment:8 Changed 11 years ago by RR

  • Resolution set to fixed
  • Status changed from accepted to closed

(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]

comment:9 Changed 11 years ago by Marcell

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:10 Changed 11 years ago by roebling

  • Status changed from reopened to infoneeded_new

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

comment:11 Changed 11 years ago by Marcell

  • Owner roebling deleted
  • Status changed from infoneeded_new to new

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.

comment:12 follow-up: Changed 11 years ago by roebling

  • Status changed from new to infoneeded_new

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.

comment:13 in reply to: ↑ 12 Changed 11 years ago by Marcell

Replying to 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.

comment:14 Changed 11 years ago by roebling

  • Status changed from infoneeded_new to new

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.

comment:15 Changed 11 years ago by Marcell

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.

Note: See TracTickets for help on using tickets.