It's not hard to make it optional in the build, but that would increase complexity, and that's something we don't want.

We have deliberately chosen to build the KWayland backend in any case because we want to avoid another point of failure in a system that is already complex enough to deal with.

It increases complexity far more to force end users and/or distros to do it on their own instead...

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.

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.

The split would have to be done in the binary packages, only.

Quite a few distros are source-based now.

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

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.

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?

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.

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

(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 to build Plasma", indicates my concern is warranted.

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

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.

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

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.

Changing back to wontfix to match the maintainers decision on that topic.