MarcusMoeller wrote:... and just to summarize. The original bugreport has been created back in 2012. Martin promised a possible inclusion for 4.9

Then I asked Andre to code the switcher (getting paid for his work) and he filed a review request. Martin then told, that it first should be put on kde look and could be included later if it's well adopted. That was more than a year ago. The switcher is the best rated and most downloaded one, but now there is another and another reason why it should not be included? Doesn't that sound frustrating for a contribution (no matter if paid or not?). Do you really want to call more than two years of waiting 'nagging'?

well, it has a rating of 63 % (which is hardly more than the 50 % it started with) and got downloaded 121 times. So I would rather question whether it ever reached the "well adopted" stage.

Concerning inclusion: what we don't want is to open up for including all possible variants, that's exactly why we introduced the possibility for 3rd-party hosting of switchers. And that's also why we are just talking about reducing the amount of offered switchers by default. Please also understand that if we accept more switchers it comes with a cost for us: we are then maintaining the switcher. That's another reason to reduce the number of offered switchers in a default installation.

well, it has a rating of 63 % (which is hardly more than the 50 % it started with) and got downloaded 121 times. So I would rather question whether it ever reached the "well adopted" stage.

we are using the switcher on more than 600 machines as default. Imho the values on kde-look are quite high, as one has to register, login and to vote. As far as I remember, the internal voting machanism in KDEs 'get more..' dialog never worked.

And as you see, when it comes to adoption, we already ported the switcher to plasma 5, the only thing we asked for, was to review and to include it.

Besides that, KDE-look does not yet offer an option to provide scaling switchers for plamsa 5. Also there is no way to create one 'product' with different 'branches', meaning we would need to create a new 'product' like Scaling Switcher for plasma 5.x. I don't even know whom to contact, to request support for plasma 5 switchers.

Greetings
Marcus

MarcusMoeller wrote:we are using the switcher on more than 600 machines as default.

nice

MarcusMoeller wrote:Imho the values on kde-look are quite high, as one has to register, login and to vote. As far as I remember, the internal voting machanism in KDEs 'get more..' dialog never worked.

Well let's not discuss the brokeness of the opendesktop voting mechanismn I still have content with 93 % rating which I haven't touched there for years and nobody probably downloaded for years as it is included in KWin.

MarcusMoeller wrote:Besides that, KDE-look does not yet offer an option to provide scaling switchers for plamsa 5. Also there is no way to create one 'product' with different 'branches', meaning we would need to create a new 'product' like Scaling Switcher for plasma 5.x. I don't even know whom to contact, to request support for plasma 5 switchers.

Yeah that are exactly the reasons why I wrote above that I don't want to have the currently shipped switchers moved there. If we go for the plasma-addons repository I won't say no to add it there. So let's just finish the general discussion - it looks like L'n'F for the default switcher and all others to plasma-addons.

it looks like L'n'F for the default switcher and all others to plasma-addons.

Sounds reasonable

Greets
Marcus

What seems to be Martin's - understandable - fear is that he ends up with having to maintain other people's switchers if they abandon them.

So what if we say that switchers in Plasma-Addons only stay there as long as someone other than Martin is willing to maintain them? If e.g. Marcus and Andre at some point both lose interest in "their" switcher and nobody else wants to maintain it, it's dropped out of Plasma-Addons with its next release. As long as they maintain it, it can stay.

MarcusMoeller wrote:Do you really want to call more than two years of waiting 'nagging'?

I this call "nagging":
(full discussion here: https://git.reviewboard.kde.org/r/109832/)
---------------------------

Martins initial reaction to the bump was

mgraesslin wrote:If I think about it, we should even remove all except the default one and make all others 3rd-party.

Replies:

Andre wrote:If KWin decides in the future to move the plugins out and only maintain the default window switcher it should not hurt that much to have nine plugins to move instead of eight But atm I think it is the best place for this code.

"best place" (probably) "reasoned" by (false) claim

Andre wrote:as the used API changes so rapidly

which Martin immediately denied.

We go on:

Andre wrote:A more fundamental discussion should be held on a mailing list. But I don't see why the outcome of this discussion should block this commit.

Andre wrote:But I think it is unfair that you keep rejecting this plugin for reasons that are not related to it and about which I can do nothing.

Remember: the just given and main and standing reason is that Martin didn't want to incorporate more switchers at all and the requirement for a more fundamental discussion which might very well have the outcome to remove the switcher (as is) again was acknowleged (and in an illogical stance declared not a reason to not include the switcher before it's clear whether it would remain at all)

At that point, I frankly got suspicious, tried the switcher, compared it to the present ones, and pointed out what I considered improvable about the present switcher situation (invoking the scaling switcher)

The you showed up:

MarcusMoeller wrote:I would not welcome to completely switch the style on a larger number of windows.

With the "argument" that a larger number of windows would be uncommon anyway and ignoring that the "scaling" switcher altered it's style (esp. also label usage) depending on the amount of windows,
I pointed that out.

You reaction was the suggestion to simply drop the present related switcher in favor of the scaling switcher

MarcusMoeller wrote:What about replacing thumbnails with scaling and to drop grid?

Martin denied, repeating the reason behind the "thumbnail" switcher behavior he had already given to you in the bug 2012.

Your reaction:

MarcusMoeller wrote:Ok, then I would suggest, just to add scaling.

Andre returned, reacting on my switcher situation analysis:

Andre wrote:I'm not totally against changing State 3 (icons only) to a state where the tabbox has multiple rows. Or adding a fourth state to avoid scrolling when even the icons are too much to fit into one row.
But I would prefer not to do this here and now as I think this is an improvement which could be made later and is a bit of a taste issue.

At that point, I was absolutely sure, some external motivation existed to get this in exactly "as is" and asap. I opened a door:

luebking wrote:Unless you're in hurry because of some external force, i don't see any reason to act in a rush.

which however was not entered. You directly replied:

MarcusMoeller wrote:There is no need to change it, please just include it in the official release.

Entirely ignoring Martins general stance to not want to increase the amount of stock switchers as well as anything else.

So I went more direct:

luebking wrote:Also please notice: once upstreamed, it's no longer a pet project.
WRT Martins consideration "we should even remove all except the default one" and if discussion with HIG/VDG eg. ends up in "merge with thumbnails and grid" that will just happen, possibly even before the next release.

So basically, you're asking to intentionally clutter the git history and **** Andre, by ripping his code after feigning a merge. Sorry, but that doesn't sound like a very smart strategy to me.

Which brought your (expectable, you didn't invent that) reaction:

MarcusMoeller wrote:Concerning the general discussion, what I see is that contributions are not honoured within the project, but that's another topic. In the past, KDE was known for it's flexibility and options, but this does not seem to be the case anymore.

At which point Martin apparently had to clarify the entire "problem" again:

mgraesslin wrote:no, we just don't have concluded yet where to put the contribution. As you might notice I suggested here to remove all switchers which I implemented.

Notice: the entire time, yours and Andres part in the "discussion" was "ok, but push it upstream! ok, but push it upstream! ok, but push it upstream! if you don't push it upstream, that means you do not appreciate contribution!"
I felt like talking to a wall and -being pretty sure some subjective motivation was invoked- increasingly ****. And so far, actually nothing happened to change that mood.
(And no: that has no impact on my opinon on swichers. I won't hold a feature responsible for any persons attitude.)

colomar wrote:If e.g. Marcus and Andre at some point both lose interest in "their" switcher and nobody else wants to maintain it, it's dropped out of Plasma-Addons with its next release. As long as they maintain it, it can stay.

Actually, I see a second problem here (keeping all/many 3rd party switcher in one repo)
Should ever an API change be requried and switchers *need* an update, either Martin effectively maintains switchers (adjusting all), one switcher might hold back all plasma-addons, or switchers randomly skip releases, if one switcher maintainer is only "late" (on vacations or whatever)

Would such flip-flop (switchers dis/appear from plasma-addons, pot. frequently) be acceptable for that package?

If not, ultimately there'll be little difference to keeping them in kwin, would there?
At least, there'd be a linked release cycle.

Since maintaining in plasma-addons requires KDE commit rights anyway and there's actually nothing preventing a distro to package random extragear repos (or even kde-look tarballs , would it be better to have "extragear/kwin-switcher-foobar"? (I do of course see why kde-look tarball releases are inferior to a git repo
Iow, what would be the advantage of plasma-addons collecting 100 switchers?

luebking wrote:Since maintaining in plasma-addons requires KDE commit rights anyway and there's actually nothing preventing a distro to package random extragear repos (or even kde-look tarballs , would it be better to have "extragear/kwin-switcher-foobar"? (I do of course see why kde-look tarball releases are inferior to a git repo

Well, extragear could be a good choice for additional switchers, too, yes.
So we could either have a three-tiered solution

1. Shipping with L&F Package
2. Package from extragear
3. Installation via GHNS from kde-look

Or a four-tiered solution

1. Shipping with L&F Package
2. Indluded in Plasma-Addons
3. Package from extragear
4. Installation via GHNS from kde-look

For the four-tiered solution, we'd have to define criteria for what goes into Plasma-Addons and what into Extragear, though maybe the rules for Plasmoids could apply here as well (whatever they are).

colomar wrote:For the four-tiered solution, we'd have to define criteria for what goes into Plasma-Addons and what into Extragear, though maybe the rules for Plasmoids could apply here as well (whatever they are).

I'll bring that up in the Plasma hangout on Monday. Let's see what the other devs think about the proper way to handle it.

@luebking I did not reply to that discussion, because I think it's not meant to be discussed in the review (which martin recently realized).

Of course I got your point, to re-think the whole process, but I also think this should not lead to contributions not being accepted nor reviews not being processed in a technical manner.

I also got the point, that non-maintained addons would be dropped from the addons package, but as you can see from the review request, we have provided an updated version in a proactive manner. Besides that, I am not aware of any other request for a switcher to be included. So overall it's about what we have right now + one more switcher in plasma-addons.

Greetings
Marcus

Dear Visual Design Group,

to me there are several discussions here, maybe it helps to separate them to get a clearer view:

a) How should the request of adding one switcher to the current eight be handled?
b) How should all switchers be handled: How many do we need? Which should be included, which the default?
c) Where should they be placed/shipped from technically?
d) How do we deal with behaviour that was once officially provided and people got used to? (more general: How do we incorporate user feedback?)

Obviously, the re-appearance of the 2 years pending question of adding the "scaling thumbnails switcher" (https://git.reviewboard.kde.org/r/109832/) (Question a)) triggered a more general discussion and the other questions.
They seem worth pondering.

Maybe there is a fifth question: e) What does involvement of paid work time mean? (To answer @luebking's question from Thursday: Yes, Andre and myself are most of the time contributing on working time to KDE initiatives. Yes, we want our contributions to be included in the official releases, if this is decided by the initiative. We believe that bringing contributions upstream first is best practice in Free Software initiatives and we pursue it actively.)

My opinion on the questions:
Re a): I believe that the nineth switcher should be treated like the other eight, for better or for worse. And it should be done timely, because waiting 2 years to get something in while trying actively to maintain it is a long time. If there are conditions to be met, they should be the same for all switchers. And they should be transparent. If it takes time to come up with better conditions, all nine switchers can be treated similiar unless all can be held against the new conditions.

Re b): I generally agree that we should strive for a low number of switchers and a default that most users will benefit from. I haven't had much personal time with all switchers, so I cannot provide a good opinion on all of them. Though, when in doubt, we may provide more switchers then too less. And we should try to find a way to gather more reliable feedback, so we will able to try several variants and get measurements back. For this is should be possible to provide several switchers easily and within short reach of the users.

Re c:) I think that the main distribution should come with a few switchers, not just one, if they are matching diverse user needs. They need to be readily available if possible and maintained. If there are additional ones for our "tests", they may even come with the main distribution, but marked differently. There could be extra ones from the tiers that @colomar proposed, but in order to get b) figured out over time, I'd put the "core ones" and the one that we want to test very close to the core.

Re d): As the switchers are there to serve the users. It is users that provide the most important measure. So once a significant number of users selected a provided switcher and found it good for their workflow, we should provide them with this switcher for a considerable time in my view. This will grow the trust in Plasma that it caters for their needs. This trust is important, so they keep faithfully trying new variants when they are provided, and eventually switch to something new within their own deliberation and timeframe. This is more "pull" than "push" and usually better to win more users. I know that the "scaling thumbnail switcher" as been provided in times before SC 4.6; what I don't know is how many people tried it and got hooked on it compared to the other ones that were provided.

This brings me to e) a bit: If someone like @MarcusMoeller, who is responsible for 600 machines and their users running Plasma Workspace, is willing to invest time and money over 2 years in one particular switcher, this shows something about the size of the itch of these users. @MarcusMoeller is closer to these users than I am, and I am taking this into account.


Plasma and its handling of windows is a primary factor of user experience, to many it is "the anchor man", "the face" of KDE itself.
So thanks to everyone who is working on it, especially @mgraesslin!

Best Regards,
Bernhard

Default window switcher (sidebar) got moved to look and feel package, all other switchers are in the process of being moved to kdeplasma-addons.

Thanks all, the move of all switchers is now finished.