[KScreen] [Bug 361954] Make kwayland backend optional

[Martin Gräßlin via KDE Bugzilla]

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

Martin Gräßlin  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #17 from Martin Gräßlin  ---
Changing back to wontfix to match the maintainers decision on that topic.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Luke-Jr via KDE Bugzilla]

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

Luke-Jr  changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #16 from Luke-Jr  ---
Since this requires (indirectly) changes to Mesa, which is indeed loaded with
X11, your claim is only half true.

Other components are not libkscreen, and may not necessarily be needed by the
user. For example, LxQt currently requires libkscreen, but not any of those
other Wayland-demanding components.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Sebastian Kügler via KDE Bugzilla]

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

Sebastian Kügler  changed:

   What|Removed |Added

   Assignee|se...@kde.org   |n...@kde.org

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Sebastian Kügler via KDE Bugzilla]

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

--- Comment #15 from Sebastian Kügler  ---
@Jeremy

Please note that there's no Wayland protocol "running" in an X11 session. This
backend is loaded at runtime under specific conditions, namely when you run a
Wayland session. Nothing of it is loaded under X11.

Furthermore, KWayland is already a build requirement from other components.
Making it optional in libkscreen is not going to buy you anything.

You may re-read this thread, it contains all the above information already. In
the future, when using Bugzilla, please make sure to refrain from personal
accusations, especially those based on misinformation or a simple lack of
technical understanding (we're happy to answer questions, if you're unsure
about something, you just have to ask nicely).

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Jeremy Andrews via KDE Bugzilla]

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

Jeremy Andrews  changed:

   What|Removed |Added

 CC||athenian...@outlook.com

--- Comment #14 from Jeremy Andrews  ---
Just wanted to say, this exact attitude on the part of the developers is why I
gave up on GNOME years ago. I'm sad to see that this Apple-like pursuit of
simplicity and irreductible interdependency on whatever library is popular at
the moment has also infected the KDE community.

I'm an X11 user that doesn't want a bunch of Wayland protocols running on top
of X and going around standard ways of doing things with a nascent protocol
that isn't nearly as well-tested and with which I have no experience. When
Wayland is actually ready and in a usable state, I plan to use it in place of
X. It isn't there yet. I'm not happy with this poorly-implanted kludge of a
desktop environment you've hacked together. It essentially forces KDE users to
have a frankensystem that runs the Wayland protocol on top of X in order to
take advantage of new features while still being able to use legacy X-dependent
code.

It's obvious from reading this that your only agenda here is making less work
for yourselves rather than what's good for the user, or even what makes for a
stable piece of software. You can say it's just one library, but it's one
library that replaces half of what X is supposed to do with an incompatible way
of doing things. I'm not okay with that. If I had wanted Wayland, I would have
installed it myself. I'm not interested in beta-testing Wayland for you.

So, I just want to let you know that you've lost another user to LxQt. I like
Qt5, and I'm glad that Qt is at least somewhat independent of your organization
at this point, and can only hope that the KDE team's attitudes don't spread
into Qt itself. If this is how people code when you don't pay them money, I'm
tempted to rethink the wisdom of open source software as a concept.

-- 
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 #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

[Martin Gräßlin via KDE Bugzilla]

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

--- Comment #11 from Martin Gräßlin  ---
> If KWin/Plasma 5 will require KWayland

Things which require KWayland as of today:
* mandatory in kscreenlocker - used for private communication between the
daemon and the greeter
* mandatory in kwin - it's a Wayland compositor after all
* mandatory in powerdevil - needed to turn of screens in a Wayland session
* mandatory in plasma-integration
* optional in KInfocenter
* optional in Breeze
* optional in Oxygen

KWayland is just in the progress of becoming a framework, afterwards you can
expect several frameworks to start using it. Good candidates are plasma,
knotification, etc. In some cases it will be optional due to supporting
non-Linux builds, in some it won't.

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.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Luke-Jr via KDE Bugzilla]

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

--- Comment #10 from Luke-Jr  ---
In my case, I still run KDE 4, with a few KF5-based applications. If
KWin/Plasma 5 will require KWayland, I will probably switch to LXQt when KDE 4
ceases to be viable. LXQt, however, still requires libkscreen.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Sebastian Kügler via KDE Bugzilla]

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

--- Comment #9 from Sebastian Kügler  ---
By the way, out of interest: why do you want libkscreen sans wayland? Kwin and
plasma-workspace depend on KWayland as well, so you'll need Kwayland anyway to
build Plasma, or are you also going to hack the build-system for these repos to
make it optional? Are you using libkscreen for something else entirely that I
may have missed?

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Sebastian Kügler via KDE Bugzilla]

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

--- Comment #8 from Sebastian Kügler  ---
Thanks for educating me about whole point of my work and my aim of
participating in KDE. :-D

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.

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.)

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 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.

-- 
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

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.

[KScreen] [Bug 361954] Make kwayland backend optional

[Luke-Jr via KDE Bugzilla]

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

--- Comment #6 from Luke-Jr  ---
Quite a few distros are source-based now.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Sebastian Kügler via KDE Bugzilla]

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

--- Comment #5 from Sebastian Kügler  ---
The split would have to be done in the binary packages, only.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Luke-Jr via KDE Bugzilla]

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

--- Comment #4 from Luke-Jr  ---
I don't understand your final sentence. It doesn't look like the build system
currently supports splitting the backends into different packages: it always
wants to build them together.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Sebastian Kügler via KDE Bugzilla]

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

--- Comment #3 from Sebastian Kügler  ---
Well, in the end, those that have to do the work have to make this decision,
and that's (among others), me. We take these decisions based on priorities and
past experience.

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.

Please note that your wish can easily be solved at packaging level by splitting
the build into multiple packages and you can only install what you really want
on your system.

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

[KScreen] [Bug 361954] Make kwayland backend optional

[Luke-Jr via KDE Bugzilla]

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

--- Comment #2 from Luke-Jr  ---
It increases complexity far more to force end users and/or distros to do it on
their own instead...

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