[Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget?

René J. V. Bertin rjvbertin at gmail.com
Wed Jan 27 19:03:46 CET 2016


Olivier Goffart wrote:

Hi,

> On Friday 4. December 2015 12:10:10 René J.V. Bertin wrote:
>> Hi,
>> 
>> What are the native classes (widgets) used to implement QTabBar and
>> QTabWidget widgets on OS X? I was expecting NSTabView and family, but can
>> find no occurrence of anything related in the source.
> 
> QWidgets (and QML) don't use native UI views. They draw everything themself.
> The drawing is done in the style (qmacstyle_mac.mm in this case)
> 
> So to repeat:
> QTabBar::paintEvent asks the style to paint the tabs
> QMacStyle::drawControl (see the case CE_TabBarTabShape) draws it.
> Apparently it's using HIThemeTabDrawInfo and HIThemeDrawTab.

I finally had some time and motivation to dig into this. The actual relevant 
case is CE_TabBarTabLabel in QMacStyle::drawControl() .

To repeat, my issue is that 2 fonts are being used for drawing the tab widget 
labels when I enable the use of the KDE (KF5) platform theme and combine that 
with the macintosh style. This should result in widgets that look like Mac 
widgets as usual, but using the fonts and colour palettes specified in 
~/.config/kdeglobals . Tab widgets are a notable exception: the active 
(selected) tab is drawn with the correct font, but the non-active tabs are drawn 
with the system font. That looks weird and leads to layout errors if the user-
specified font is much narrower than the system font, as tab dimensions are 
determined from the selected font.

The culprit here is the test

bool nonDefaultFont = p->font() != qt_app_fonts_hash()->value("QComboMenuItem");

which is always false : the KDE platform theme returns the relevant desired font 
through the ComboMenuItem style hint. As a result, the tab label is drawn using 
HIThemeDrawTextBox().

Shunting nonDefaultFont to true gives the correct behaviour (but the borders 
between tabs in a QTabWidget always look "fuzzy" ... because of 
isSelectedAndNeedsShadow?).

I haven't check but I presume that the active tab was always drawn with the 
correct font because of isSelectedAndNeedsShadow being true.

Question: is there another way to do the nonDefaultFont check, possibly 
comparing fontIDs (i.e. fontID(p->font()) not in 
{kThemeSystemFont,kThemeSmallSystemFont,kThemeMiniSystemFont})?

R




More information about the Development mailing list