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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
