[KScreen] [Bug 361954] Make kwayland backend optional

[steveL via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361954

--- Comment #13 from steveL  ---
(In reply to Martin Gräßlin from comment #11)
> Please note that KWayland is a library, it does not mean that you have to
> run Wayland. If you want to switch the desktop environment because of the
> usage of one library, please do so. I consider that as an irrational
> reasoning. Please understand that we won't go extra miles to support such
> choices.

I don't follow your logic: I fail to see how you could possibly go to any
length at all to provide technical support to someone who has decided not to
use your software.

At that point, it's irrelevant what choices you feel comfortable with; you've
already lost the user/s.

-- 
You are receiving this mail because:
You are watching all bug changes.

[KScreen] [Bug 361954] Make kwayland backend optional

[steveL via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361954

--- Comment #12 from steveL  ---
(In reply to Sebastian Kügler from comment #8)
> Thanks for educating me about whole point of my work and my aim of 
> participating in KDE. :-D

Eh? Who said anything _at_all_ about *your* personal aims or goals?

Since this appears to be getting somewhat "edgy", let me state at the outset
that this is not about making anyone do anything, nor about infringing on your
rights.

It is solely about keeping KDE widely-usable.
I am not here on some misdirected mission wrt any other project, or agenda: I
have been using KDE solely since 1998.

> I don't know how "KDE's sponsored purpose as a showcase for Qt" is to be
> understood or where you're coming from with this, but let's concentrate on
> technical rather than philosophical or academical topics.

Inverted coupling *is* a technical matter.

I'm perturbed that you don't know KDE has always been a showcase for Qt, which
is cross-platform or not worth buying, again a technical matter that affects
the bottom-line.

> I'm speaking as maintainer (so bug-wrangler and developer). These roles
> cannot be split, or at least we don't have people who just triage bugs. In
> practice, it's the developers having to shoulder this work as well as
> development. (Your help is welcome here.)

If you don't have bug-wranglers, how can people help with bug-wrangling?
The whole point of a bug-wrangler is that they have (at least) assignment
permissions on bugs.

Anyhow, I'm unsuited to be a bug-wrangler; though I know a good one when I see
them: Gentoo's Jakub Moc (retired) is the best I've seen so far, though perhaps
not so good at bringing in newer wranglers due to his relentless focus.

If you actually want bug-wranglers, you could do a lot worse than Luke-Jr, or
most Gentoo users who make it your bugzilla (they build from source, they try
to solve their own problems with help from others whom they help in turn, and
they test and submit patches.)
OFC you'd have to recruit them, and which requires actually having a position
to recruit them to.

Still, I think we'd both agree now, that we are off-topic. ;)

Irrespective of your buglists, bug-wrangling or lack of it, is entirely
orthogonal to software architectural design.

It seems to me, that you are not giving yourself less bugs; you are giving
yourself more, with more pressure, because everyone is being forced on to the
unstable framework, on top of an unstable, in-development lower-layer (which
cannot be tested against a stable one, "because simplify.")
I'm presuming there are ABI abstractions in play; Qt has always supported ABI
compatibility across the series.

> In the end it all boils down to a resources available versus complexity. A
> higher degree of complexity means more possible cases to investigate, which
> in turn means more resources needed to deal with this complexity. We've made
> a conscious decision to not support building libkscreen without Wayland
> support for these reasons.

(That's a reason, not several.)
Odd, I thought FLOSS was meant to be a collaboration, with QA done by users,
and even the occasional patch. Users support each other for their corner-cases,
and the software gets more robust and more widely usable, as a result.

You can never investigate all the various cases, despite attempts to enumerate;
the target moves too rapidly. That's why one throws desktop apps out to
early-adopters to do the beta-testing.
It is important however, to be able to backtrack at this point, so one can
provide guarantees later.
And to see both implementation and use of stable APIs as the goal, since it's
much easier to test when you can swap out or mock, as it is better for the user
when their software respects the ecosystem (and can thus be swapped in, or
out.)

> That said, from a cursory glance, your patch looks like the way I'd do it as
> well. I just don't want it upstream, and I won't spend any effort supporting
> your patched version of libkscreen. Please clearly mark your patched version
> as such to avoid confusion.

Thanks for the confirm.
Sure on the marking, though this may be moot by the time we get to production
testing, never mind usage.

The decision to restrict KF/Plasma on Linux to only work with wayland, and not
standard X.org, is what puzzles me, given the Qt cross-platform base.

Forgive me if that's a misinterpretation; a clear statement to the contrary
would suffice to allay my concern, that KDE is throwing away the option to use
a proven dependency in favour of one unproven in the harsh world, when one
could just use both and thus always have an alternative implementation to test
against.

If this seems difficult, then it's perhaps possible that there is emulation of
web-browser ABIs going on, instead of projects like LADSPA.

I reiterate that my concern is solely about keeping KDE widely-usable.

ATM "Kwin and plasma-workspace depend on KWayland as well, so you'll need
Kwayland anyway 

[KScreen] [Bug 361954] Make kwayland backend optional

[steveL via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361954

steveL  changed:

   What|Removed |Added

 CC||sl...@rathaus.eclipse.co.uk

--- Comment #7 from steveL  ---
> When looking at the list of bugs in our screen management tools, the last 
> thing I
> want to see is more bug-reports that I have to sift through because some
> packager or user built their libkscreen without wayland support. This time is
> much better spent on the current set of bugs. I'm sure that's something we all
> can agree on.

Regretfully, I cannot. The whole point of KF/Plasma is to be more modular, not
less, in aid of KDE's sponsored purpose as a showcase for Qt.
As such, inverted coupling like this, to wit insisting on wayland support from
the platform in question, is contrary to the aims of the overall project, and
the clear direction set by core developers for the design.
Even were it not, inverted coupling is ALWAYS a no-no, apart from the
occasional exception for OS-vendor platform-specific implementation of a
standard (at the level of using an implementation-defined path for the sh
interpreter.)

WRT "lists of bugs" are you speaking as a bug-wrangler, or a developer?
No-one wants to add unnecessary work, but this appears to be an issue with
bug-wrangling support, which is orthogonal to architectural goals for the SC.

Stating that the split can only "be done in the binary packages" can in no way
be seen as modularity at the source level.

Luke's patch is at: http://luke.dashjr.org/tmp/code/no-kwayland.patch
Comment or review, before we apply and use it downstream, would be most
appreciated.

-- 
You are receiving this mail because:
You are watching all bug changes.