> 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").
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.
- David
-----------------------------------------------------------
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
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
