Review Request: Move from KTabWidget to KTabBar tab switching by mouse wheel events.

[Christoph Feck]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/5184/#review7313
-----------------------------------------------------------


Sorry, that's even worse. Now it might skip tabs because on each wheel event both the wheelDelta() as well as your new code is executed. Users will be annoyed.

I just looked at lxr.kde org, and for example [1] uses wheelDelta() signal to implement the tab switching on wheel.

We have three options:

A) Do not touch it: We respect the initial envisioned API that applications listen to that signal and use it for whatever they see fit. Not that I like that signal-based API, but just breaking it without looking at the consequences is short sighted. It probably was added so that developers don't need to put all that QT_NO_WHEELEVENT etc. stuff into their code.

B) Your initial approach: We silently discard that signal-based API by simply never emitting the signal and force developers to reimplement wheelEvent() instead when they want custom behavior. Only developers who used the signal for purposes other than tab switching will have to change their code.

C) Add a property to KTabBar that switches between A and B, with A being the default (and mention that A is deprecated, i.e. developers should set it to B, because that will be the only option in KDE 5).

Comments please.

[1] http://lxr.kde.org/source/extragear/sdk/kdevplatform-git/sublime/container.cpp#181

- Christoph


On 2010-08-31 15:54:54, David Palacio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5184/
> -----------------------------------------------------------
> 
> (Updated 2010-08-31 15:54:54)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> KTabWidget implements tab switching as response to mouse wheel events. This makes applications like Rekonq, that use a KTabBar instead, do nothing when the wheel is scrolled.
> 
> The proposed patch moves the behaviour implementation from KTabWidget to
> KTabBar, disables and disconnects the relevant signal in KTabBar/KTabWidget.
> 
> Note that QTabBar in Qt already implements this with a small difference: it
> does not wrap around the extreme tabs. That is, it will not go from the last to
> the first tab and viceversa.
> 
> 
> This addresses bug 248962.
>     https://bugs.kde.org/show_bug.cgi?id=248962
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdebase/apps/dolphin/src/dolphinmainwindow.h 1170268 
>   /trunk/KDE/kdebase/apps/dolphin/src/dolphinmainwindow.cpp 1170268 
>   /trunk/KDE/kdebase/apps/konsole/src/ViewContainer.cpp 1170268 
>   /trunk/KDE/kdelibs/kdeui/widgets/ktabbar.cpp 1170208 
>   /trunk/KDE/kdelibs/kdeui/widgets/ktabwidget.cpp 1170208 
> 
> Diff: http://reviewboard.kde.org/r/5184/diff
> 
> 
> Testing
> -------
> 
> Rekonq works as expected.
> KTabWidget users, such as Konqueror and Konsole work as well.
> 
> 
> Thanks,
> 
> David
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100831/280ef873/attachment.htm>