New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting non-default scaling factor in gnome/windows messes up Scintilla #162

Naatan opened this Issue Apr 13, 2015 · 14 comments


None yet
7 participants

Naatan commented Apr 13, 2015

In gnome tweak tool I set my font scaling factor to 0.9, then I put my cursor on some text in Komodo and right click it, my selection will change to a line (or more) above.

@toddw-as any pointers?

@Naatan Naatan added the Type: Bug label Apr 13, 2015

@Naatan Naatan added this to the Backlog milestone Apr 13, 2015

@Naatan Naatan modified the milestones: 9.1.1, Backlog May 15, 2015

@Naatan Naatan modified the milestones: 9.1.1, 9.2 Jun 23, 2015


This comment has been minimized.


mitchell-as commented Jun 29, 2015

Scintilla is unaware that any font scaling is going on because its internal styles are not being updated. I suspect Gnome Tweak is doing some trickery behind the scenes to make Pango draw fonts larger than they actually are. Scintilla is completely oblivious to this and still thinks the font size is the same as when the style was last loaded. There is no fix for this.


This comment has been minimized.


Naatan commented Jun 30, 2015

Unfortunately this is becoming more common and it's not something we can ignore. Whether Scintilla is aware of it or not; it is affected. We might have to patch Scintilla to have the awareness it needs, or provide a bandaid solution for the "effect" of the problem (the offset issue described).

@Naatan Naatan modified the milestones: Backlog, 9.2 Jun 30, 2015


This comment has been minimized.


mook-as commented Jun 30, 2015

We do attempt to obey DPI settings on GTK; it would be useful to check if we're missing some of the logic there. (Possibly hook up something to redo the value, similar to what happens on Windows.)


This comment has been minimized.

ervumlens commented Aug 1, 2015

I'm running into this problem, FWIW. Right-clicks moving me one line down and a few characters to the right. It only happens to me with the OpenBox window manager. Cinnamon and Xfce work fine.

I don't recall doing any tweaking other than to change themes (none of which seem to affect this problem for better or worse). OpenBox doesn't appear to use the settings in gnome-tweak-tool so I don't have a useful number to share here.

I haven't done enough right-clicking to notice the problem until now, but man it's a hard problem to work around when I need that click!


This comment has been minimized.

ervumlens commented Aug 2, 2015

Some observations (FYI, I'm linking to "contrib/" code but talking about "src/" code):

  1. Left-click and middle-click always work as expected.
  2. The context menu itself is placed correctly.
  3. All the values in ScintillaGTK::PressThis look fine for event->button == 3. Specifically, the values related to changing the selection are correct. This means what I see on the screen is not coming from these values (although maybe it should).

Since everything looked fine event-wise down at the Scintilla level, I figured the problem was further along the message chain.

To see if this was the case, I changed the right-click code's return FALSE to return TRUE. This would in theory stop the right-click message from propagating and instead use the correct values already calculated in ScintillaGTK. Magically the right-click worked as expected in OpenBox. Cinnamon and Xfce continued to work as expected. Change the code back and the problem in OpenBox returned. (I rebuilt and retested the code in both states many times, just to be sure it wasn't actually magic.)

I don't know what handles the button-press event after ScintillaGTK, but right now I'm blaming it for the problem.

@Naatan, my symptoms are similar to yours but I don't know if my underlying bug is the same. When you have time ("ha ha," right?), could you try building Komodo with the change I mentioned to see if it has any impact? If that doesn't help you, I'll move my problem to a new issue.


This comment has been minimized.

ervumlens commented Aug 2, 2015

I don't know if my underlying bug is the same...

Now I think it's the same.

Font scaling breaks Komodo in Cinnamon for me, just as @Naatan described. Like OpenBox, Cinnamon is not using values from gnome-tweak-tool, but Cinnamon does have its own font tweaking thing that includes font scaling.

The patch/hack/proof-of-concept I made above fixes the font scaling problem here in Cinnamon. I'm hoping it's just a matter of walking through the rest of the message chain to find the problem, although it sounds kind of miserable.

In case you didn't notice already, the problem is worse as you right-click down the screen and as more lines are visible. The lines near the top of the screen aren't bad, but zoom out and right-click near the bottom and you're zipped up a bunch of lines — or zipped down, if you're in OpenBox.


This comment has been minimized.


Naatan commented Aug 5, 2015

Very helpful @ervumlens, thank you so much! We'll be sure to look into this for one of our next releases.

@Naatan Naatan modified the milestones: 9.3, Backlog Aug 5, 2015


This comment has been minimized.

ervumlens commented Aug 5, 2015

"If the women don't find you handsome, they should at least find you handy." 💪:neckbeard:

More observations:
4. Left-click is affected when attempting to drag-and-drop a selection. This operation fails where ever the right-click would jump lines. I only know this because...
5. I saw it in the xul:scintilla code, next to bum bum BUM! the code that's goofing up the right-click! But xul:scintilla is merely a pawn for something more sinister, namely...
6. The scimoz_wrapper! It wraps scimoz in lies! ... Okay, so Mook-as already said the problem was probably around the logPixels code. BUT! Remember I mentioned the values in ScintillaGTK always looked good no matter what the font-scale setting? It turns out scimoz_wrapper is double dipping! ScintillaGTK is already accounting for the font scaling. When scimoz_wrapper passes pre-scaled numbers to Scintilla, the results are overscaled!

Changing the font scale changes the values of logPixelsX and logPixelsY. But why does it usually work out okay in Linux? Because pre-scaling by 1 (96 logical pixels / 96 DPI) never overscales! scimoz_wrapper is an evil, twisted genius!

The new patch/hack/proof-of-concept. Replace this code in scimoz_wrapper.template.js (or, as I did, change the live scimoz_wrapper.js version under "mozilla/build/" if you don't want to rebuild anything) ...

koSciMozWrapper.prototype.positionFromPoint = function(x, y) {
    return this.__scimoz.positionFromPoint(parseInt(x * this.logPixelsX / kDefaultDPI),
                                           parseInt(y * this.logPixelsY / kDefaultDPI));

... with this...

koSciMozWrapper.prototype.positionFromPoint = function(x, y) {
    return this.__scimoz.positionFromPoint(x, y);

Now the wrapped scimoz scales the values itself, using some unknown process. I suspect Pango trickery here, as mitchell-as suggested.

This probably raises more questions than it answers, but I hope it helps narrow things down.


This comment has been minimized.

ervumlens commented Aug 11, 2015

FYI, font scaling also affects the position of the auto-complete pop-up.

Font scale = 1.1
small - autocomplete - 1 1

Font scale = 1.0 (normal)
small - autocomplete - 1 0

Font scale = 0.9
small - autocomplete - 0 9


This comment has been minimized.

arnoldbird commented Sep 17, 2015

Like ervumlens, I also was seeing the auto-complete popups misalligned. Fixed by installing unity-tweak-tool and going to Fonts and clicking Restore Defaults. This caused a lot of new spaces and tabs (I think) to be added to my open komodo docs. However, when I closed komodo, and re-opened, that problem was gone. I could then adjust the font size in the "color scheme" preferences in komodo, and all's well. I'm using Ubuntu 15.04.

@mitchell-as mitchell-as modified the milestones: 9.3.1, 9.3 Oct 5, 2015

@Naatan Naatan modified the milestones: 9.3.1, 9.4 Nov 4, 2015

@Naatan Naatan modified the milestones: 9.4, 10.0 Nov 13, 2015

@Naatan Naatan changed the title from Setting non-default scaling factor in gnome messes up Scintilla to Setting non-default scaling factor in gnome/windows messes up Scintilla Jan 11, 2016


This comment has been minimized.


mitchell-as commented Mar 14, 2016

Can anyone with a HiDPI screen on Linux verify the patch above works? You can test this on your current Komodo installation by searching for a file called "scimoz_wrapper.js" and modifying it. (Please make a backup first!) You just need to wrap that chunk of code in the test for non-Linux platforms.


This comment has been minimized.


Defman21 commented Apr 1, 2016

I'm not owning a HiDPI screen but I'm on Linux and this patch fixes autocomplete popup positioning for me when I'm using a non-standard FSF (Font Scaling Factor).


This comment has been minimized.

bjmc commented Mar 29, 2017

I see this issue is closed, is there a good fix or workaround for this problem? Has the patch mentioned above been incorporated into a Komodo release? I'm still experiencing this with,

Komodo Edit, version 10.2.1, build 17670, platform linux-x86_64.
Built on Wed Mar 8 20:13:03 2017."

on Ubuntu 16.04 running the Gnome desktop environment on a HiDPI screen.

Here's an example of the problem in action, as you can see the autocomplete popup is displaced away from the line of active text:

screenshot from 2017-03-29 13-39-59


This comment has been minimized.


Naatan commented Mar 29, 2017

Could you open a new bug report and share your OS settings please? (anything related to resolution, HiDPI and font size).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment