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

List:       kde-core-devel
Subject:    Re: KTabBar -- double clicking on empty space
From:       Andreas Hartmetz <ahartmetz () gmail ! com>
Date:       2007-09-09 16:52:21
Message-ID: 200709091852.22403.ahartmetz () gmail ! com
[Download RAW message or body]

On Sunday 09 September 2007 18:40:14 Constantin Berzan wrote:
> On Sunday 09 September 2007 15:59, Richard Moore wrote:
> > On 9/9/07, Thomas Zander <zander@kde.org> wrote:
> > > The disadvantage of this is that all code listening to that signal need
> > > to special-case the magic number "-1".
> > > Which is sub-optimal because it adds complexity to the 'API' where you
> > > don't expect it.
> >
> > Yes, and any existing code that is using that index could be broken in
> > hard to find ways. I'd say having a new signal is a much cleaner
> > design.
>
> Having mouseDoubleClick(-1) makes sense.  If we create a separate signal
> for the empty tab area, then mouseDoubleClick() should be renamed to
> something like tabDoubleClick() to keep the semantics accurate and obvious
> (unless the new signal will be called mouseDoubleClick(void) as in
> KTabWidget). Same thing for MiddleClick if we decide that middle-clicking
> the empty space is worth signalling.

++ for two signals and renaming the existing one to tabDoubleClick[ed]().
The current name is, strictly speaking, wrong anyway.
What about the freeze though?
And what about right clicks? A too large number of signals is also something 
to avoid...
Oh, wait. Actually tab widgets should behave the same way in every application 
as far as that makes sense (very far IMO), so why would anyone need all these 
signals? Without an answer to this the rest is premature optimization.
[prev in list] [next in list] [prev in thread] [next in thread]