Reply to topic

A Classic twist to the Breeze window control icons!

paulm
Registered Member
Posts
42
Karma
0
OS
I think Breeze is beautiful, however, I have outlined elsewhere where I think there are serious usability issues with the current Oxygen-style window control icons still used in the Breeze theme.

These issues annoyed me so much every time I looked at a Plasma window that I created a fork of the breeze library at https://github.com/paul4ig/breeze to try and implement a design which would try to address most of these issues.

Here is a screenshot of my design which I have called "Classic" for now:
Image

Here is also a video of my code in action. As you can see, my code affects both the kdecoration library (for the window decorations) and kstyle library (for dockable panels within applications) -- I refactored slightly for a common code base for the icon style between the two (it is currently just copied and pasted code).

The "Classic" look should be familiar to any KDE aficionado as they are partly inspired by the window decorations used in KDE 1, hence the "Classic" name. Here is a screenshot of the 20-year-old-this-year KDE 1.1 for reference:
Image

Here is the window decoration configuration on Redhat 4, KDE 3.3, where options for "KDE 1" and similar (but uglier IMO) "KDE 2" were given (now missing in Plasma 5):
Image

My "Classic" design is not identical though, as I kept the diamond "restore" icon from Oxygen. The original KDE 1 theme, as well as CDE, used an embossed/engraved styling to switch between maximized and restored windows, but I do not think this makes clear which is which and hence wanted to distinguish. The only problem, however, with the diamond is that, unlike the other window control icons, it doesn't have a direct visual mapping of the function. I like the "diamond" though because it looks elegant and if you instead think of it as a kite it reminds you of "floating" -- I think "float" would be a better descriptive term than what most desktop environments call "restore" (what you are "restoring" to depends upon context and will not always restore). I have no idea if this is what the original designer of the Oxygen icons was thinking!
(while I am on this topic, it reminds me that there are also no tooltips in the current Breeze implementation -- I think it would be a good idea to add them as "Minimize", "Maximize"/"Float" and "Close").

I also added a new configuration item to the Breeze Window Decoration settings called "Button icon style" to allow you to choose between Classic and the existing Oxygen style if you wish:
Image
You can still toggle the option of "Draw a circle around close button" if you wish, but I feel this adds too much distracting visual clutter if used with the "Classic" design.

While I was at it, for those who want familiarity, I also created a third "Redmond" Breeze sub-style which gives a much fresher and more modern Windows-like style than the outdated and ugly (IMO) "Plastik" Windows-XP-inspired theme:
Image

I would be great if you could include my code in a future release, at least to give people the options. I do feel though that "Classic" would make a better default than the existing "Oxygen" style as addresses most of the issues I have listed, viz:
1. There is a direct visual mapping of the function of the buttons. Minimize = make compact without window = compacted square. Maximize = make window into large square. The exception is the restore/float diamond/kite but I have explained why I still like this above.
2. It is now obvious that maximize and minimize are not direct opposites of each other. All have clear and distinct icons.
3. We no longer use yet another (!) arrow. The window controls now do not look like they signify "move down" and "move up", nor does minimize look like a drop-down menu which is likely to occur frequently in the window titlebar with the upcoming client-side/dynamic window decoration plans.
4. Not all users have their panel/taskbar at the bottom of the screen, especially with the advent of horrible 16:9 widescreen displays. The existing Breeze minimize icon points downward. The "Classic" minimize button is more universal.
5. Last but not least, it gets rid of that horrible Windows 3.1 vibe, and has a unique and less cluttered looking style with true KDE heritage!

What do you think?

Paul
hugo.pereira@free.fr
Registered Member
Posts
133
Karma
0
Hi,
Nice work.
I like your "classic" buttons
how did you deal with the "shade", "unshade", "stay on top" and "stay below" buttons ?

Hugo
paulm
Registered Member
Posts
42
Karma
0
OS
hugo.pereira@free.fr wrote:Hi,
Nice work.
I like your "classic" buttons
how did you deal with the "shade", "unshade", "stay on top" and "stay below" buttons ?

Hugo


Hi Hugo,

I just left those the same as they were. My main concern was to get rid of the over-used and ambiguous single arrows.

"Classic":
Image

"Redmond":
Image

I think the shade/unshade is one place where the arrow is appropriate as the window body actually does move, so is probably good to keep shade/unshade as they are.

However, now that you have mentioned it, I think the "keep above" and "keep below" need to be looked at further. I see three issues with them:

    1. First of all, I think they are named wrongly -- in English it would be more precise to rename these functions "keep in front" and "keep behind" as they do not move the windows to the top or bottom of the screen.

    2. The double arrow, while being more distinct than the much used single arrow, still has not got a clear visual meaning and could imply docking to the top or bottom of the screen or something.

    3. The icons are not consistent with the application icons in the breeze-icons set for a similar functionality ( object-order-front and object-order-back ). These are perhaps too busy for use in every application titlebar, though I see LibreOffice uses slightly simplified versions (lc_bringtofront/sc_bringtofront and lc_sendtoback/sc_sendtoback):
    Image

    Microsoft, on the other hand, uses more literal icons that visually represent in-front/behind rather than top/bottom so something along those lines may be better:
    ImageImage

    I will do some experimentation and post back...

Last edited by paulm on Sun Jan 29, 2017 9:04 pm, edited 2 times in total.
hein
KDE Developer
Posts
67
Karma
1
OS
paulm wrote:
hugo.pereira@free.fr wrote:1. First of all, I think they are named wrongly -- in English it would be more precise to rename these functions "keep in front" and "keep behind" as they do not move the windows to the top or bottom of the screen.


The spatial metaphor chosen (which is reinforced by terms like Raise and Lower, which are also used throughout the UI) is in line with the desktop metpahor in general, where a piece of paper is also "above" or "on top of" others on a desk. It's further reinforced visually by the window shadow system, via the focused and topmost window receiving a larger shadow, suggesting greater verticality. It wouldn't be possible to change this to front/behind without changing the rest to keep a holistic theme going (which extends into applications, with very common strings like "Always on top" in many a video player).


Plasma, apps hacker. KDE e.V. vice president. Blue Systems, CTO.
paulm
Registered Member
Posts
42
Karma
0
OS
hein wrote:
paulm wrote:1. First of all, I think they are named wrongly -- in English it would be more precise to rename these functions "keep in front" and "keep behind" as they do not move the windows to the top or bottom of the screen.


The spatial metaphor chosen (which is reinforced by terms like Raise and Lower, which are also used throughout the UI) is in line with the desktop metpahor in general, where a piece of paper is also "above" or "on top of" others on a desk. It's further reinforced visually by the window shadow system, via the focused and topmost window receiving a larger shadow, suggesting greater verticality. It wouldn't be possible to change this to front/behind without changing the rest to keep a holistic theme going (which extends into applications, with very common strings like "Always on top" in many a video player).


Except there isn't a single consistent "chosen" spatial metaphor for Plasma at all. The most common definition of "top" and "bottom" in Plasma actually corresponds to the vertical orientation of the overwhelming majority of displays. Here are just some of the first examples I came across:
Image Image
Image

I don't see how the window shadow system enforces any particular spatial orientation. All it shows is a light source to the top(!)-left. A light source can be lamp or bulb or anything.

Regardless, the main advantage of the terms "in front of" and "behind" in English is actually that the modelled spatial orientation/plane does not even matter -- the user does not even have to think about it as it is relative to the viewer. "In front" can refer to "the part or side that normally first presents itself to view" (Oxford dictionary, context 2) and "behind" "At or to the far side of (something), typically so as to be hidden by it". The reference plane could even be to the ceiling, and whatever object is visible and facing the viewer can still be "in front" and whatever can be obscured to the viewer by other objects would be "behind".

Such a clearer change in terminology therefore doesn't change the "holistic theme" at all since we are now simply describing what is/is not in direct view to the user rather than referring to a particular abstract spatial orientation. I can only see 2 strings that would be affected -- the Alt-F3 menu and the "look and feel" "Buttons" configuration (there really should be tooltips on the window decoration buttons too, but this does not seem to have been implemented).

As for video players, I have 3 installed and only see "on top" in VLC, most likely simply copying the terminology used in KDE rather than anything else -- such an option really isn't necessary in KDE given the Alt-F3 menu anyway. Other applications, such as every Office suite I know of, use "in front" and "back" to refer to objects moving in this plane. Then we can look at the usage of terminology in web applications -- just look to the bottom of this very web page!!!:
Image

Regardless, third-parties will always have small inconsistencies. It is surely more important that Plasma is consistent with itself.
hein
KDE Developer
Posts
67
Karma
1
OS
FWIW, the scrollbar context menu is coming from Qt (which in turns copies this from Windows), not a Plasma design (but way to go on the hunting).


Plasma, apps hacker. KDE e.V. vice president. Blue Systems, CTO.

 
Reply to topic

Bookmarks



Who is online

Registered users: abury, Baidu [Spider], Bing [Bot], brodie, capslock, Clancularius, Exabot [Bot], Google [Bot], Majestic-12 [Bot], mcoudert, migueldolz, szutmael, the_flyingangel