[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: doubleclick toolbar button roundup
From:       Jelmer Feenstra <email () jelmer ! cc>
Date:       2001-10-23 19:29:13
[Download RAW message or body]

On Tuesday 23 October 2001 20:28, David Faure wrote:
> And toolPalette is a KToolbar.
> I remember the killu/kontour author (rm/Igor) asking for double-click
> support in KAction for this very reason.
> So... I don't know. Either we decide that double-clicks on toolbar buttons
> are not supported (as a special action), which won't break any kde cvs apps
> (dunno about out-of-cvs apps!) ..... or we take into account that some apps
> might want to use double-click on toolbuttons for a special purpose, like
> the old killu did.

Sigh, I was just told via email that konsole in HEAD also allows doubleclicks 
on the toolbar buttons, renaming the session if the signal is emitted by the 
button. So this is really getting weird now, toolbar buttons need to be able 
to emit doubleclick() signals and IMO they should emit a clicked() signal for 
every click they get (thus, twice if there's a doubleclick, to make sure my 
original problem is solved). Doing both _should_ not be a problem for the 
situations that were mentioned where the doubleclick signal is actually 
needed. When I tried this however, somehow in konsole the button that was 
doubleclicked stayed pressed (toggled) even when an other sessions button was 
selected (clicked). I'm looking through the konsole code now to see where the 
toggling happens and why it goes wrong, but I'm not making much of it :(

It would be nice if it were possible to (at the time of creating) tell the 
toolbarbutton if it needs to emit doubleclick signals. This would be used in 
those special cases, like konsole or killustrator. So, every toolbar button 
would just emit two clicked signals when it gets clicked twice (no matter how 
fast) and those that were told to emit doubleclicked signals as well will 
emit _one_ clicked signal and one doubleclicked signal. Handy, yes ? :)

> IMHO it would prevent trouble, but you'll still get trouble from apps that
> expect double-click-for-special-action.... well, I don't have a strong
> opinion either way. Well, yes, I have an opinion: it's sad not to be able
> to reach a consensus on something as basic as this, and to end up with
> yet-another-configuration option (the usual solution in opensource when
> it's not possible to please everyone...) In fact I'd let the _app_ tell if
> it wants doubleclicks or only single-clicks, not the user. [This wouldn't
> solve the "I double-clicked but I wanted a single action" case, but as was
> said, the same happens everywhere else, and we don't have to try and guess
> what the user wanted to do IMHO - this is what always sucks with MS
> products...]

I'm not sure whether or not you are now agreeing with me that clicking the 
back/forward/up/split twice fast is supposed to do that particular action 
twice as well...  If you do, what about the above solution ? (let the app 
tell if it wants doubleclicks for a particular toolbar button)

I know this is becoming a rather lengthy discussion, but I think it's worth 
it - as it surely can be done better compared to the situation at the moment.

Thanks for listening and awaiting your response,

Jelmer Feenstra

[prev in list] [next in list] [prev in thread] [next in thread]