Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.

[Alex Merry]

> On March 1, 2014, 11:15 a.m., Alex Merry wrote:
> > The implementation all looks fine.  The only concern I have is that it's an odd location for it; I wouldn't expect to go looking for a method to invoke Help in KConfigWidgets.  Although I'm not sure where it would go instead, given the reliance on QtGui and KConfig.
> > 
> > Although, maybe is could go in KConfigGui?  It's still a bit out of place, but it sort of fits in KConfig if you think of it as accessing a bit of system/application configuration ("where to find help").
> 
> David Faure wrote:
>     Yeah I thought about that alternative. We already abuse KConfigGui for kstandardshortcut, kwindowconfig, etc. -- i.e. things that are there for dependencies reasons, not because they are in the expected feature list for the KConfig framework.
>     So I tried to not keep abusing it...
>     
>     One scary way to look at the issue is: what if one day we want to replace KConfig with another configuration technology? Then all that stuff we bundle into KConfigGui (i.e. into the KConfig framework itself), will be in the wrong place, since we'll want these APIs to keep existing, just not with kconfig as the underlying technology.
>     
>     (OTOH KConfigWidgets is a different framework, it's "widgets with a need for configuration", doesn't have to be tied to KConfig as the underlying implementation)
>     
>     I know, I'm saying here that we did it wrong for kstandardshortcut and kwindowconfig, where I was probably the one selecting the current situation...
>     I also don't honestly think that moving away from KConfig is a plan (but rather providing any new technology from within the KConfig API instead).
>     
>     I picked KConfigWidgets using the same logic as to why it was in xmlgui before: because that's where it's needed, at the lowest level.
>     
>     I can be convinced for KConfigGui, but it's not ideal either, for the reasons above.
>

OK, if we just work on the basis that KConfigWidgets is misleadingly named (not that a better name occurs to me), and is essentially the tier 3 version of KWidgetsAddons, that seems fine.


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115959/#review51415
-----------------------------------------------------------


On Feb. 23, 2014, 11 a.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115959/
> -----------------------------------------------------------
> 
> (Updated Feb. 23, 2014, 11 a.m.)
> 
> 
> Review request for KDE Frameworks and Albert Astals Cid.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> -------
> 
> 3 commits:
> 
> 
> Unittest: make errors readable
> 
> --
> 
> Resurrect KConfigDialog::setHelp (used to come from KDialog).
> 
> It controls the default behavior of showHelp(), which is implemented
> using KHelpClient.
> 
> REVIEW: 115959
> 
> --
> 
> Move KHelpClient down from kxmlgui, for use in KConfigDialog.
> 
> 
> Diffs
> -----
> 
>   autotests/kconfigdialog_unittest.cpp e5322c1782c2a68c15451777066e28a9b7afea23 
>   src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 
>   src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 
>   src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 
>   src/khelpclient.h PRE-CREATION 
>   src/khelpclient.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/115959/diff/
> 
> 
> Testing
> -------
> 
> Compiled all of KF5.
> 
> 
> Thanks,
> 
> David Faure
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140301/18080b73/attachment.html>