the suspicious change seems to be this one:

$ diff qmmp-1.1.7/src/plugins/Ui/skinned/mainwindow.cpp qmmp-1.1.10/src/plugins/Ui/skinned/mainwindow.cpp
2c2
<  *   Copyright (C) 2006-2016 by Ilya Kotov                                 *
---
>  *   Copyright (C) 2006-2017 by Ilya Kotov                                 *
24a25
> #include <QDesktopWidget>
284c285,294
<         move(settings.value("mw_pos", QPoint(100, 100)).toPoint()); //geometry
---
>         QDesktopWidget *desktop = qApp->desktop();
>         QPoint pos = settings.value("mw_pos", QPoint(100, 100)).toPoint();
>         if(!desktop->availableGeometry().contains(pos))
>         {
>             QRect availableGeometry = desktop->availableGeometry();
>             int r = m_skin->ratio();
>             pos.setX(qBound(availableGeometry.left(), pos.x(), availableGeometry.right() - r*275));
>             pos.setY(qBound(availableGeometry.top(), pos.y(), availableGeometry.bottom() - r*116));
>         }
>         move(pos); //geometry


I've tried to comment out the new code to see if it makes difference

scratch build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=27629785

please install and test the experimental package:
https://kojipkgs.fedoraproject.org//work/tasks/9789/27629789/qmmp-1.1.10-2.fc27.x86_64.rpm


also please specify which desktop/windowmanager do you use?

Created attachment 1451829 [details]
Desktop showing geometry, sizes and positions

it fixed it partly as you can see :)

the main window is now back to it's original position, but the others not. Same changes required i assume. 

All windows are below/above each other and adjected/sticked together.

Desktop is Cinnamon latest as of FC27. You can take the screensize and geometries from the picture, which illustrates the problem good. Maybe it even shows why the new routine fails miserable :)

BTW: when your finished and found out what was the problem, PLEASE let the devs of LIFEREA and Thunderbird know about it. 

Their windows have the same positioning bug ( only them ) 

Liferea starts on the right display, Thunderbird on the left, where it should be vice versa :D

(In reply to customercare from comment #3)
> it fixed it partly as you can see :)
> 
> the main window is now back to it's original position, but the others not.
> Same changes required i assume. 

yep, silly me, the same in eqwidget.cpp and playlist.cpp

but I cannot see anything obviously wrong with the code, so let's call Muffin maintainer for help ...

Leigh, please, do you have any idea why the check

if(!desktop->availableGeometry().contains(pos))

could fail in the first place?

(I suspect the problem is not in qmmp/Qt if Thunderbird is also affected ...)

it seems to be a  "major" implementation problem to solve the repositioning problem on two or more displays. (working fine for just one hehehe :) )

FireFox i.e. opens itself anywhere, where the mousepointer is. So moving the mouispointer to where you want firefox to open, solves their problem :)

unfortunatly, it doesn't work for liferea and thunderbird :(

Does the issue reproduce with muffin-3.8, you will need to use my copr to test.

https://copr.fedorainfracloud.org/coprs/leigh123linux/cinnamon/


@miketwebster Is this a known issue as it doesn't appear to be reported against muffin.

https://github.com/linuxmint/muffin/issues

I have two monitors.  The app saves and restores its position correctly if it's closed while on the primary (regardless of whether my primary is left or right.)

If I position it on a secondary monitor, it restores itself in the vertical position (because my monitors are horizontally arranged) but is at the extreme edge of the primary.

>>> x = QApplication([])
qt5ct: using qt5ct plugin
>>> inotify_add_watch("/home/mtwebster/.config/qt5ct") failed: "No such file or directory"
x.desktop()
<PyQt5.QtWidgets.QDesktopWidget object at 0x7f59cd268f78>
>>> x.desktop().availableGeometry()
PyQt5.QtCore.QRect(1680, 27, 1920, 996)
>>> x.desktop().screenGeometry()
PyQt5.QtCore.QRect(1680, 0, 1920, 1080)
>>>

This is showing only my primary monitor as available (and screen) geometry.  I haven't dug into what Qt looks for to determine sizes.

This behavior can be reproduced in cinnamon, gnome-shell, and (just the wm) kwin.

The python results are reproduced likewise.  Comparing `xprop -root` results between muffin/mutter-managed and kwin-managed screens doesn't show much difference, at least with NET_WORKAREA, NET_DESKTOP_GEOMETRY.

If it were up to me, I'd just remove those checks in the various places they occur.  Why was it needed?  How many people will it help vs how many more people it will just 'work' on without those.  This area of the desktop can be really really messy and inconsistent, regardless of how its implemented.  Window managers (at least any I've looked at) already have sanity-checking for windows placed out-of-view.  99% of users would, I imagine, never be screwing with their setup or monitor layout, etc... so how often would this even be necessary?

I think this issue is unrelated to thunderbird - thunderbird/firefox do a lot of custom things (since they're multiplatform, and need to abstract a lot more of this stuff,) and while I don't doubt there may be some issue with them, they use Gtk.

(In reply to Michael Webster from comment #8)
...
> This is showing only my primary monitor as available (and screen) geometry. 
> I haven't dug into what Qt looks for to determine sizes.
> 
> This behavior can be reproduced in cinnamon, gnome-shell, and (just the wm)
> kwin.

so, it looks more like a Qt bug if I get it right?

> Why was it needed?
...
> 99% of users would, I imagine, never be screwing with their setup or monitor layout

it happens to me all the time that after undocking my laptop, things appear out of the display panel, so probably the original motivation was something like that ... however, I agree that's problem of the underlaying graphics system and not the application

Ah these are unmanaged/undecorated windows probably. So the wm wouldn’t attempt to correct their position.  I would call it a qt bug or maybe incomplete configuration, but I’m really not familiar with qt lore.  What if the monitor count was saved and this repositioning code was only run when the count differed from the previous session?  This would cover the laptop case at least?

"What if the monitor count was saved and this repositioning code was only run when the count differed from the previous session?"

can be ruled out, i didn't change my displays for months now :)

I’m suggesting that as a way to fix the issue. Or at least work around the current one. Essentially this code would never run unless the previous run’s monitor count was not the same as the current one’s.

Nevermind...nothing's broken - in Qt a "screen" is a monitor apparently (I'm used to it being something very different in gtk).

Instead of checking desktop().availableGeometry(), this code should get the number of 'screens' (desktop.screenCount), iterate over the result and use the overloaded desktop.availableGeometry(monitor_num) to check the saved geometry against each screen's geometry in turn.

If I can get this to build I'd try to make a patch.

(In reply to Michael Webster from comment #13)
> If I can get this to build

is there any problem?

> I'd try to make a patch.

that'd be marvellous, as I don't understand those things and don't have the time (nor even energy) to study screens handling in Qt ...

while commenting out the new check might be a way to go, I'd rather see this fixed properly ...

reported upstream as https://sourceforge.net/p/qmmp-dev/tickets/971/

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

https://src.fedoraproject.org/rpms/qmmp/c/745a5fb3bc18c02e2cc591dcda42ac058f5c36c7?branch=master

https://koji.fedoraproject.org/koji/taskinfo?taskID=29976689