[QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

Scott Bloom scott at towel42.com
Thu May 24 02:26:03 BST 2018


Im just a user of the widget 😊  Though I am looking into the problem.  If I find a solution Ill forward it to Phil.

I honestly don’t know if here is a QScintilla bug tracker, as a commercial user of it, I just go direct to support 😊

From: cowwoc <cowwoc at bbs.darktech.org>
Sent: Wednesday, May 23, 2018 18:25
To: Scott Bloom <scott at towel42.com>; Phil Thompson <phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

Okay that's perfect.

Is it safe to assume that you guys will take care of this issue from here on in? Is there some bug tracker I can add a watch on?

Thanks,
Gili

On 2018-05-23 8:16 PM, Scott Bloom wrote:
To be a bit more explicit.

The QScintilla widget appears to be using the scaling factor of the “Primary” monitory, not necessarily monitor 1.

In my setup, I have 3, the laptop monitor + 2 externals (to the right of the laptop) so my primary is actually monitor #2

I confirmed that it only works correctly, on monitors whose scaling factor is the same as the primary monitor.

Scott
From: cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org>
Sent: Wednesday, May 23, 2018 17:11
To: Scott Bloom <scott at towel42.com><mailto:scott at towel42.com>; Phil Thompson <phil at riverbankcomputing.com><mailto:phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com<mailto:qscintilla at riverbankcomputing.com>
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

I think you nailed it.

I used to think that the problem had to do with launching the app on monitor 1 then dragging it into monitor 2 but I see now that no matter what I do the bug always occurs on monitor 2.

Here's the kicker: the scaling factor of monitor 2 is 100%. The scaling factor on monitor 1 is 150%. So it looks like the app is using the scaling factor of monitor 1 for the app running on monitor 2. Further, if TortoiseHg is open on monitor 2 and I change the scaling factor on monitor 1, I see the font of the app change on monitor 2 (which is unexpected).

Lastly, setting the scaling factor on monitor 1 to 100% fixing the caret issue on monitor 2.

Gili

On 2018-05-23 8:04 PM, Scott Bloom wrote:
Does the problem exist, in the tortoiseHG if opened on a scaled screen?

Scott

From: cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org>
Sent: Wednesday, May 23, 2018 17:03
To: Scott Bloom <scott at towel42.com><mailto:scott at towel42.com>; Phil Thompson <phil at riverbankcomputing.com><mailto:phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com<mailto:qscintilla at riverbankcomputing.com>
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

Hi Scott,

Thanks for reproducing the problem.

I tried digging into example-Qt4Qt5 but I know nothing about Qt and frankly was turned off not being able to find a pre-built version of qmake (even after installing the Qt SDK). Are you able to publish a pre-built executable of example-Qt4Qt5 for me to try out?

Thanks,
Gili

On 2018-05-23 6:40 PM, Scott Bloom wrote:
To duplicate under windows 10:

  1.  Setup two monitors, resolution doesn’t matter, however the Scale & layout option (windows 10), “Change the size of text, apps and other items” to 125% on one screen
  2.  Run the example-Qt4Qt5 app as shipped with the QScintilla core
  3.  In the screen with magnification, just type, you will see the visible cursor is NOT where it should be.

I have confirmed it doesn’t happen with SciTE

It doesn’t appear it has anything to do with moving, just having the window open on the scaled screen.

Gili, can you confirm that ?

Scott

From: cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org>
Sent: Wednesday, May 23, 2018 15:19
To: Scott Bloom <scott at towel42.com><mailto:scott at towel42.com>; Phil Thompson <phil at riverbankcomputing.com><mailto:phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com<mailto:qscintilla at riverbankcomputing.com>
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

Thanks Scott. As far as I can tell, this bug isn't 4k specific.

If I change my 1080p monitor to have the same scaling factor as the 4k monitor and drag TortoiseHg across the problem does not occur. The bug seems tied to different scaling factors, regardless of the monitor resolution.

Gili

On 2018-05-23 6:17 PM, Scott Bloom wrote:
I don’t have a 4k monitor, but I will try to play with it on a multimonitor PC and see if I can set the scaling factor on one screen and not the other (all three screens are the same resolution here)

There is not (that I know of) a QScintialla public test app

Scott

From: cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org>
Sent: Wednesday, May 23, 2018 15:15
To: Scott Bloom <scott at towel42.com><mailto:scott at towel42.com>; Phil Thompson <phil at riverbankcomputing.com><mailto:phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com<mailto:qscintilla at riverbankcomputing.com>
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

It just tested SciTE and it works fine.

Do you have an equivalent program that uses QScintilla?

PS: Using TortoiseHg, if I keep the application on the same monitor and change its scaling factor the bug does not occur. The bug only seems to occur when the application is dragged from one monitor to another. My guess is that when the application is sitting on one monitor and the scaling factor is changed, it receives and responds to an event. But when the application is dragged across monitors it does not recieve a scaling-specific event and as such it doesn't think to update the DPI accordingly. I would be surprised if this logic was TortoiseHg-specific (it seems like something that should be handled by the lower layers) but who knows...

Thanks,
Gili

On 2018-05-23 6:08 PM, Scott Bloom wrote:
Understood.

You may want to try SciTE.

That is a base editor, tied to the core Scintilla widget, not used QScintilla (which is a Qt wrapper for the core)

In reality, the TortoiseHg devs, need to work on this, to see if its their bug first..

This could be due to the 4k to HD resolution swap…

Scott

From: cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org>
Sent: Wednesday, May 23, 2018 15:06
To: Scott Bloom <scott at towel42.com><mailto:scott at towel42.com>; Phil Thompson <phil at riverbankcomputing.com><mailto:phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com<mailto:qscintilla at riverbankcomputing.com>
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

Hi Scott,

I'm not affiliated with TortoiseHg. I'm just an end-user. As such, I have no idea how to create a minimal testcase outside of TortoiseHg. When I filed a bug report at https://bitbucket.org/tortoisehg/thg/issues/5086/caret-position-is-incorrect-if-window I attached a video demonstrating the problem. Hopefully that'll help.

If you guys have a stand-alone application I could run, I can try reproducing the problem with it as well.

Thanks,
Gili

On 2018-05-23 4:45 PM, Scott Bloom wrote:
I have a PC with multiple monitors..

However, looking at the issue, there is no minimal testcase.  There is also nothing saying it’s a bug in Scintilla, QScintilla or tortoisehg.  It could be any of the three.

Why is the assumption being made that its QScintilla?

Scott

From: QScintilla <qscintilla-bounces at riverbankcomputing.com><mailto:qscintilla-bounces at riverbankcomputing.com> On Behalf Of cowwoc
Sent: Wednesday, May 23, 2018 13:42
To: Phil Thompson <phil at riverbankcomputing.com><mailto:phil at riverbankcomputing.com>
Cc: qscintilla at riverbankcomputing.com<mailto:qscintilla at riverbankcomputing.com>
Subject: Re: [QScintilla] Bug report: Caret position is incorrect if window dragged across monitors

On 2018-05-23 11:09 AM, Phil Thompson wrote:

On 23 May 2018, at 3:01 pm, cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org> wrote:



On 2018-05-23 8:46 AM, Phil Thompson wrote:

On 22 May 2018, at 3:48 am, cowwoc <cowwoc at bbs.darktech.org><mailto:cowwoc at bbs.darktech.org> wrote:

Sorry, I forgot to include the bug report: https://bitbucket.org/tortoisehg/thg/issues/5086/caret-position-is-incorrect-if-window



Thank you,

Gili



On 2018-05-21 9:13 PM, cowwoc wrote:

Hi,



Can someone please take a look at this bug report which seems to affect your project?

Sorry, I don't have the equipment needed to reproduce the problem.



Phil



Hi Phil,



Which equipment are you missing? A video card with 2 ports? 2 monitors? Or a copy of Windows?



...and a PC.



Phil

Fortunately for you, that's not a problem :) Assuming you have a Mac laptop:

  1.  Plug in a second monitor (any will do) so your laptop sees multiple monitors.
  2.  Fire up a virtual machine of your choosing. I used VMWare Workstation, which is equivalent to VMWare Fusion on Mac. I believe VirtualBox (which is free) will work just as well.
  3.  Download and install the Windows 10 ISO which you can download for free from https://www.microsoft.com/en-ca/software-download/windows10
  4.  You can run Windows 10 without a license for a short period of time (30 days I believe) so this isn't a problem.
  5.  Configure the VM with 2 virtual monitors and you should be able to reproduce the problem.
  6.  I just tried it in VMWare Workstation and it worked for me.

I haven't been able to get this working (yet) using a single physical monitor. See https://superuser.com/questions/1325393/how-to-use-multiple-virtual-monitors-if-host-has-a-single-monitor

But it's possible that VirtualBox is better in this regard than VMWare Workstation.

Gili












-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/qscintilla/attachments/20180524/5de5a147/attachment-0001.html>


More information about the QScintilla mailing list