Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

[Jaroslaw Staniek]

On 27 January 2016 at 21:28, Andreas Hartmetz <ahartmetz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160128/63c8fa29/attachment-0001.html>