[PATCH] Bug 156495: Drag and drop breadcrumb popup

[David Faure]

On Monday 23 March 2009, rahman duran wrote:
> >
> > +        if (m_dirsMenu != 0) {
> > +            delete m_dirsMenu;
> > +            m_dirsMenu = 0;
> > +        }
> > Remove the if, not useful.
> > In fact I don't really understand why you delete the menu there in the
> > dragmove event?
> > It will be deleted when exec() returns anyway (see the other "delete
> > m_dirsMenu" statement
> > in the code).
> 
> 
> This is why I said its tricky to manage it, in first post :) While we
> trigger menu with dragging we need to close it manualy as user don't click
> to the menu and the exec() loop won't end by it self. So the menu stays
> opened. This is Why I delete it manually. 

Ah OK. But exec() is called on that menu, right? It feels weird (and fragile) to
delete the menu while it's in exec().

Would hide() work too? From the qmenu code, it seems to end the exec() eventloop,
which is all you need AFAICS.

> If you ask why I delete in
> DragMove, simple; you know the little arrow that opens the menu? Its just a
> part of kurlbutton, not a button itself. So we need to close the menu if
> user decides to drop items on kurlbutton instead of the opened menu. If
> mouse leaves the arrow area we need to close menu.

I see. From just reading the patch I hadn't realized that the added code that calls
startPopupDelay() ends up creating m_dirsMenu and calling exec on it (correct me
if I'm wrong).

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).