Am 27.12.2012 22:14, schrieb Bache-Wiig Jens:
> That said, it should be relatively easy to work around this in an application
> by creating a custom proxy style:
>
> class MyProxyStyle : public QProxyStyle
> {
> public:
> int styleHint(StyleHint hint, const QStyleOption *option = 0,
> const QWidget *widget = 0, QStyleHintReturn *returnData =
> 0) const {
> if (hint == QStyle:: SH_ItemView_ActivateItemOnSingleClick)
> return 0;
> return QProxyStyle::styleHint(hint, option, widget, returnData);
> }
> };
>
> Just set this as your application style and it should revert to the old
> behaviour regardless what your existing application style is.
Thanks for that. Yes, I think it should work. However, as I offer all
available styles to my users for selection I'd have to do this for every
single style... and it's probably not really usable when querying them
via QStyleFactory::keys(). I actually don't want to change them
"hard-coded", but it seems there's no other solution...
It might simply be a bug in which case I'd gladly file a bug report, but
I would like to hear some developer's opinions on it before I do so... I
think it's pointless to file a bug if it's wanted behavior - for
whatever weird reason.
@Andreas: yes, I'm sure about this. Changing the default in KDE (or any
other desktop environment) doesn't change the situation. I haven't yet
tried it on anything else than Linux, though.
Not using the activated() or itemActivated() signals is pointless IMHO
because it would mean a drastic change in *many* parts of the code and
doesn't really sound like the way to go, simply because of API
compatibility (which according to the docs hasn't changed in this
area)... also, note that I'm still using Qt 4 primarily.
Thanks again for your replies!
Cheers, René
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
