PopupFlags in konq_listviewwidget.cc

[David Faure]

On Friday 02 January 2004 12:24, Julian Rockey wrote:
> Hi,
> 
> Revision 1.222 of konq_listviewwidget.cc changes the signal emitted when a 
> popup is requested, from
> 
> void popupMenu( const QPoint &global, const KFileItemList &items )
> 
> to
> 
>  void popupMenu( KXMLGUIClient *client, const QPoint &global, const 
> KFileItemList &items, const KParts::URLArgs &args, 
> KParts::BrowserExtension::PopupFlags i )
> 
> This breaks my app, which relies on the former being emitted.
>
> My question is: is this intentional - i.e. apps cannot rely on the 
> browserextension API to remain stable? And the only way to make the code work 
> with 3.1 and 3.2 is to #ifdef? So I can't make a binary that works on both?

You have a good point here - there's no BC requirement on konq_listviewwidget.cc
itself, but there's usually a behavior-compatibility requirement at the BrowserExtension
level.
Hmm, difficult problem. We can't emit both, since this would trigger the popupmenu
twice in konqueror. I don't see a way to restore behavior-compat here - the change was
very much needed, to clean up the popupmenus a bit.

You could connect to a signal even if it's not defined anywhere - but your slot using
PopupFlags would not compile on KDE-3.1. However since you don't need the actual
flags, you could simply remove that argument from the slot - it's allowed to connect
a signal with 5 args to a slot with 4 args, dropping the last one.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions