On 27 January 2016 at 21:28, Andreas Hartmetz <ahartm...@gmail.com> wrote:
> On Mittwoch, 27. Januar 2016 17:21:33 CET Boudewijn Rempt wrote: > [snip] > > > whether kglobalshortcuts is functional or not is besides the point: > > the point is that whether it works or not it doesn't add any > > functionality to the average application. Global shortcuts are useful > > only for a very limited set of applications, so it should always have > > been an optional dependency. > > > Here is something that is never beside the point: > maintenance burden and continuous-integration-ability. > ifdefs are somewhat bad for maintainability and really, really bad for a > continuous integration systems's ability to detect relevant build > breakage. I am repeating Martin's argument here with different words. > > IMHO eEveryone is right and doing a great work. Many FOSS projects don't bother with proper bug management or CI, you guys are the top percent! Please let me share some conclusion. I see t wo directions (realistically, a mix of them happens): 1. Accept that users of KF5 fork or shamelessly copy/paste the code and thus probability of contributing back (with code, real use cases, and bug/wish reports) become lowered. 2. Modularize, keep the number of tiers low. I've heard it's. If #ifdefs are suboptimal, then accept overhead of abstraction, injecting functionality, etc. Regarding #1. This happens to my paid (legal) uses of KF5 already.[0] So I wouldn't ask what people that never worked within KDE, would do. I am trying to contribute back to code I maintain. Well, worse, in my FOSS app where more flexibility and tinkering is possible, I would be soon back to reconsidering forking KActionCollection to avoid a chain of dependencies whan all I need from kxmlgui is that class. Apps like Krita or Kexi, targeting wider audience, are pretty good test beds. Regarding #2 and the optionality. In a framework I maintain, KDb, alternative to QtSql, the recent idea is to switch from optionality for database drivers to hard requirements. This change is based on some kind of "poor-man's behavioural studies": Optional features are until now so often skipped. Some packagers won't enable them even for testing for any reason including hard unsolved dependencies[1]. Now instead of that, everything but truly uncommon stuff would be ON by default. If someone knows what she/he is doing, will set to OFF but this will be actually a choice, hopefully informed choice. Can we encourage the use of this approach? [..] [0] I am happy with any use as this legitimizes this KDE's product as something well in par with the mainstream Qt! [1] *buntu tend to miss PostgreSQL support for a predecessor of KDb. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel