| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| | |
Conflicts:
tests/auto/qtreeview/tst_qtreeview.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On XP and Vista where tabs use taboverlap, the currently
dragged would loose the outline. We need to compensate for the
taboverlap when creating the draggable widget, otherwise the
outline will be clipped.
Task-number: 254453
Reviewed-by: nrc
|
| |\ \
| |/
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qcocoaview_mac_p.h
src/gui/widgets/qmainwindow.cpp
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This fix ensures that the current tab is visible after calling
setTabButton() on a scrolled tab bar.
Reviewed-by: bnilsen
Task-number: 252472
|
| | |
| |
| |
| |
| |
| | |
Spotted by looking at the code
Reviewed-by: bnilsen
|
| |/
|
|
|
|
|
|
|
| |
We do not need to relayout on all changeEvents. The only events that
should change the layout of tabs are StyleChange and FontChange.
LayoutDirectionChange is separately by layouts.
Task-number: 188389
Reviewed-by: ogoffart
|
| |
|
|
|
|
|
|
|
| |
The problem is in QTabBar which emits the currentChanged signal
before accessing its own internal data. As we react to that signal by
possibly removing/adding tabs, it can cause a assertion failure.
Task-number: 251184
Reviewed-by: ogoffart
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a few of the remaining glitches tabbar animations have:
* We no longer grab tabs but paint them through QStyle. This makes tabs
work and animate correctly when they are outside the visible region.
* Buttons now correctly follow tabs when dropped
* Gtkstyle recieved some polish to make it look more native.
Task-number: 247694, 251166
Reviewed-by: nrc
|
| |
|
