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

List:       kde-core-devel
Subject:    Re: Tear-off handles for KPopupMenu
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       2000-04-27 11:57:59
[Download RAW message or body]



On Thu, 27 Apr 2000, Matthias Elter wrote:

> > The xmlgui stuff supports tear-off handles, by specifying a tearoffhandle
> > tag in a menu.
> 
> The tear-off handles on/off should be a KDE-global setting. Some apps using \
> tear-off handles, others not is not acceptable IMHO.

Sure, it would be nice.

BTW, the reason why I added support for tear-off handles in the xmlgui
code was not to make this a global thingy. It's just that I hate
limitations in a framework ;-) . That was the biggest problem of
OpenPartsUI, it was always behind the "real" API ;-) . Up to that point
it was not possible to insert a tear-off handle into a xmlgui aware
app. That is why I added support for a <tearoffhandle/> tag :-)

> > The problem with KPopupMenu inserting an item at the very beginning of the
> > menu will most likely break the xmlgui stuff, because it heavily relies on
> > knowing about _all_ items in a container widget (like a popupmenu is) 
> > (otherwise the merging screws up) .
> 
> Store the id's of the items you insert in a dict and you are save. Ok you are right \
> you have to be carefull with stuff like indexOf(). Perhaps it's possible to hide \
> the tear-off items by overloading methods like indexOf in KPopupMenu. I'm going to \
> look into this. 
> > I think inserting a tear-off handle at the beginning without the
> > application knowing about it is also likely to break other apps. Think of
> > the following example:
> > Imaging a Recent-Documents menu, created not with all the action stuff,
> > just with plain insertItem. I already saw code that connects to the
> > activated( int id ) signal of the menu and does something like
> > 
> > slot()
> > {
> > doSomething( listOfItems[ menu->indexOf( id ) ] );
> > }
> > 
> > As indexOf returns a different value than the programmer expects (because
> > KPopupMenu inserted an item the programmer does not know about) the
> > program is likely to break ;-) . Just doing a indexOf( id ) - 1 won't work
> > either because the user might change the gui settings in kcontrol so that
> > KPopupMenu does not insert that tear-off item.
> 
> Using indexOf(id) to identify menu items is bad design IMHO. You should always work \
> with id's and never rely on the index to identify menu items.

Yes, I fully agree, it is bad design.

Nevertheless I believe that we should not break the behaviour of Qt's
indexOf() method. The developer has to be able to rely on the method to
return a correct value. Having KPopupMenu insert a tear-off handle without
the programmer knowing about it (combined with the possibility to change
that at run-time) does break this rule.

And requiring code like

if ( menu->hasTearOffHandle() )
  doIt( menu->indexOf( id ) - 1 );
else
  doIt( menu->indexOf( id ) );

looks like a hack to me. (a hack we would have to explain to all the kde
hackers out there, as we changed the semantics of QPopupMenu.....)

> But as I said, it might be possible to "hide" the tear-off handles. I'm looking \
> into this.

That would be great! :)


Ciao,
 Simon


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