KMessageBox runtime dependency on FrameworkIntegrationPlugin makes it useless

[Kevin Ottens]

Hello,

On Saturday, 2 July 2016 12:23:31 CEST David Faure wrote:
> > [...]
> > We still need to handle the migration when/if the user installs
> > FrameworksIntegration no? Suddenly all his MessageBoxes will be back
> > without any apparent reason.
> 
> True. Although this feels like a corner case without much harm (one can just
> click "don't show again" once more).

Agreed, it's not so much of an issue IMO.

> > I guess the other benefit that KConfig brings is that it can support
> > "system overrides" of the config options, is that really useful for
> > "dontShowMeAgain" settings?
> 
> QSettings supports that, actually.
> 
> I think we have two different questions at hand here.
> 
> 1) what would have been the right solution for this if KF 5.0 wasn't out
> yet? ---> there I would agree, using QSettings only, no plugin, would have
> been much simpler. We would have changed the API to remove or rework
> setDontShowAgainConfig(KConfig *), and we would have ported the apps with
> GUI code to re-enable all messages from KConfig to QSettings.
>      ---> alternatively, I would now say, we should just have moved
> KMessageBox to a framework with a higher tier.

Unfortunately I can't remember why we never went any of those routes... I 
think it was a mixture of time constraints and differentiation from Qt.

> 2) how do we fix this now, taking into account existing apps, i.e. our BC/SC
> constraints.
> 
> We can't come up with a good solution for that question, because things are
> broken right now (no plugin = no way to save) and whatever we change, we
> break something else (QSettings only = we break existing GUI code;
> QSettings as fallback = we introduce "migration" issues when
> installing/uninstalling the plugin).

I think the "migration" issue is the least annoying. As you pointed out it 
would be just about having to click the checkbox once more when the plugin get 
uninstalled. Not perfect, but not a big deal either.

> I'm wondering if the best option wouldn't to ask all packagers to make
> kwidgetsaddons depend on frameworkintegration. Everything else leads to
> breakage.

Urgh... no. Otherwise we're making a lie with the tier we have for it.

Besides, honestly I don't think that's a breakage, it was intended that way: 
no integration plugin, it's like QErrorDialog remembering the state until the 
application restarts, integration plugin you get something more clever because 
you use more of the system.

> My ideal solution (kmessagebox in a higher tier) can't be done anymore
> either, because that would break SC (apps using it, might not link to that
> other lib).

That said, I think there's another option which wouldn't need a KF6. This one 
was clearly not pursued due to time constraints, but it's not the case 
anymore. What about bringing the missing features to QMessageBox and then mark 
KMessageBox deprecated once it lands? It can't be that many features anymore I 
think.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160707/6357a461/attachment.sig>