Issues porting KGeography to KF5

[David Faure]

On Thursday 02 January 2014 19:55:42 Kevin Ottens wrote:
> On Thursday 02 January 2014 19:51:17 Albert Astals Cid wrote:
> > El Dijous, 2 de gener de 2014, a les 19:48:46, Kevin Ottens va escriure:
> > > On Thursday 02 January 2014 19:45:36 Albert Astals Cid wrote:
> > > > El Dijous, 2 de gener de 2014, a les 17:36:41, Kevin Ottens va 
escriure:
> > > > > On Tuesday 31 December 2013 10:39:08 David Faure wrote:
> > > > > > On Tuesday 31 December 2013 00:52:59 David Gil Oliva wrote:
> > > > > > > Hi!
> > > > > > > 
> > > > > > > I'm porting KGeography to KF5, and I found some issues.
> > > > > > > 
> > > > > > > *KConfigDialog::setHelp()*
> > > > > > > 
> > > > > > > KConfigDialog* dialog = new KConfigDialog(this, "settings",
> > > > > > > kgeographySettings::self());
> > > > > > > dialog->setHelp("configuration", "kgeography");
> > > > > > > 
> > > > > > > It gives me the following error:
> > > > > > > 
> > > > > > > /home/david/devel/kgeography/src/kgeography.cpp:170:13: error:
> > > > > > > ‘class
> > > > > > > KConfigDialog’ has no member named ‘setHelp’
> > > > > > > make[2]: *** [src/CMakeFiles/kgeography.dir/kgeography.cpp.o]
> > > > > > > Error
> > > > > > > 1
> > > > > > > make[1]: *** [src/CMakeFiles/kgeography.dir/all] Error 2
> > > > > > > make: *** [all] Error 2
> > > > > > > 
> > > > > > > What should I subtitute it for? Or should I drop it?
> > > > > > 
> > > > > > Kévin? Is the help button missing in your port of KPageDialog to
> > > > > > QDialogButtonBox?
> > > > > 
> > > > > The problem is setHelp from KConfigDialog, not KPageDialog AFAICT.
> > > > > Not
> > > > > the
> > > > > help button itself.
> > > > > 
> > > > > setHelp is indeed gone as it was in KDialog. Moving to QDialog was
> > > > > likely
> > > > > the most disruptive source incompatible change we had to go through.
> > > > > It's
> > > > > supposed to be replaced by showHelp() which is virtual (and by
> > > > > default
> > > > > invokes openUrl with help:/ which should do the right thing in most
> > > > > cases
> > > > > assuming the framework integration is active)
> > > > 
> > > > I'd say showHelp does the wrong thing everytime setHelp was called
> > > > since
> > > > setHelp is used to specify which help page you wanted the help button
> > > > to
> > > > open, and if you're doing it is most probably because you don't want
> > > > the
> > > > default, so don't see how the default showHelp is going to work at
> > > > all.
> > > 
> > > Sure, by most cases I meant that in most cases setHelp isn't called
> > > anyway.
> > > For those who called setHelp the replacement are either reimplementing
> > > showHelp or connecting to the help button.
> > 
> > Can we have that documented with proper information of what the code
> > reimplementation of showHelp should do?
> 
> It should be some variation of the openUrl call but with a more convoluted
> URL. I didn't make the latest implementation of the integration for that
> one... Aleix might know the scheme used IIRC.
> 
> Hmmm... in fact it makes me realize that we could put back a setHelp with a
> different implementation which would change the URL used by showHelp... Then
> it'd be source compatible again for the KConfigDialog users.
> 
> Anybody feels like looking into that?

This requires moving KHelpClient to KConfigWidgets, I'll do that now.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5