After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 537183 - gtk_window_set_skip_taskbar_hint not working on Win32
gtk_window_set_skip_taskbar_hint not working on Win32
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.13.x
Other All
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
: 568888 613190 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-06-08 00:10 UTC by Erik van Pienbroek
Modified: 2018-02-10 03:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase (266 bytes, text/plain)
2008-06-08 00:12 UTC, Erik van Pienbroek
  Details
Proposed patch (1.40 KB, patch)
2008-06-10 20:37 UTC, Erik van Pienbroek
none Details | Review
Another testcase (709 bytes, text/plain)
2008-06-10 20:42 UTC, Erik van Pienbroek
  Details

Description Erik van Pienbroek 2008-06-08 00:10:32 UTC
Please describe the problem:
Hi,

I have developed a program in which the user can minimize the window to the system tray.
This is done by using the GtkStatusIcon and catching the 'window_state_changed' signal (from GtkWindow). In the 'window_state_changed' callback function I check whether an minimize just occured and if so, call gtk_window_set_skip_taskbar_hint(TRUE) to remove the program from the task bar.

On Linux this works fine, but under Windows (Vista) the program doesn't disappear from the taskbar.

Attached testcase demonstrates this behaviour

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Erik van Pienbroek 2008-06-08 00:12:02 UTC
Created attachment 112344 [details]
Testcase

This testcase is used against GTK 2.13.2
Comment 2 Cody Russell 2008-06-08 03:44:16 UTC
I think the taskbar skipping is closely related to how transient/modal windows are implemented in the Win32 backend.  I may have broken this while I was trying to fix the transient/modal window problems.

I'll try to take a look at this whenever I have time to work on the Win32 code again.
Comment 3 Erik van Pienbroek 2008-06-10 16:55:26 UTC
I just looked at the GDK source and I've found out that you put a comment in the function gdk_window_set_skip_taskbar_hint()...

### TODO: Need to figure out what to do here.

... followed by a return;

This was done in revision 18929: http://svn.gnome.org/viewvc/gtk%2B?view=revision&revision=18929

I've tried reverting this change. The hiding of the window now works, but the 'un-hiding' doesn't.
Comment 4 Erik van Pienbroek 2008-06-10 20:37:31 UTC
Created attachment 112508 [details] [review]
Proposed patch

Attached patch should make the function gtk_window_set_skip_taskbar_hint() work properly on Win32

I've also removed the #if 0 block as it doesn't have anything to do with removing the window from the taskbar and it hasn't been touched since 2003 (http://svn.gnome.org/viewvc/gtk%2B?view=revision&revision=9225)
Comment 5 Erik van Pienbroek 2008-06-10 20:42:37 UTC
Created attachment 112509 [details]
Another testcase

I've also updated the original testcase. This testcase switches the skip_taskbar_hint flag every 2 seconds.

The proposed patch introduces a slight flicker every time the skip_taskbar_hint function is called, but normally it is only called on initialisation or on minimize (to tray), so this shouldn't be too much of an issue
Comment 6 Cody Russell 2008-06-11 04:23:45 UTC
This is almost certainly going to confuse the transient window code, but I'll try to take a look at it this weekend and test it out.
Comment 7 Erik van Pienbroek 2008-07-17 23:11:24 UTC
After further testing I've found my proposed patch introduces a regression.. When trying to show a context menu (gtk_menu_popup), the context menu immediately disappears (just a quick flash)
Comment 8 Tor Lillqvist 2009-01-28 17:49:58 UTC
*** Bug 568888 has been marked as a duplicate of this bug. ***
Comment 9 Josh 2009-04-11 04:37:53 UTC
any updates on this? this bug has been open for nearly a year now.
Comment 10 Yann Leboulanger 2009-04-11 10:03:01 UTC
I still see the bug in GTK2.14.3
Comment 11 Tor Lillqvist 2009-04-11 17:03:17 UTC
> this bug has been open for nearly a year now

OK, so feel free to ask for your money back then.
Comment 12 Josh 2009-04-11 18:49:32 UTC
(In reply to comment #11)
> OK, so feel free to ask for your money back then.

No need to get cranky, Just asking for an update..geez
Comment 13 adrenalinedj 2009-05-20 11:00:07 UTC
I have te same problem...

But after some searches on Google, i found some pieces of answer and i made a function to make the trick for Windows....

void showWindowInTaskBar(gboolean bool)
{
	HWND handle;
	handle=(HWND)gdk_win32_drawable_get_handle(pWindow->window);
	if(bool)
	{
		SetWindowLong(handle, GWL_EXSTYLE, GetWindowLong(handle, GWL_EXSTYLE) & ~WS_EX_APPWINDOW);
		SetWindowPos(handle, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);
		SetForegroundWindow(handle);
    	ShowWindow(handle, SW_SHOW);
	}
	else
	{
    	ShowWindow(handle, SW_HIDE);
	}
}

pWindow is a GtkWidget* and the main window of my application.
This function hide the window in taskbar when bool=FALSE and show the window in taskbar + get the focus when bool=TRUE

It could be used while the bug is not yet fixed in GTK...
Comment 14 Isaac 2009-10-02 03:13:48 UTC
I'm a humble Pidgin user that doesn't like taskbar entries, and through some Googling came down to this RFE http://developer.pidgin.im/ticket/9690 pointing the problem to this bug.  Just wanted to let the people here know this bug could affect a lot of Windows users looking for a fix.
Comment 15 Tor Lillqvist 2009-10-02 08:28:59 UTC
The fix is easy: Use Linux instead.
Comment 16 Tor Lillqvist 2010-03-17 21:30:07 UTC
*** Bug 613190 has been marked as a duplicate of this bug. ***
Comment 17 Brad Carps 2010-03-22 07:49:12 UTC
(In reply to comment #15)
> The fix is easy: Use Linux instead.

Attitudes like this are a large part of why Linux software gets almost no love outside the developer community and little love within it. GTK+ is supposed to be one of those "important" foundational components, and it's evidently maintained by an anti-social neckbeard who can't fake professionalism.

Suggesting that the user use an entirely new operating system, and all the trouble switching entails, suggests laziness to the highest degree, apathy to the problem, hatred of the spirit of the developer community, and it no doubt makes every one who reads this thread a little more anti-Linux and Open Source.
Comment 18 Tor Lillqvist 2010-03-22 08:54:54 UTC
I would post a witty reply if I wasn't too lazy.
Comment 19 Craig Harding 2010-04-03 00:11:32 UTC
So has anyone tried this quick fix (https://bugzilla.gnome.org/show_bug.cgi?id=537183#c13) from comment #13 above or Erik's patch (comment #7)?

Is there any other status on this bug?
Comment 20 Marcelo Aires Caetano 2010-04-03 02:04:06 UTC
about the proposed patch Erik van Pienbroek....
I already use a workaround on my programs using the same SetWindowLong to hide taskbar.
sometimes I need to do it 3 or more times to work.
look that I not using that patch, just a workaround.
maybe some function of gtk restores the SetWindowLong.

I'm commenting this just to help.

regards
Comment 21 Matthias Clasen 2018-02-10 03:35:50 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.