A bold issue with Qt

[newbthenewbd]

So, there's this really nice font (RIP Vernon Adams): https://github.com/KDE/oxygen-fonts/blob/master/oxygen-fonts/mono-400/OxygenMono-Regular.ttf

And with the Qt version, making it bold does nothing :(

Could it be something with how TTF's are handled? Probably unrelated, but opening a quite large, accidentally quite related >200KB HTML file[^1] makes this pop up in the executing terminal: OpenType support missing for "Oxygen Mono", script 11

[^1]: The length of the name of which also exposed some weird behavior with tab scrolling - it always acts as if it was scrolled to the very left... Not really sure where this gets in the scope of upstream Qt problems, and flooding the repo with random brief reports isn't my intention either, but technically this affects the ease of use quite a bit so :)

[orbitalquark]

Sorry, I'm pretty unfamiliar with how Scintilla (and platforms like Qt) handle fonts. I don't have any idea why this is happening.

As for long filenames in tabs, are you expecting right-justified vs. left-justified? I was under the impression that left-justified is more desirable for identification. Or am I misunderstanding the issue?

[newbthenewbd]

As for long filenames in tabs, are you expecting right-justified vs. left-justified? I was under the impression that left-justified is more desirable for identification. Or am I misunderstanding the issue?

Yeah well, the gif probably explains it better than me :) Clicking the tab to the right zooms it into view, so now "it's scrolled to the very right", but then, clicking just outside the tab, to its left, doesn't switch to the expected neighbor tab, but another one farther away - the one, it seems, that stands right there when "it's scrolled to the very left"...

Thank you for such swift responses! I don't know everything about Qt either, but looks like now I'm gonna get a bit more familiar, with how easy CMake makes rebuilding the editor :)

[newbthenewbd]

The tab issue also happens with simply a ton of short-named tabs, as if something didn't update the position for the however-it's-called clicked tab calculator :)

[orbitalquark]

Oh, I didn't realize it was a gif (I typically read issues over e-mail). That looks like Qt-specific behavior. I'm not sure what to make of it (bug or not).

[newbthenewbd]

Hmm. Added printf("%d\n", index); to the QTabBar::tabBarClicked handler, it seemed correct, printed 11, but the tab that popped up at the same time was 1...

[newbthenewbd]

Err, or zero, I guess. Lua is messing me up too fast :)

[newbthenewbd]

It seems that it's QTabBar::currentChanged sending the wrong values.

[newbthenewbd]

Just for the record it's more than that, somehow the tab indices are all over the place in desync :(

Another annoyance of a gif follows, maybe kinda proving that this ain't right...

[newbthenewbd]

Some printf galore in an otherwise unmodified (I hope) variant...

CLICK!
tabBarClicked 7
sync_tabbar calls set_tab with 7
set_tab called with 7
currentChanged 1
sync_tabbar calls set_tab with 1
set_tab called with 1

Now, what makes it seem to "work" right, and look like this:

CLICK!
tabBarClicked 19
currentChanged 19
sync_tabbar calls set_tab with 19
set_tab called with 19

...is removing this line?!?

emit("tab_clicked", LUA_TNUMBER, index + 1, LUA_TNUMBER, button, LUA_TNUMBER, modifiers, -1);

[orbitalquark]

Thanks for attempting to debug this. I discovered that Qt emits tabBarClicked before potentially changing the current tab index (which emits currentChanged). Since Textadept always changes the current tab index if a tab is clicked (potentially causing a scroll), Qt's mouse click handler is not aware of the change and thinks a different tab was clicked. I've fixed this in https://github.com/orbitalquark/textadept/commit/e44373b5ed0e826547215c965962b22fbed2d53c

[newbthenewbd]

..Wow. Got to the tab setter calling a tab setter, here assumed it's corrupting some arcane internals or simply the stack, gave up, took a break, and now return to see it not only fixed, but explained plainly? This is.. wow.

Meanwhile also found out about this quite useful QT_LOGGING_RULES="*.debug=true" environment variable, but it made clear that there is no problem beyond the font missing a bold variant, and GTK but not Qt creating one on the fly... So, definitely something to bug the distant upstreams about :)

Thank you!!!

[newbthenewbd]

Just because it's funny, got that one :)

https://github.com/mburakov/qt5/blob/master/qtbase/src/gui/text/qfontengine_ft.cpp#L726-L727

https://bugreports.qt.io/browse/QTBUG-49164 sitting in there since seven years? *proceeds to plan a hijack on FT_IS_FIXED_WIDTH*