https://bugs.winehq.org/show_bug.cgi?id=46502
Bug ID: 46502 Summary: Windows events WM_ENTERSIZEMOVE, WM_EXITSIZEMOVE are not sent Product: Wine Version: 4.0-rc7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: reinhold.hoffmann@hotmail.com Distribution: ---
When moving a Windows dialog around the Windows notifications messages
WM_ENTERSIZEMOVE https://docs.microsoft.com/en-us/windows/desktop/winmsg/wm-entersizemove
WM_EXITSIZEMOVE message https://docs.microsoft.com/en-us/windows/desktop/winmsg/wm-exitsizemove
are not sent.
In Wine 2.0 these messages were sent but in Wine 4.0-rc7 not anymore. Therefore it looks like that this is a regression bug.
Unfortubnately I cannot say with which version this bug came in.
Sorry, that I have not found this bug ealier.
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #1 from Reinhold reinhold.hoffmann@hotmail.com --- Created attachment 63353 --> https://bugs.winehq.org/attachment.cgi?id=63353 Demo for the bug
Please find in the attachment the following files to demonstrate the bug
"Test.exe" to demonstrate the issue "Test_demo_ENTER_EXIT_SIZE_MOVE.png" how to demonstrate the bug "Test_source_code.zip" the source code of Test.exe created with VS2010
Please see the source code of OptionsDlg.cpp. Those two messages are not received.
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- You need to unset "allow the window manager to decorate windows" to allow Wine to receive the events. If you do that, the messages are sent properly as far as I can see.
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #3 from Reinhold reinhold.hoffmann@hotmail.com --- Thanks for the immediate response.
Yes, with this option the events are received.
But honestly, our applications looks totally different now and more like old days Windows 95/XP applications rather than a modern user friendly apps which users have been used to for quite some time. From a user's perspective using this option is a big step backwards and cannot be recommended.
I do not understand why this was changed and that these two events were connected to the option "UN-allow the window manager to decorate windows" now with Wine 4.0.
To me this is a big step backwards.
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #4 from Reinhold reinhold.hoffmann@hotmail.com --- The question is whether "Un-allow the window manager to decorate windows" is the final solution or just a temporary workaround.
For a temporary workaround this is OK.
For a final solution it would limit apps which use these messages to the "old fashioned" windows design which IMHO would not be a good decision. That needs to be clarifed.
Thx
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- (In reply to Reinhold from comment #3)
Thanks for the immediate response.
Yes, with this option the events are received.
But honestly, our applications looks totally different now and more like old days Windows 95/XP applications rather than a modern user friendly apps which users have been used to for quite some time. From a user's perspective using this option is a big step backwards and cannot be recommended.
I do not understand why this was changed and that these two events were connected to the option "UN-allow the window manager to decorate windows" now with Wine 4.0.
To me this is a big step backwards.
Nothing was changed, the behavior has always been like that.
If the window manager is in charge of moving the window, we don't get notified when moving starts, so there's no way for us to send a WM_ENTERSIZEMOVE.
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #6 from Reinhold reinhold.hoffmann@hotmail.com --- Again, thank you very much for your immediate response.
Quite frankly I am not an expert what Wine does and what a windows manager does and what the load sharing between both instances is.
Your response basically says that the behaviour of the message flow for these two messages is different for different windows managers. E.g. Gnome for Ubuntu (now in Ubuntu 18.04) behaves differently than the "Windows" window manager (not sure if this is the correct word for un-opting "allow the window manager to decorate windows") or other windows managers e.g. KDE or e.g. Winebottler's window manager on a Mac (works nicely here). This different behaviour impacts up to the app. This means that a Microsoft Windows app needs to deal with the behaviour of the different windows managers unless the option "allow the window manager to decorate windows" is unset.
This is new to me but I am still learning :-).
https://bugs.winehq.org/show_bug.cgi?id=46502
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- On Windows, an app can intercept and control most of the window manager's behavior through messages. Under X11 the window manager is in charge, and the app is expected to cope with its decisions. The app can set hints to influence the WM behavior, but it cannot enforce anything.
If your app requires control over the window management, you'll most likely want to rethink the user interaction to make it work correctly under X11. There's simply no way to get the same level of control that you can get under Windows.
https://bugs.winehq.org/show_bug.cgi?id=46502
--- Comment #8 from Reinhold reinhold.hoffmann@hotmail.com --- Let me finally share my experience of the work associated with this report here.
The key finding is that our Windows apps are not only dependant on Wine but also on the window management of the running platform.
For Linux it is X11 and for other OS there are different window managements (e.g. Mac). Because our main platform is Windows, porting our software to Wine (e.g. for Linux or Mac) the software needs to be tweaked with regards to the window managent software of the underlying platform, too. If tests are OK, fine, but if on a per platform base something needs to be changed the app needs to know the underlying host system and need to make according decisions.
With this in mind I was able to find a reasonable solution for our apps for those missing events here.
In particular I would like to thank you, Alexandre for your patience and support here and the great work on Wine.
That said, our next target platform will be Android. In this context I would like to refer to report #46037 (https://bugs.winehq.org/show_bug.cgi?id=46037). Given the findings here and some early experiences with Android I believe #46037 will be essential for us (one example is to use different audio buffer sizes for Android for audio playback).
Thanks
Reinhold
https://bugs.winehq.org/show_bug.cgi?id=46502
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org