Does this mean that the extreme eagerness to get this very specific switcher (as shown by some people) into KWin upstream (and not eg. a migration of this an other approaches to get a better scaling switcher by default) might be related by the fact that sombody actually pays to get his very pet into upstream??

In case, thanks (seriously, I appreciate that) for being the first one to actually find the balls to say so.

@Thomas what's wrong in paid development?

Concerning the fact to get a better scaling switcher default, the new switcher could easily replace thumbnails, but Martin does not want it. And just to confirm, when we talk about pets, I think about my little dog, not contributions to Free Software projects.

I think we should only include fundamentally different approaches to window switching (and anything else). These should be configurable / individualizable (is there a word like that?). This way we should be able to keep all current options, as similar approaches have to be merged.

alake wrote:- No 3rd party run-time installation.

that's not possible. 3rd-party installation is something we technically cannot remove. We could remove the GHNS button, but it wouldn't disallow installing manually. Also I don't think it's a good idea. Having the possibility for multiple switchers was one of the design decisions for the switching architecture from the start. Window switching is not something we can have one good UI which suits all users. Whether the UI is suited depends on: number of windows, user workflow, screen size, etc. Not allowing 3rd-party installation would limit the possibility extremely. And I don't want to go into that - I had disappointed users in the past and they were all quite glad they could just "fix" the switcher to get it the way they like.

Couldn't these Window Switcher Themes be included in the Look & Feel Packages ? I was under the impression that in the future, these packages would provide different "user experiences", and that tweaking individual theme components (icons, application theme, plasma theme, etc...) would be considered as advanced options. If so, I don't see a problem with having a 3rd party system. Most "casual" users would only select a Look & Feel Package, and only users who really want to fine tune the appearance of their environment would go in KWin's KCM. Simple by default, powerful when needed, right?

AGuiFr wrote:Couldn't these Window Switcher Themes be included in the Look & Feel Packages ? I was under the impression that in the future, these packages would provide different "user experiences", and that tweaking individual theme components (icons, application theme, plasma theme, etc...) would be considered as advanced options. If so, I don't see a problem with having a 3rd party system. Most "casual" users would only select a Look & Feel Package, and only users who really want to fine tune the appearance of their environment would go in KWin's KCM. Simple by default, powerful when needed, right?

Exactly that (and I assume this is also what Andrew would like): Each Look & Feel theme would come with an associated window switcher which is consistent with the rest of it. Users are still free to change the window switcher (kust like tey can tweak other individual look and feel aspects), but we'd assure that by default, people get a consistent experience.

of course look'n'feel packages could provide the window switcher. It just means installing the theme at the right place and configuring KWin and triggering KWin into reloading it's configuration.

So I think that only the window switcher themes that are used in the default Look&Feel packages should be included, and the others can be installed through GHNS.

mgraesslin wrote:of course look'n'feel packages could provide the window switcher. It just means installing the theme at the right place and configuring KWin and triggering KWin into reloading it's configuration.

Good to hear!

AGuiFr wrote:So I think that only the window switcher themes that are used in the default Look&Feel packages should be included, and the others can be installed through GHNS.

Sounds like a sensible idea to me.

colomar wrote:

AGuiFr wrote:So I think that only the window switcher themes that are used in the default Look&Feel packages should be included, and the others can be installed through GHNS.

Sounds like a sensible idea to me.

Also to me. Expcept that I don't want to host "my" themes on a proprietary platform. So I might also go for adding them to plasma-addons and making it possible to install them with package manager.

mgraesslin wrote:Also to me. Expcept that I don't want to host "my" themes on a proprietary platform. So I might also go for adding them to plasma-addons and making it possible to install them with package manager.

I don't think anybody would have a problem with that

MarcusMoeller wrote:@Thomas what's wrong in paid development?

I can only speak for myself:
---------------------------------------
- pay to get an approved bug fixed: totally fine
- pay to have an approved feature implemented: totally fine
- pay to generelly improve things: totally fine

- pay to nag others to get a very specific feature/implementation approved: bad
- pay to do that on a deadline, nagging around quality checks: extra bad

- being paid to nag others to get a specific feature/implementation approved and not even mention the background: disgusting fail of character period.

I rank the latter three as treason, because you put your personal profit against the benefit of all others.

About the switcher:
- I'd agree that "thumbnails" is not an ideal switcher
- I cannot finally decide whether "scaling" is any better
- I'm dead sure it's not an ideal solution either. And I give a **** on any contracts in that regard.

AGuiFr wrote:So I think that only the window switcher themes that are used in the default Look&Feel packages should be included, and the others can be installed through GHNS.

Agreed. In addition one might want to name them significalty "Breeze default switcher" or similar. (And indeed "protect" the "breeze" tag)

mgraesslin wrote:Expcept that I don't want to host "my" themes on a proprietary platform. So I might also go for adding them to plasma-addons and making it possible to install them with package manager.

Mind to elaborate on this?
Afaics, MarcusMoeller's claim is wrong - GHNS seems to have infrastructure for hash checks, but if there's an actual concern for GHNS hosting that applies to you, it will/should apply to others as well, yesno?
And while it's oc. the maintainers privilege to add the features he prefers, this seems a questionable stance ("GHNS is good enough for you, but not for me")

I'd frankly prefer to get rid of the GHNS defects then, eg. could we add a repo server to the GHNS servers list or would it be sufficient to extend GHNS entries with a "signed-off by" tag to indicate peer review?

luebking wrote:Mind to elaborate on this?

sure

luebking wrote:Afaics, MarcusMoeller's claim is wrong - GHNS seems to have infrastructure for hash checks, but if there's an actual concern for GHNS hosting that applies to you, it will/should apply to others as well, yesno?
And while it's oc. the maintainers privilege to add the features he prefers, this seems a questionable stance ("GHNS is good enough for you, but not for me")

I'd frankly prefer to get rid of the GHNS defects then, eg. could we add a repo server to the GHNS servers list or would it be sufficient to extend GHNS entries with a "signed-off by" tag to indicate peer review?

There are a few things I don't like about it: missing git repositories, missing possibility to push bug fixes, missing possibility to have something like version checks, etc. etc. Given that I'd prefer to have them in a kde-hosted git repository just for code management. If we have that we can also release it together with rest of Plasma and get version checks and updates for free. Obviously I would such a solution not restrict to my own swichters, but would be fine to accept more there.

And of course: if we had a better way to distribute (e.g. if there ever were a Bodega server hosted by KDE) I would prefer that for distributing.

I can only speak for myself:
---------------------------------------
- pay to get an approved bug fixed: totally fine
- pay to have an approved feature implemented: totally fine
- pay to generelly improve things: totally fine

- pay to nag others to get a very specific feature/implementation approved: bad
- pay to do that on a deadline, nagging around quality checks: extra bad

- being paid to nag others to get a specific feature/implementation approved and not even mention the background: disgusting fail of character period.

Noone is paying someone to raise voice for something. What Andre and others stated is their own personal opinion.

About the switcher:
- I'd agree that "thumbnails" is not an ideal switcher
- I cannot finally decide whether "scaling" is any better
- I'm dead sure it's not an ideal solution either. And I give a **** on any contracts in that regard.

It's your personal taste that you do not find scaling any better. It has some advantages that I lined out several times which you might not want to see.

What I agree on is having code on an external platform as the one we have right now, might not be the best way to distribute code. It also gives me the feeling of isolating contributions (no we don't want to have that ... in here). I welcome the idea of having them in plasma-addons.

Greets
Marcus

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