Preface: I understand all too well that XMPlay was never made to be used under POSIX enviroment and I am not asking to port it to Linux, however I do ponder if it's about time we thought of some kind of solution to the issue at hand, given somewhat growing Linux userbase these days. And I've been personally using XMPlay under wine for well over 10 years, so I have some amount of personal interest in the issue.
That being said, I'd like to document this issue to uttermost of my ability, so perhaps it will be possible to provide some kind of fix.
So, there seem 2 separate but close issues:
1. For skins that use sliding panels OR overlapping elements, these elements are rendered in the order their sub-windows regardless of their intending Z-order. Moreover clicking on these items bring them to top regardless (see attachment 1). Also, when moving main window it can be seen that sub-elements lag behind the main window a bit.
2. For not yet completely understood reason when moving XMPlay window, its sub-elements (including extended playlist/info window) begin to fly around screen as if trying to keep up with main window (they seem to follow the direction of moving main window, but when they reach its position the main window jumps again in the same direction it was moved it). This is a thing that begins and ends abruptly, so restarting a player does not help.
Now, I believe both issues are closely related to how X11 server manages its window objects, how Wine translates that to and from WinAPI, and finally how sub-element movement and position is implemented in XMPlay itself.
For issue "1" I didn't manage to find a workaround: It persist regardless of window manager, decorations or virtual desktop enabled. It might just be something hardcoded into Wine, OR XMPlay manipulates sub-item z-order on the fly, which just so happen to be edge case and fail to work in timely fashion under Wine/X11.
For issue "2" there is workaround: you disable window manager control over wine completely, and then issue disappears. This is however not the best workaround as now the window does not behave together with system being always on top, not visible to task panel (so tray icon must be enabled to not lose window) and being immovable with shortcuts/Alt-drag.
So the issue 2 is closely related to when sub-element position is updated, because this is accounted for by window managers as they, maybe, try to restore element position if it's updated too quickly and perhaps causing a race condition which also manifests only from time to time. I can confirm this with openbox and xfwm window managers with their base configurations, I've also seen similar reports from people using KDE and Gnome desktops.
Given this,
1. How feasible it is to "flatten" the player GUI, so only single player window and info windows are created? This basically means interface is rendered synchronously in software in known order, and z-order issue is thus eliminated.
2. How problematic is it to somehow monitor sub-window positions updated outside xmplay, thus perhaps locking position update until that value is unchanged? I wonder if perhaps XMPlay monitors and overwries window position attributes even if it should not generally? I can observe that forcibly moving e.g. track title element by dragging in with ALT pressed, causes other elements and the main window to be moved along as well.
