[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:27:55
[Download RAW message or body]



On Thu, 27 Apr 2000, David Faure wrote:

> On Thu, Apr 27, 2000 at 12:58:20PM +0200, Matthias Elter wrote:
> > Hi
> > 
> > I have patched KPopupMenu to insert a tear-off menu in all non-toplevel menus. \
> > Similar to single/double click this is of course a KGlobalSetting. 
> > A tear-off handle is a special menu item, that - when selected - creates a copy \
> > of the menu. This "torn off" copy lives in a separate window. It contains the \
> > same choices as the original menu, with the exception of the tear-off handle.  
> > Problem: Only a few kdebase apps are using KPopupMenu instead of QPopupMenu right \
> > now. This should be changed for consistency reasons. 
> > Especially the XML GUI stuff should be fixed to use KPopupMenu.
> 
> That's interesting - Simon had other plans for using tear-off
> handles in the XMLGUI ;-)
> I like your way, though. But for it to work with the XMLGUI stuff,
> it has to "hide" the fact that there is a toolbar handle, 
> in terms of position ("index").
> (The XML-GUI stuff uses positions quite intensively, so it
> would get confused if an unknown item has position 0...)

The xmlgui stuff supports tear-off handles, by specifying a tearoffhandle
tag in a menu.

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) .

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.

Or am I missing something?

Ciao,
 Simon


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