This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Consolidate Window Switcher Themes

Tags: None
(comma "," separated)
mgraesslin
KDE Developer
Posts
572
Karma
7
OS

Consolidate Window Switcher Themes

Thu Oct 23, 2014 9:18 am
Hi VDG,

currently KWin is offering several window switcher (alt+tab) themes pre-installed. Several of them are very similar and the quality is not the best to be honest. Recently we got a request to add another one, which is again very similar to already existing ones. And that triggered us thinking about whether we should consolidate the available themes.

What is your thought on it? Should we be open to add more and more or should we maybe go down to one default theme and offer more themes through 3rd-party installation?
User avatar
jensreuterberg
Registered Member
Posts
598
Karma
3
OS
Now this is just me - but one of the issues I have with window-, as well as workspace-, switching in Plasma is that it visually separates the user from the shell. It is a bit like the systemtray thing, the ideal should be that it should feel as "one solid thing". Not a secondary object that resides outside of the desktop shell. You want that feeling of effortlessness or weightlessness when using the shell to controll and handle applications.

So when the window switcher is directly cut off from the workspace switcher, when the animations differ-by-default (if they differ after user edits, that is all good of course), we get that jarring sensation of it being cut off.

So what I propose is to look at the goals of the unified system tray, the way activities are handled and try to model a window AND desktopswitcher on that. Yes repetition is boring BUT the shell is supposed to be a little bit boring. Its ment to feel natural as breathing (by DEFAULT, again a user should be able to edit it into a massive thing).


KDE Visual Design Group - "Sexy by default - Powerful through cooperation"
mgraesslin
KDE Developer
Posts
572
Karma
7
OS
Jens, what you bring up is IMHO already solved: the default switcher is "SideBar" which is intended to be integrated in the shell by using the same area as other shell components like adding widgets or switching activities.
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
mgraesslin wrote:Should we be open to add more and more or should we maybe go down to one default theme and offer more themes through 3rd-party installation?

We should provide a couple of real alternatives, but not too much and not too similar ones. And we should have an easy "3rd party installation" procedure. The question was raised as well in one of our last VDG meetings, but with no clear result IIRC.

BTW: kdeartwork-wallpapers contribute with +140MB to the update process.

Last edited by Heiko Tietze on Thu Oct 23, 2014 3:37 pm, edited 1 time in total.
User avatar
MarcusMoeller
Registered Member
Posts
9
Karma
1
It seems to have a good default, is never a bad idea. But a bunch of alternative options also is not bad (and in the past, this was the strength of KDE). So being able to select from a number of window switchers, offers the ability to users to choose what matches best to them. There is no 'one ring to rule them all'.

For me, it's more about the way how they are included. My favorite option is to have them included in kwin as long as they are maintained. 3rd party repository suck, at least the way they work at the moment. If the extension repository is provided by the KDE project itself (as like extensions.gnome.org), including integrity validation during installation, it could be an option. kde-look is broken, at least for including code. It's plain http without validation. Besides that plasmapkg does not seem to work right now, but that's another topic.

Concerning the current review request: https://git.reviewboard.kde.org/r/109832/ - we are talking about one more switcher to include. It differs enough from others to make it unique and offers some features the others are missing. This has been discussed for more than a year now.
User avatar
andreas_k
Registered Member
Posts
561
Karma
0
I'd like Jens idea of a plasma shell. When you look at gnome, the shell is more consistent and present than in kde. And all the time plasma looks different.

Would it be difficult to use opendesktop.org (GHNS) for that. the main problem there is only when you want to install it and the installer tald you go to the webpage.
ber
Registered Member
Posts
3
Karma
0
OS
The switcher in question to be added (https://git.reviewboard.kde.org/r/109832/) is one that aims to provide a behaviour that many users have been accustomed to for a significant period (as far as I can see before KDE SC <4.6). In general: If users learn a specific behaviour their usability backpack gets larger.
Plasma - like any application - should give users a choice to select their known behaviour and thus support those switchers that habe been popular,
especially if this can be done with reasonable effort. Otherwise there is the danger that users will miss out and get frustrated.

Now there is a patch to establish the old behaviour again as option, user satifaction can only grow by picking it up.

(Disclosure of interests: I work with Andre and we have been contracted to port the old behaviour of this specific switcher to 5.1. So there are users that deeply care for the old behaviour.)
kdeuserk
Registered Member
Posts
207
Karma
0
Outsourcing the window switcher is imho a certain death for them (especially with the current situation of providing plugins). Things will break and the devs wont notice/care since it is 3rd party.
Gnome is also customizeable if you want, just that the core is small and everything else has to be provided through 3rd parties. I find that approach very messy since things break all the time and the providers of the extensions have always to catch up.
Imho the only way to guarantee they will work in the future is keeping them. Outsourcing them will decrease their quality even more. If no dev cares for the switchers now, even less devs will care for the third party switcher.
User avatar
Heiko Tietze
Registered Member
Posts
593
Karma
0
OS
Do we talk about the switcher only, or is it about a general approach what/how much KDE delivers by default?
mgraesslin
KDE Developer
Posts
572
Karma
7
OS
kdeuserk wrote:Outsourcing the window switcher is imho a certain death for them (especially with the current situation of providing plugins). Things will break and the devs wont notice/care since it is 3rd party.


What makes you think we would notice currently and that we would have the manpower to fix them?
mgraesslin
KDE Developer
Posts
572
Karma
7
OS
Heiko Tietze wrote:Do we talk about the switcher only, or is it about a general approach what/how much KDE delivers by default?


we can talk about the general approach, but please don't turn this into a bike-shedding discussion :-)
User avatar
alake
Registered Member
Posts
591
Karma
3
OS
I wasn't aware there was a window switcher theme mechanism. Huh, learn something new every day.

One thought I had is that we're accumulating a lot of independent theming capabilities for different parts of the desktop environment. While I'm all for capability and flexibility, there are consequencies. One of which is producing and maintaining cohesive, consistent visuals either by default or by option. At the very real risk of of being accused of removing functions, would it be ok if I suggested that we start working towards reducing the number of independent theming mechanisms?

So specifically to your question Martin, is it possible for the window switcher theme to just use visuals from the plasma theme?
luebking
Karma
0
alake wrote:So specifically to your question Martin, is it possible for the window switcher theme to just use visuals from the plasma theme?

That happens anyway (at least the stock switchers import plasma components)

The switcher "theming" system is less a "themeing" system but more a "layouting" system.

Window 1
Window 2
Window 3

[ ICON 1 ] [ ICON 2 ] [ ICON 3 ]
Window 2

[ THUMNAIL 1 ] [ THUMNAIL 2 ]
[ THUMNAIL 3]

The layout is done in QML and *can* abandon plasma components, what might be interesting for KWin as lxqt WM.
luebking
Karma
0
ber wrote:(Disclosure of interests: I work with Andre and we have been contracted to port the old behaviour of this specific switcher to 5.1. So there are users that deeply care for the old behaviour.)


Please confirm or deny:
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.
User avatar
alake
Registered Member
Posts
591
Karma
3
OS
Thanks much for the explanation luebking.

To try to answer Martin's question then, I'm in favor of:
- a set of about 3 window switching layouts selectable from a window behavior kcm (a simple droplist is fine).
- A sensible default - the current default is fine I think.
- No 3rd party run-time installation.

Hope this helps. :-)


Bookmarks



Who is online

Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan