http://bugs.winehq.org/show_bug.cgi?id=26670
Summary: Atlantis Word Processor window does not appear in task bar Product: Wine Version: 1.3.17 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: ld0d@kolumbus.fi
The Atlantis Word Processor works otherwise perfectly, but the main window does not appear on the Ubuntu/Gnome taskbar panel nor in the alt-tab quick switch list. If the system is configured to only have one virtual desktop, there is no way to access the window if it gets hidden by another window. With multiple virtual desktops in use, the taskbar "button" for Atlantis gets wrongly placed on the *second* virtual desktop, while the window itself opens on the first one as expected.
I'm using Ubuntu 10.10 amd64 with wine 1.3.17 from the WineHQ PPA Repository. The program itself is a 32-bit Windows executable. I have also tried this with the Ubuntu wine1.2 package, but it has the same problem.
A demo can be downloaded here: http://www.atlantiswordprocessor.com/en/downloads.htm
http://bugs.winehq.org/show_bug.cgi?id=26670
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.atlantiswordproc | |essor.com/en/downloads.htm
http://bugs.winehq.org/show_bug.cgi?id=26670
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-14 04:14:58 CDT --- The following commit is the source of the problem:
commit 61e50e15ba45ad54655f98619f5ef33917033165 Author: Alexandre Julliard julliard@winehq.org Date: Fri May 28 12:14:43 2010 +0200
winex11: Map zero-size windows and set an empty window region for them.
http://bugs.winehq.org/show_bug.cgi?id=26670
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration, regression Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from Ken Sharp kennybobs@o2.co.uk 2011-04-14 06:50:44 CDT --- Confirming as per comment 1.
http://bugs.winehq.org/show_bug.cgi?id=26670
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv
http://bugs.winehq.org/show_bug.cgi?id=26670
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-15 03:21:31 CDT --- Created an attachment (id=34121) --> (http://bugs.winehq.org/attachment.cgi?id=34121) Revert a part of 61e50e15ba45ad54655f98619f5ef33917033165
Attached patch reverts a small part of 61e50e15ba45ad54655f98619f5ef33917033165 and makes the Atlatis' window appear again on a taskbar. But pressing the app's button on a taskbar (leading to minimization of its main window) makes another window (hidden owner of a Delphi main form) appear on the taskbar.
http://bugs.winehq.org/show_bug.cgi?id=26670
Jarek jarekczek@poczta.onet.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jarekczek@poczta.onet.pl
--- Comment #4 from Jarek jarekczek@poczta.onet.pl 2011-07-04 09:04:17 CDT --- (In reply to comment #3)
Created an attachment (id=34121)
--> (http://bugs.winehq.org/attachment.cgi?id=34121) [details]
Revert a part of 61e50e15ba45ad54655f98619f5ef33917033165
I wouldn't call the fun get_window_owner, because it is really get_window_owner_with_non_zero_size, so the name can be misleading. Maybe get_window_owner_nzs?
But generally this doesn't lead to a sure solution compatible with windows behaviour.
This bug is strictly connected with [url=http://bugs.winehq.org/show_bug.cgi?id=27190%5Dbug 27190[/url]. Delphi app with a hidden window.
I think I managed to reach the core of these problems. I attach a simple winapi (source and exe) which creates 3 windows, called 0, 1, 2. The owner of 2 is 1. All are normal overlapped windows.
On the taskbar there are constantly 2 windows: 0 and 1 (never 2!).
Pressing Alt-tab shows 2 windows: constantly 0 and 1 or 2. Which one of the 2 latter is shown depends on which was the last active. Let's consider a complicated sequence: 1. activate 1 2. activate 2 3. activate 0 4. activate another app After it alt-tab allows to switch between 0 or 2.
This behaviour is reasonable. But how does the system know which was the last active window of the owned bunch 1,2? GetTopWindow - always 0 GetPreviousWindow/GetNextWindow - 2 always previous to 1 GetActiveWindow - points to window "0", as this is an active window for this thread. (I checked they all belong to the same thread. Didn't check the active window, guessing here).
I guess native window manager keeps a variable last_active_of_a_bunch for all windows without owner. But maybe you have a better explanation. Implementing such a variable (updateable at set_active_window) would solve the problem. Plus ability to control window manager and make it show different windows on taskbar and different on alt-tab panel.
My example points that zero size of a window has nothing to do with the problem.
http://bugs.winehq.org/show_bug.cgi?id=26670
--- Comment #5 from Jarek jarekczek@poczta.onet.pl 2011-07-04 09:05:56 CDT --- Created an attachment (id=35429) --> (http://bugs.winehq.org/attachment.cgi?id=35429) sample app for owned windows
http://bugs.winehq.org/show_bug.cgi?id=26670
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |61e50e15ba45ad54655f98619f5 | |ef33917033165
http://bugs.winehq.org/show_bug.cgi?id=26670
Patrick Saalfeld suntrix.patrick@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |suntrix.patrick@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=26670
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |4f0f7dec9927eba84a98acd63b2 | |2f1d843d672fc Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2012-01-31 14:08:24 CST --- Fixed by 4f0f7dec9927eba84a98acd63b22f1d843d672fc.
http://bugs.winehq.org/show_bug.cgi?id=26670
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2012-02-02 13:37:53 CST --- Closing bugs fixed in 1.4-rc2.
-
wine-bugs＠winehq.org