Kver wrote:From what I understand about Wayland and CSD pinging, Wayland will check to see if a program is responsive every time you attempt to interact with it, and then offer a failure fallback if the application fails to respond.

LOL.
A "don't write broken ****" protocol. That's gonna be some fun! =)

This would of course allow to detect hung clients, but is just as much not an option for X11 (because we can neither passively grab the active client -for "some" toolkits tend to react in a bad way-, nor can we assume that clients don't use sync I/O -including dbus- or "slow" routines in the GUI thread)

Kver wrote:maximise and minimise are still capable of functioning.

It's never been an issue of "functioning" - the problem would be to induce this from the titlebar buttons. (Once the WM knows that the window shall be manipulated, eg. from a taskbar or any other 3rd client, it can of course act accordingly even if the client is hung)

Kver wrote:In my opinion though, designing around failure cases

What I declare to be not the case here. The WMs foremost job is to allow the user to mange his windows (as the name suggests
It has to be capable of doing so regeardless whether the client has a bad day - and given the amount of bugreports where users accidentally killed the kill helper (and back then kwin with it) on attempting to kill a hung client: that's not a rare occasion at all.
If it cannot provide this, it has simply failed its job.

Kver wrote:building a well-designed library

What will not happen - there will be librarieS.
Gtk+ now considers GNOME and its workflow the primary target system and everything else close to irrelevant [1]
Also, application developers *will* take the opportunity to ensure the user knows that this is a "VERY SPECIAL APPLICATION, AS YOU CAN SEE!!!", ie. bring their custom look (as somehow seems to be encouraged by QML anyway) and feel (*me* will btw. dictate a Platinum style titlebar button layout, just like chromium dictates a windows like layout :-P )

Proof? Look at the Windows desktop.

[1] http://lwn.net/Articles/562856/

Excellent idea Kver, and very well presented and argumented. Actually, I think this deserves more than a simple thread, a dedicated section should be created ; each idea being a thread.

Concerning the debate about client-side vs. server side decoration, I see very little advantages to CSD. I think for all the pros of CSD, there is at least a similar solution with SSD, while preserving all the advantages SSD has over CSD.

Kver wrote:Applications would waste less space on screen; for small laptops this is a significant advantage.

On small screens, I tend to maximise my windows, or make them use half the screen if I want to do two things at the same time. You can configure SSD to have a special behaviour when the window is maximised. In Plasma Netbook, when a window is maximised, the titlebar is removed and the close button moves to the top bar. This is also the case in Ubuntu's Unity.

Kver wrote:The decoration can be placed on any side. Applications like a movie player could hide decorations completly

I don't think this is a real advantage. Your mockups look nice, for sure, but I am quite sure someone trying your media player or your pdf reader for the first time will not know how to close it. Even on Windows where CSD are the norm, the close button remain in the top-right corner in all applications. CSD mainly gives more freedom to the designer to make more beautiful UIs, but I think the constraints you have for preserving usability keeps you from taking full advantage of it. As for the example with the media player, I don't think it would make sense from a usability point of view. If you want to focus on the movie, you make it full screen and all the chrome will disappear. If it is not full screen, how can you move it around without a title bar ? Either a title bar would appear when you hover on it, which you would grab to move the windows, or you can move the window by holding your mouse anywhere in the area, in which case you would loose the ability to pause the movie by clicking on it, common to many media players. For me, both solutions seems to provide no improvement over having a title bar. But maybe you had something else in mind.

Kver wrote:Applications with a full-screen mode may just use the same chrome in full-screen, maintaining placement of close/minimise/maximise buttons.

Apart from video players and games, I never use other applications (e.g. browser or word processor) in full screen mode. Actually, I don't see any advantage to maximised. In OS X it seems to be common, but OS X doesn't have a maximised mode which makes the application take the whole screen, so it makes sense there. For Plasma, full screen mode seems to me a corner case.

Kver wrote:A strong CSD protocol/library could ensure reliability

This is not a pro, but a mitigation of a con. SSD already ensure visual consistency and resilience to crashs.

One "pro" I would add that you didn't include is that, from an average user perspective, the top of the window is part of the application, and the separation between application theme and window decoration theme doesn't make sense for them (especially when they blend like for oxygen in KDE 4.x). CSD force to use a unique application theme. But once again, this is easy to solve while keeping SSD.

luebking wrote:

Kver wrote:From what I understand about Wayland and CSD pinging, Wayland will check to see if a program is responsive every time you attempt to interact with it, and then offer a failure fallback if the application fails to respond.

LOL.
A "don't write broken ****" protocol. That's gonna be some fun! =)

I didn't really understand the point you're making... Could you elaborate to someone who is not knowledgeable about window management?

luebking wrote:This would of course allow to detect hung clients, but is just as much not an option for X11 (because we can neither passively grab the active client -for "some" toolkits tend to react in a bad way-, nor can we assume that clients don't use sync I/O -including dbus- or "slow" routines in the GUI thread)

As far as I've understood no one has been suggesting using CSDs under X anyway (in this thread).

I didn't really understand the point you're making... Could you elaborate to someone who is not knowledgeable about window management?

This doesn't relate to windowmanagement
A requirement to *always* be responsive to input events effectively forbids to implement synchronous I/O or any kind of (even potentially) slow functions in the GUI/main thread. One might use an off-thread event reader that does also perform the pong and queus event forwarding to the main thread, but that does in a way of course defeat the idea of the ping/pong protocol.

-> This will require quite some porting efforts in several applications, but since sync I/O is bad style anyway (though very often used out of lazyness, I don't except myself here), the wayland protocol will implicitly forbid to "write broken ****™". It will also cause some swearing

As far as I've understood no one has been suggesting using CSDs

Yes, I've simply more or less confirmed Kver's research and implications on this.
To rephrase:

This would work on wayland, not because wayland provides a better system to detect a hung client, but because the wayland protocol would deem "looks like hung, but is not" a bug.

Now that I've successfully started a fire with CSDs, it's time to change gears;

What if... Plasma Used Launchers from Other Systems & Enviornments? (Part 1)
Forward
KDE and Plasma has several methods of launching programs; simple list menus, quick shortcuts, powerful multi-component menus, and task 'pinning'... Command line. Plasmas' default setup is to use two of these in tandem; 'task pinning' and multi-component menus.

Other enviornments tend to use the same methodology, but usually with far less configuration options. Windows, for example, often allows pinning applications as quick launchers, and a multi-component menu. Apples' OSX takes a different approach, using a multi-component quick-launcher (the dock) and opening components via the file manager. Elementary OS takes a middle-road having a multi-component dock, and a simple launcher. Gnome uses a multi-component dashboard which serves as the 'nerve center' for application launching and managment.

For the sake of brevity (hahah! Like that'll happen!), part one of this what-if will focus on Elementary OS; in addition to looking at launchers, the overall feel of the systems will also be breifly explored and discussed separatly.

What if... Plasma Used Launchers from Other Systems & Enviornments Elementary OS?
Elementary OS is a distrubution of Linux which makes used of a highly customised desktop shell called "Pantheon", which origionally started as a set of modifications to the Gnome desktop. It consists of a panel at the top, and a dock at the bottom. While visually similar to Apples' OSX, Elementary aims for a mono-tasking approach on all actions, and has a simpler approach to task/application launching and managment.


Click to Enlarge - by Softpedia

I'm going to mention "Mono-Widgets", "Compound Widgets" and "Multitasking Widgets" several times; this is because my analysis of KDE/Plasma and Elementary presented the need for some vocabulary.

• When I refer to Mono-Widgets, I'm referring to a widget which performs only one operation. For example, the Elementary Launcher very stricly finds and launches applications. It does nothing else, and dismisses itself when the single task is complete.
• Compound Widgets perform several functions, but when a user enters a compound widget they only do one thing, then the widget exits. They only ever use one part of the widget per invocation. KDE Launchers fall into this category, bundling power, application, search, recent documents, places, favourites, and other functions into one area; however you only ever do one at a time, and then the widget dismisses itself.
• Multitasking Widgets are widgets where you'll enter them, work on a task or two, and eventually dismiss them when you are finished. For example, the network widget will have you create, modify, update, select, and delete networks and basic network settings. Where this differs from Elementary is that Elementary will only list existing networks, opening a separate program to edit them.

Comparison to KDE/Plasma:
EOS desktop components such as the Plank (the dock), and Slingshot (applications launcher) are extreme mono-tasking widgets, simplifying the work-flow substancially but also necessitating more individual widgets. A good example of this is the exclusion of power options in Slingshot, but the addition of a power widget on the far side of the panel. Ironically, KDE contains a much more comprehensive legion of widgets, many of which mono-task similarly to Elementary widgets - but instead Plasma defaults to compound widgets and multitask widgets.

Elementary supports minimal customization options out-of-box. Because they have chosen to avoid customization Elementary must approach their static configuration wtih much more dicipline. Combined with their minimal approach, there's a distinct feeling that every UI element added was harshly scrutinised before inclusion. Elementary almost never hides UI elements in their desktop enviornment; if a widget would not have space to include all the options necessary, it will instead attempt to include the options for most use-cases and provide access to a more comprehensive application. On the other side, Plasma widgets don't tend to launch applications.

"Simple by default, Powerful when needed"
The Plasma default layout tends to focus on displaying fewer compound widgets which rely on more robust configuration. Compound widgets come with all functionality enabled by default and tend to be "configured down" in a way that users must pick what they don't want; this is directly counter to "Simple by default". Elementary on the other hand has exceptionally focused mono-tasking widgets, but no configuration options. In other words, Elementary meets the first half of the mantra (Simple by default), but the plasma desktop acheives neither (Powerful when needed)


Click to Enlarge - KDE-style Plasma Panel, Elementary Launcher

Widgets in plasma which do focus on mono-tasking (such as the calendar) tend to have a higher focus on design, and are exceptionally intuitive. KDE developers could and should investigate the creation of more mono-tasking widgets for areas currently dominated by heavy-duty compound widgets. Developers chould also re-investigate the default layout after mono-task widgets are complete to relegate much heavier widgets to configuration options. By packaging simple widgets into the default configuration and keeping heavier widgets as options KDE would further acheive the "Simple by default, powerful when needed" mantra.

The best example may be the Kickoff launcher which features favourites, applications, places, recently used files, account info, search, and other options. Some of these exist in other widgets, and the launcher could be forked into its remaining contituent parts; a launcher, a recent files widget, a computer widget, an account widget, etc. Plasma fails in intuitivness when it packs this functionality into a widget and hides some components to keep the design clean such as hiding search in its launcher - where Elementary refuses to hide any feature. While this makes individual plasmoids powerful, it actually reduces the functionality because an undiscovered feature really doesn't exist to people who haven't found it.


Click to Enlarge - Elementary styling takes over

Technical Challenges
If KDE were to attempt to lean towards an Elementary setup the largest hurdle would not be the addition of features or new monotasking widgets, but instead the streamlining of the desktop and its options into a functional, streamlined, and focused desktop without upsetting its user-base. This is less of a technical problem and more of an emotional one: KDE users tend to worry when applications become 'dumbed down' despite the fact that functionality remains. Granted, Marco Martin has done some fantastic work which eases operations like the swapping of widgets, so the road to quickly allow users to reconfigure to more complex setups has been paved.


Pros

• Elementarys' static structure requires far less cognative throughput on its users
• Mono-widgets are lightweight, and visually more appealing. They have high discoverability.
• Mono-widgets are simple to understand and intuitive. Search will want you to type something. Launching opens applications.
• Configuration options which do exist are easier to understand, and will likely be better understood.
• Elementarys' highly diciplined approach packs similar functionality into a much smaller package

Cons

• Mono-widgets are functionally a step back.
• Each mono-widget requires a way to get to it, pushing complexity up the UI to areas like the panel.
• Sometimes operations are complimentary or highly similar, and that is lost in mono-tasking. For example, a launcher search and a file search are highly complimentary.
• Mono-tasking can result in a "good enough" experience where widgets get the job done, but sacrifice power and convienience.
• Mono-tasking can make an otherwise capable tool feel oversimplified or underpowered.

Extra widgets would need to populate panels for a mono-widget design

Notes
In Plasma, default widgets should enforce a minimal configuration by default to present core functionality first, then allow users to "configure up". For widgets added to the system via configuration tools, we should remain with the "configure down" approach to expose funcitonality when a user adds a (presumably) unknown widget. This is much more in-line with the "Simple by default, Powerful when needed".

While Elementary is considered Linuxs' most "elegant" desktop, KDE has more technology to quickly and easily iterate. KDE5/Plasma5 makes far better use of text and design elements, and actually feels more "designed" compared to Elementary in some areas; when you inspect an individual widget in Elementary they can be surprisingly utilitarian and uninsipred. The calendar is a prime example of where KDE has more visually appealing design. When Elementary Freya is released, I have no doubt that if KDE/Plasma developers hunkered-down and focused on design, we could "out-Elementary" Elementary by their next release.


KDE always needs a menu widget for usability reasons

On the inverse, KDE developers tend to lean towards "proper" system-level design, making them less willing to make technical exceptions for strictly design reasons, or at least slow KDE design down while better methods are engineered. This is not a bad thing. For example (as far as I know) KDE will not kludge in code to make docks adjust their colours based on wallpapers; but when similar functionality eventually does hit, it will be done in a way that is technologically superior, where plasma theme designers could easily tap well-designed APIs. Often, this comes down to the "glue" libraries used by KDE when adding APIs to QML.


An icon-sized desktop switcher is easily embedded as a plasmoid. | Activities are an unknown hallmark of KDE

Overall, technology-wise, KDE is capable of easily out-designing Elementary OS in a sustainable way; but where KDE has Technology Elementary has tenacious focus and dicipline we should learn from. They don't try to please everybody, and perhaps KDE/Plasma shouldn't try either. Focusing on a simpler default desktop enviornment and having power-users configure-in more powerful widgets where they want it may ultimately be a better model; power-users can be expected to "configure up", but casual users won't "configure down".

Chime in!
What are your thoughts on Elementary OSs' design merits? What did I miss, any addendums? Let us know!
The next What-If I'll be addressing is: "What would a Windows 10 Menu look like in Plasma?"

I wonder how many people uses Kickoff (probably many since it's the default) or switch back to KMenu. I guess most KDE-ians launch apps per KRunner, which is a "mono-widget" in your terminology. And KDE provides Lancelot above all...

As an editorial note: Don't you want to split this thread into separate postings?

Speaking as a former Gnome user, I'm now comfortable with the huge number of configuration options & settings in KDE and now get the fact that just because KDE has options that i'll never use, it doesn't mean that i shouldn't be using it - I just don't fiddle with what i don't know about. One of the things that infuriated me about Gnome was that it was simplified and felt very restrictive & 'locked down', it felt like 'you do things our way or not at all' - you have to admire their vision and single mindedness but that's not for me.

A trivial example to illustrate my point - in their basic mp3 ripper Sound Juicer you could only select from a very limited number of file naming options, none of which were what i wanted and there was no hint at all that you could configure things differently if only you knew how, nothing! In reality you could install either Dconf or Gconf editor & tweak it in there, the same as the flac quality settings, paranoia mode etc. etc but the user had no way of knowing that. In contrast, using K3b for ripping, the file naming, flac quality settings, paranoia mode etc. etc are all very easy to configure and that's perfect.

I agree that having all the options exposed at once might not be the most welcoming setup for new users and doesn't fit in with 'Simple by default' at all. What about going for a simplified basic setup (simple mono-widgets), but have an easily accessible thing (an entry in the widgets right click menu for example) effectively saying 'show me what else this thing can do' with help on how to configure the hidden features - so that it's obvious to everyone what extra advanced features are available & how to get to them?

ken300 wrote:I agree that having all the options exposed at once might not be the most welcoming setup for new users and doesn't fit in with 'Simple by default' at all. What about going for a simplified basic setup (simple mono-widgets), but have an easily accessible thing (an entry in the widgets right click menu for example) effectively saying 'show me what else this thing can do' with help on how to configure the hidden features - so that it's obvious to everyone what extra advanced features are available & how to get to them?

Our approach to this is the Alternatives selection: Have a minimalistic Plasmoid used by default, and allow the user to switch to one with more features easily. Via right-click menu.

Heiko Tietze wrote:I wonder how many people uses Kickoff (probably many since it's the default) or switch back to KMenu. I guess most KDE-ians launch apps per KRunner, which is a "mono-widget" in your terminology. And KDE provides Lancelot above all...

As an editorial note: Don't you want to split this thread into separate postings?

I find when I'm using my personal computer I tend to stray towards leaner launchers, and on my work machine I stuck with the default. When I fully switch to KDE 5 I imagine I'll be using the alternate launcher (with the favs along the side), as it just gets the job done with minimal fuss. Granted, I've always found KDE launchers were always weird, and during the time it was maintained Takeoff was at one point my favourite.

Anyway, I don't know about switching these into separate threads; I worry that I'll flood the forum since here might be 6+ of these things by the time I'm done. I was origionally going to set up a blog for them, but it wouldn't have been visible at all and I wanted this to be more interactive. If somebody wanted I could send these in as guest posts to their blog; I'm realizing now that as soon as I post the next what-if it would cut off the conversation of the last, which might make this thread a mess.

Kver wrote:Anyway, I don't know about switching these into separate threads; I worry that I'll flood the forum since here might be 6+ of these things by the time I'm done. I was origionally going to set up a blog for them, but it wouldn't have been visible at all and I wanted this to be more interactive. If somebody wanted I could send these in as guest posts to their blog; I'm realizing now that as soon as I post the next what-if it would cut off the conversation of the last, which might make this thread a mess.

*looks at Kver with a stern face*: Young man, you have to put that series in a blog. There is such great thinking in there, it would be a crying shame if its visibility would be confined to our awesome but small group here.
And not as guest posts on someone else's blog, but on your blog. About the visibility: That part is easy. You create either a blog specific to KDE posts, or you create a category or tag which provides its own RSS feed, and then you have that added to Planet KDE (click "Add your blog" to learn how). I can promise you, your number of visitors will soar with these posts!
Just be sure to make it absolutely crystal clear that these are "just" your ideas which you put up for discussion, and not necessarily the way the VDG or Plasma or KDE is going. And I really mean crystal clear. So clear that even people who read only the headline, only the first or only the last few sentences or only look at the pictures get it.
Because I can also promise you that these things will spread like wildfire. They will be discussed on Reddit, maybe on Slashdot, and very controversially. Many people will love you for them, and many will hate you. And I mean hate you. But that's okay, because those people hate change just because it's change.
I can say all this from my own experience. All of this has happened to me, and I regretted not having plastered "Early design draft" all over a screenshot I posted (you've got that covered, but I'd make the ribbon twice the size, so that even the almost blind will notice it).

But really, really, do absolutely post this stuff on a blog (or category within it) aggregated on Planet KDE. Unless you don't like to see the number of visitors (not visits!) to your blog surpass 3.000 on a single day, that is

As a new Plasma 5 user coming from Unity, the first thing I missed was a simple search based launcher like elementarys or unitys. So far neither Kickoff nor Kicker has completely filled that void for me.
Kickoff, while looking great, felt sluggish and jumping back and forth between subcategories made it hard to discover the great applications KDE has to offer and I didn't know about.
Kicker feels lean and fast and with some apps pinned to the left works great as a launcher for me, but its search feature is lacking due to being constrained by the launchers small height.
I settled on Kicker + KRunner and after 1 month of usage I'm still very happy with that combination.

On a side note, it's a bit annoying that you loose all the settings / favourites for your launcher if you decide to try the alternative and then go back.

Kver wrote:Chime in!
What are your thoughts on CSD; what did I miss, any addendums? Let us know!
The next What-If I'll be addressing is: "What would 'Start' Menus and Launchers from other enviornments look like in KDE?"

The mockups in particular are very, very beautiful at the first glance!
But.. there is a but. To me, besides the obvious technical problems that have been exposed in detail (let's ignore that for a second), it poses a potentially equally as bad problem in terms of usability.
even in the mockups, 2 windows have window control buttons in completely different positions. the window decoration used to be a firm point of the UI of every application, no matter how much different the content area is.
At a glance i know how i'll be able to move the window, (without having to hunt for semi secret empty areas in the rest of the window) and i know how and where to click to close the window, minimize/maximize etc, even unconsciously, with spatial/muscolar memory. THis with "too much freedom" in that department will be broken.

Now, I am in favor of making decorations a bit more flexible, with a protocol to allow things like making the decoration alpha blended overlaid on top of the contents (I guess would need wayland for that), or to inject a series of extra buttons in it, with a similar protocol to dbusmenu.
And note, I am for a quite limited protocol that will give applications clear walls of what they can and can't do... like, repositioning the close button by the app would be very forbidden, as the set and number of widgets addable in the decoration would be very limited. this, besides not having the problems of CSD would enforce some degree of consistency in the hard way, and that even tough I know will be painful for someone, would actually be a pro.

notmart wrote:

Kver wrote:Chime in!
What are your thoughts on CSD; what did I miss, any addendums? Let us know!
The next What-If I'll be addressing is: "What would 'Start' Menus and Launchers from other enviornments look like in KDE?"

The mockups in particular are very, very beautiful at the first glance!
But.. there is a but. To me, besides the obvious technical problems that have been exposed in detail (let's ignore that for a second), it poses a potentially equally as bad problem in terms of usability.
even in the mockups, 2 windows have window control buttons in completely different positions. the window decoration used to be a firm point of the UI of every application, no matter how much different the content area is.
At a glance i know how i'll be able to move the window, (without having to hunt for semi secret empty areas in the rest of the window) and i know how and where to click to close the window, minimize/maximize etc, even unconsciously, with spatial/muscolar memory. THis with "too much freedom" in that department will be broken.

Now, I am in favor of making decorations a bit more flexible, with a protocol to allow things like making the decoration alpha blended overlaid on top of the contents (I guess would need wayland for that), or to inject a series of extra buttons in it, with a similar protocol to dbusmenu.
And note, I am for a quite limited protocol that will give applications clear walls of what they can and can't do... like, repositioning the close button by the app would be very forbidden, as the set and number of widgets addable in the decoration would be very limited. this, besides not having the problems of CSD would enforce some degree of consistency in the hard way, and that even tough I know will be painful for someone, would actually be a pro.

I completly agree with the usability issue; With CSDs individual applications look perfectly reasonable, but the moment you realise buttons are moving around it's a usability loss, I specifically did that in the examples too to illustrate that point (I had a hard time finding an excuse for a vertical deco and a bottom deco). And you are *the* guy for understanding the technical issues. Your protocol you've been thinking about also sounds very, very good.

Anyway, I also wanted to mention; I'm *beyond* happy that you're not bandwagoning onto CSD; if anything gets into the decos I think everyone here agrees it's better *good* solutions are used instead of kludges and hacks. One thing we all respect is that KDE and its devs ultimately wait to find the best technical solution, and it's the whole reason KDE is so sustainable for such a complex system. I'd rather wait and see it done right, than to have it done badly now; especially since in software there's no "take backs"

+1 for separating every mockup set into its own thread and having a blog for these great ideas.

I love the launcher. Personally I think something like that would be better than Kickoff. It looks beautiful, but you need too many clicks to do anything with it. Also, and this goes for both kickoff and kicker, why do we need "favorites" in a launcher, when we can have them in the panel, again with one less click.

We tend towards redundancy. We have so many ways of achieving the same, many of which less than ideal. I would like (for the default) to have a clearer separation of functions:

-A launcher that "just" launches and searches applications (Kver's looks great)
-Favorites in the panel (or in a dock, like in Kver's mockup)
-Recent documents, various searches, advanced stuff via Krunner.

I would keep the current situation as an option for those who love it this way.

What do you think?

pedrorodriguez wrote:why do we need "favorites" in a launcher, when we can have them in the panel, again with one less click.
What do you think?

+100 for that! I am of the opinion that the favorites are obsolete, they are way too inflexible anyway.
Having stuff pinned in panels/docks is much better.
It has annoyed me for year to always have to stare at the Favorites section despite the fact that I do not have a use case for it and sadly it can't be disabled.

Kver, amazing work by the way, kudos! Please keep going, more people like you are needed!