Review Request 128880: [OS X] use a different tab bar widget for tabbed documents

[René J.V. Bertin]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128880/
-----------------------------------------------------------

(Updated Sept. 12, 2016, 10:47 p.m.)


Review request for KDE Software on Mac OS X and KDevelop.


Changes
-------

This revision also addresses the artefact in the line/col indicator widget. This uses an estimate for the tabbar overlap which is based on `QStyle::PM_TabBarBaseOverlap`; evidently this value should be obtained from `m_tabBar->style()` (which might return Fusion) rather than from `KSqueezedTextLabel::style()` (which will always return "macintosh"). QTabBar is centre-aligned with the base on OS X, so that explains the artefact.

Even using `m_tabBar->style()` the result is still not ideal; skipping the underlining attracts the eye much less, so I propose to do exactly that on OS X, with a simple `#ifdef`.


Bugs: 363473
    http://bugs.kde.org/show_bug.cgi?id=363473


Repository: kdevplatform


Description
-------

This is a potential fix for an issue raised on BKO: https://bugs.kde.org/show_bug.cgi?id=363473

It's also the most complete/implementation:
- applies only when the Macintosh widget style is being used
- if so, creates a QStyle object for the Fusion widget style
- when successful, sets the `Sublime::ContainerTabBar` to use that style

This solves all issues stemming from Qt's use of a "native" widget that is intended only for use in dialogs and not in tabbed document interfaces.

In my testing, the `ContainerTabBar` ctor is called only rarely, apparently only when changing views (e.g. code -> patch review and back again, or code -> debug). If that observation is correct, use of a global `qTabBarStyle` variable is justified (but more elegant solutions might exist). This observation also justifies (IMHO) the check for the active application style rather than using an `#ifdef Q_OS_OSX` or even applying the fix across all platforms and application styles. That is certainly a possibility that doesn't lead to any shocking style mismatches in my eyes. It does cause some loss of compactness when using my QtCurve settings, which is why I added the style check; a small cost as a gesture to users of a highly configurable style.

There is still some weirdness behind the tabs which looks like a misaligned well or frame. I'd love to get that right too.


Diffs (updated)
-----

  sublime/container.cpp b04f6c3 

Diff: https://git.reviewboard.kde.org/r/128880/diff/


Testing
-------

See https://bugsfiles.kde.org/attachment.cgi?id=99160 (unpatched) and the last series of screenshots attached to the ticket on BKO. They show the fix applied to various styles on OS X.


File Attachments (updated)
----------------

background: pure Breeze theme. Foreground: Breeze with the QTabBar set to Fusion
  https://git.reviewboard.kde.org/media/uploaded/files/2016/09/12/3fbb5571-8fb7-4af7-b6d5-eb1d9b32cea1__tabbar-breeze-with-fusion.png
Background: pure QtCurve<OS X Graphite>. Foreground: QtCurve<OS X Graphite> with QTabBar set to Fusion
  https://git.reviewboard.kde.org/media/uploaded/files/2016/09/12/b1bc9406-4f98-4920-832b-2728aa9d2ee2__tabbar-breeze-with-qtcurve.png
Tabbed document interface in native OS X applications
  https://git.reviewboard.kde.org/media/uploaded/files/2016/09/12/5790c412-566c-42bc-83b5-efbec458d711__MacNativeTabs.png
pure native Macintosh style with Fusion QTabBar
  https://git.reviewboard.kde.org/media/uploaded/files/2016/09/12/0a98cc35-dad4-439c-af91-51ffc14e21b0__MacNative-QTabBarFusion.png
pure native Macintosh style, Fusion QTabBar, no misaligned underlining
  https://git.reviewboard.kde.org/media/uploaded/files/2016/09/12/56f92d7e-8f71-401d-b874-55165d0f701a__MacNative-QTabBarFusion.png


Thanks,

René J.V. Bertin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20160912/1069d5bb/attachment.html>