mudlet-makers team mailing list archive

[Stephen Lyons <798489@xxxxxxxxxxxxxxxxxx>]

>From the description on that link it sounds like "Many applications have
this bug; it's pretty common." is a short-cut for "Many applications are
not properly designed to work on a virtual desktop where multiple
physical screens are each mapped to cover parts of a declared range but
where there may be portions of that virtual desktop that are not
displayable on any of the display devices."

I use such a set-up - I have a virtual desktop of size 1680 x 1818made
from a 1680x1050 external monitor over a 1024x768 laptop display. (The
maximum the accelerated graphics chipset supports is 2048x2048 - so I
can't put the two screen side by side!)

Qt's QDesktop instance that QApplication::desktop() returns has width()
and height() which reflect the virtual dimensions but, and I quote:
"QDesktopWidget also inherits the QWidget properties, width() and
height(), which specify the size of the desktop. However, for desktops
with multiple screens, the size of the desktop is the union of all the
screen sizes, so width() and height() should not be used for computing
the size of a widget to be placed on one of the screens."

However this situation can be detected: "On systems that are configured
to use the available screens as a single, large virtual desktop, the
virtualDesktop property will be set to true. In this case, the widget's
size is usually the size of the bounding rectangle of all the screens."

This is all explained in the documentation for "Qt Widgets 5.x" >
"QDesktopWidget Class" which goes on to explain how to position widgets
in a user friendly way (by using a single screen - the primary one
unless the user overrides it and taking steps to detect a screen(s)
configuration change and to respond to:
QDesktopWidget::screenCountChanged(int newScreenCount) and
QDesktopWidget::​workAreaResized(int screen)

as well as:
QDesktopWidget::​resized(int screen)

tl;dr:
At present I think we only respond to the latter and we disregard the
screen parameter - which we treat as if it is always -1 (the default
screen meaning the virtual desktop if there is one.)

I think we may need to track a few more details about the Desktop setup
in the QSettings we store: besides the Application and the Editors' size
and location we may have to keep a watch on the screen that each widget
is on {so we know to redo the layout if the number of screens change -
monitor gets connected/disconnected} and also make a more intelligent
use of the resizing signals {so we resize/re-layout those primary
widgets if the screen they *are* *on* gets resized.}

I guess the current issues may also arise if some of the Qt layout code
is also guilty of using the virtual desktop size when it should be using
relevant screen size or visa-versa...

Stephen (via Email)

On 04/02/15 17:25, Andy Walker wrote:
> Many applications have this bug; it's pretty common. Until a workaround
> is found, I've found a free tool that solves this issue in most cases:
> http://bring-em-back.com
>

-- 
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/798489

Title:
  Main window retains out of range location on screen on OSX

Status in Mudlet the MUD client:
  New

Bug description:
  2.0rc8 (and previous versions).

  If you've been using a dual monitor setup and switch to single,
  Mudlet's com.mudlet.Mudlet 1.0.plist file will retain the window
  location at a value that is off the screen. There is no way to make
  Mudlet visibile except to close Mudlet, delete the .plist file, and
  reopen.

  OS X 10.6.7

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/798489/+subscriptions