kdeuserk wrote:

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.

I use Favorites for regularly needed stuff that doesn't belong on the panel but needs to be quickly accesible when needed, like KeePassX, KNotes or as it's the default Settings and Dolphin, but I only had to stare at them for a few weeks

hirnsushi wrote:I use Favorites for regularly needed stuff that doesn't belong on the panel but needs to be quickly accesible when needed, like KeePassX, KNotes or as it's the default Settings and Dolphin, but I only had to stare at them for a few weeks

I respect your use case though I think it creates more problems than it solves.
Always seeing Favorites default makes launching other applications less efficient all the time and more time is lost then saved the few times you actually need KeePassX etc. (Obviously talking of mouse navigiation, keyboard is not considered here). If you need the mentioned stuff really often I do not see a reason not to place them in the panel, the panel is big enough for many launchers to fit in. Nobody says that something does not belong in a panel just because its a simple program.
We have the option though to make Favorites optional.

pedrorodriguez wrote:-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'd use Milou in the panel for search because KRunner isn't very discoverable since it can only be accessed via shortcut.
Otherweise: +1

hirnsushi wrote:

kdeuserk wrote:

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.

I use Favorites for regularly needed stuff that doesn't belong on the panel but needs to be quickly accesible when needed, like KeePassX, KNotes or as it's the default Settings and Dolphin, but I only had to stare at them for a few weeks

I understand that you like that kind of organisation, but to me it doesn't make sense to have by default two sets of "favorites". In your case I would launch those less used apps via krunner (actually I launch everything with it). I would maybe still keep it as an option for those who can't live without that feature. Btw, the default behaviour I imagine for adding favorite apps to the panel would be: right click on launcher--> Add to Panel --> Nice animation that shows you where that icon went --> Icon on the panel next to launcher.

colomar wrote:

pedrorodriguez wrote:-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'd use Milou in the panel for search because KRunner isn't very discoverable since it can only be accessed via shortcut.
Otherweise: +1

Then we should make it more discoverable. I don't know about the current state of Milou, but I read a post months ago by Aaron Seigo, that its most interesting feature was the UI (which I believe was adopted by Krunner in Plasma 5, or something very similar). Milou is very new, and not a default. Kruner is, though, and its underlying protocol, also called krunner, should be replaced (acording to Seigo) by a new one called Sprinter, which does a whole lot of fancy stuff. In this case we might want to improve on what is already here or is going to be soon

pedrorodriguez wrote:

hirnsushi wrote:

kdeuserk wrote:+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.

I use Favorites for regularly needed stuff that doesn't belong on the panel but needs to be quickly accesible when needed, like KeePassX, KNotes or as it's the default Settings and Dolphin, but I only had to stare at them for a few weeks

I understand that you like that kind of organisation, but to me it doesn't make sense to have by default two sets of "favorites". In your case I would launch those less used apps via krunner (actually I launch everything with it). I would maybe still keep it as an option for those who can't live without that feature. Btw, the default behaviour I imagine for adding favorite apps to the panel would be: right click on launcher--> Add to Panel --> Nice animation that shows you where that icon went --> Icon on the panel next to launcher.

I aggree that it should be easier to add apps to the panel. Right now it seems to me there are even more possibilities, pin it to the launcher, add an icon to the panel or pin it to the panel by right clicking on it while running, creating three different sets of favorites. I'm all for boiling that down to one as the default while keeping the possibility to maybe add more if needed.
My usage of the pinned apps in the launcher comes from the perspective of a new KDE user trying to integrate the defaults I can't change (can't hide favorites -> try to use them) into a efficient workflow. I use krunner most of the time, but it's not always faster if you have to reposition your hand first.

pedrorodriguez wrote:Then we should make it more discoverable. I don't know about the current state of Milou, but I read a post months ago by Aaron Seigo, that its most interesting feature was the UI (which I believe was adopted by Krunner in Plasma 5, or something very similar). Milou is very new, and not a default. Kruner is, though, and its underlying protocol, also called krunner, should be replaced (acording to Seigo) by a new one called Sprinter, which does a whole lot of fancy stuff. In this case we might want to improve on what is already here or is going to be soon

Things have changed in the KRunner/Milou/Sprinter world (See Vishesh's blog post for details).
Sprinter is currently in hiatus with no recent development, KRunner and Milou's backends have been merged and there is a Search Plasmoid which basically does the same as pressing Alt-F2. So adding the Search Plasmoid to the panel by default would just be making KRunner more discoverable, nothing else. And I think we should do that.

colomar wrote:

pedrorodriguez wrote:Then we should make it more discoverable. I don't know about the current state of Milou, but I read a post months ago by Aaron Seigo, that its most interesting feature was the UI (which I believe was adopted by Krunner in Plasma 5, or something very similar). Milou is very new, and not a default. Kruner is, though, and its underlying protocol, also called krunner, should be replaced (acording to Seigo) by a new one called Sprinter, which does a whole lot of fancy stuff. In this case we might want to improve on what is already here or is going to be soon

Things have changed in the KRunner/Milou/Sprinter world (See Vishesh's blog post for details).
Sprinter is currently in hiatus with no recent development, KRunner and Milou's backends have been merged and there is a Search Plasmoid which basically does the same as pressing Alt-F2. So adding the Search Plasmoid to the panel by default would just be making KRunner more discoverable, nothing else. And I think we should do that.

I was about to post that article with the clarification. My information was out of date. Including the new plasmoid by default makes sense, as well as what we discussed previously.

On a side note, I'm looking at moving the what-ifs to a proper blog of some sorts. If anybody has any suggestions (outside of blogger) I'd like to know, otherwise I'll just be going with blogger - but I'm not hip with blogging stuff so if there's a good, capable platform with social-network-enabled commenting logins, please mention it!

I will also apologise for various editing mistakes, typos, etc; I usually edit these a few several after posting, but humans need sleep and I want this post up tonight - so I won't be making corrections until tomorrow.

What if... KDE Used Windows 10 Design Components?
Forward
First, a brief overview of Windows 8;

Windows 8 was Microsofts' first step towards creating a unified 'experience' between the range of products running Microsoft Windows. Before Windows 8, early tablets which ran Windows typically ran a traditional Windows desktop; because desktop Windows was designed for mice, it typically required a stylus, trackball, or other similar input; keyboard solutions were universially sub-par. Microsoft ideally wanted its mobile audience to use laptops and phones instead of tablets. Apple and Google later devoured the tablet/phone market with iOS and Android respectivly, and touchscreen devices became the norm. With their advantage in touch input, these two systems grew into tablets. This left Microsoft in a bind; Windows mobile was not capable of delivering a capable experience, so instead of taking the route Android and iOS did (growing their OSs' up) Micrsoft decided to begin shrinking its more capable desktop OS down. Windows 8 was the first step in this process, and essentially laid a touch-centric layer on top of a traditional desktop OS. The end result was an OS with split personalities and it required desktop users to work around touch components, while mobile users more/less had a decent - but more limited - experience.

Windows 10 is Microsofts' attempt to correct the design flaws of Windows 8; Mainly by allowing the interface to vary between form-factors, such as including a start menu and introducing a multi-desktop mode.

Consumption vs Work-Oriented Design
In terms of design, Windows 8+ has a much more consumption-oriented design, as opposed to a work-oriented design; and it has a large amount of data throughput even in the main menu. This is appealing to mass-market users who desire quick access to information, and the ability to quickly act on it. For example, the twitter live-tile not only shows the latest updates, but is a one-click access point to that data. We don't have that efficency; we can launch applications, or display plasmoids, but we don't have an efficent solution that does both. On the other hand, users have complained that the live-tile interface can become chaotic, with literally dozens of tiles calling for attention.

Desktop Linux and KDE have traditionally kept towards work-oriented designs, and consumption efficency is left in the hands of the applications. This is trouble for KDE, because we don't bundle simple applications which other enviornments do; i.e weather, maps/directions, or a clock/timer/alarms app. We do keep these as desktop components, but instead of simply launching applications, KDE requires a user to use complex editing tools to add and configure those widgets. In addition, if we did bundle those applications plasma widgets still do not launch relevant applications; our weather plasmoid does not launch a weather app, our photo widget does not launch a gallery. This poses another problem because a user must also know how to create a dash with independent widgets and know how to invoke that dash if they do not wish to crowd their desktop with plasmoids.

One way this could be solved would be creating a class of "launcher widgets" which are read-only QML widgets the system would treat as icons. Additionally, we might create a new file-level protocol for a QML "icon widget" format which could enable dynamic icons for application launchers. For example, a weather app might have a QML-based icon which displays todays weather. Though this could cause serious performance rammifications if implemented poorly, and adds dramatic complexity to simple file-browsers.

KDE should consider allowing widgets to flag themselves as being "launchable" - allowing them to be launched similarly to applications. Sometimes you need to make quick notes about something without the need to save files or open the "KDE Advanced Text Editor". Maybe you just only need the dictionary once in a blue moon. Allowing these to launch as KDEs' version of "modern apps" might be highly beneficial, and give access to KDEs well-designed plasmoids without the need to modify the desktop. Also, our container application which actually contains the widgets could offer buttons to do things like quickly add the app to the current desktop, panel, or dash. This could later be integrated into Martin Gräßlins' server-side-decorations.


The notes plasmoids - launched as an application

While a great deal of applications are being written in QML, launchable plasmoid applications for KDE might be a good option when use-cases are simple-enough to be desktop-ready, but still useful enough to work as 'standalone apps'. This might also make plasmoid development more attractive to developers who work more in traditional applications. Things like maps, directions, notes, cloud-based services, contacts, and other simple utilities - especially those which piggyback off the system - would be especially viable if developed under this model. Not only would we have our own 'metro apps', but these 'Plasma Apps' would be incredibly flexible in their ability to integrate to the desktop.


The dictionary plasmoids - launched as an application

Start Menus
The Windows 10 Start menu has embedded live tiles. For plasmoids which aren't big enough to be launched as applications, or not used consistently enough to be placed on the desktop or in the panel, Plasma could offer a launcher that has an embedded widget tray, or offer pop-up containments which could house collections of plasmoids.


Click to Enlarge - Embedded widgets in a start-menu like launcher

Technical Challenges
For the most part, Plasma is already flexible enough to allow us to extend plasmoids into 'Plasma Apps'. As a matter of fact, the plasmoid preview utility used by developers already gets us most of the way there. For the most part, there's no real (obvious) technical hurdles.

One design aspect would be making a 'native' plasma theme for plasma running in an application mode.

Pros

• Launching plasmoids as applications offers extreme occasional-use convienience.
• Ensuring widgets can easily launch related full applications fits the "simple by default, powerful when needed" mantra.
• Application developers might be more interested in plasmoid development when KDE users could launch it as a 'real app'
• It would help fill KDEs' need for simple applications.

Cons

• Users might not appreciate their program lists getting filled with plasmoids, especially if they can't be hidden.
• Plasmoids looking to be used as applications would need to account for more static contexts or alternate storage locations.
• Everything listed here would add redundant applications to the system.
• If plasmoids launched generic types of applications, we would need tonned of default aplication types; default weather, default stock ticker, default dictionary, etc.
• Applications lists would need to be overhauled to display plasma-apps.
• Adding widgets to widgets (for the 'start menu') would need a clever editing UI, adding complexity.

Notes
Overall, the main issue KDE has is the disconnect between simple applications and simple plasmoids. KDE does have the functionality of other desktops in plasma, but it can feel more cumbersome to access it, especially if it's in a situation where you may only need it on occasion. Plasmoids like the dictionary are the perfect example of this; I know no-one who refers to a dictionary often enough to constantly need one, but I can also say everybody likely needs one on occasion. For me, launching a browser and doing a Google search is faster than digging out the plasmoid. I don't use the dash either, but even still do we want the KDE dash to be the junk-drawer of occasionally used widgets forever?

I found that adding live tiles was beneficial to the start menu, as it does become a simple notification area; I think it would be beneficial if we were capable of embedding widgets into launchers or secondary 'container plasmoids'. I think KDE did do this at one point - can anyone let me know? I also think launching applications by directly clicking on plasmoids should be added; opening a full weather application would be great if we could package them together, and the same goes for stocks, maps, etc etc.

Chime in!
What are your thoughts on creating a more consumption-oriented design? What did I miss, any addendums? Let us know!
Instead of posting the next what-if, I'll just be posting what I have in the works, so in no particular order:
"What if KDE created a Server-Side Window Decorations system? What would it look like?"
"What if Material Design (by Google) were applied to KDE and plasma?"
"What if KDE had a voice assistant? Could we make amazing accessibility sexy?"

Kver wrote:Cons

• Applications lists would need to be overhauled to display plasma-apps.
• Adding widgets to widgets (for the 'start menu') would need a clever editing UI, adding complexity.

That's a challenge not a hindrance .
I like the idea, it support the simplicity approach.

Kver wrote:On a side note, I'm looking at moving the what-ifs to a proper blog of some sorts.

Make sure to add yourself to PlanetKDE, ping me if you need help.

Kver wrote:but it can feel more cumbersome to access it, especially if it's in a situation where you may only need it on occasion.

I completely agree with this! The current supposed workflow of adding a plasmoid, using it and then probably deleting it doesn't really make sense.

Running Plasmoids as apps is something we've had in 4.x, they were visible in the runners but it never really took off that much. There were a few reasons I think:

* It listed all the Plasmoids, even the system tray. Having some bad entries made it all just look pointless. Easily fixable. I'd like to see opinions on which plasmoids you would list as applications.

* Plasma previously had a design goal that it must look visibly different to applications. In order to make plasmoid applications work we need to undo this. Ideally we need to make it so that it matches the user selected widget style. Even if Breeze happens to match, that's not really solving the root problem if we want things to always look native.

* It still did the compact/full switching, which is very different behaviour from other applications so it stood out as not really being native. Again fixable, but I'd need other people to agree with me before we made that change.

Great Mockups!

david_edmundson wrote:

Kver wrote:On a side note, I'm looking at moving the what-ifs to a proper blog of some sorts.

Make sure to add yourself to PlanetKDE, ping me if you need help.

Kver wrote:but it can feel more cumbersome to access it, especially if it's in a situation where you may only need it on occasion.

I completely agree with this! The current supposed workflow of adding a plasmoid, using it and then probably deleting it doesn't really make sense.

Running Plasmoids as apps is something we've had in 4.x, they were visible in the runners but it never really took off that much. There were a few reasons I think:

* It listed all the Plasmoids, even the system tray. Having some bad entries made it all just look pointless. Easily fixable. I'd like to see opinions on which plasmoids you would list as applications.

* Plasma previously had a design goal that it must look visibly different to applications. In order to make plasmoid applications work we need to undo this. Ideally we need to make it so that it matches the user selected widget style. Even if Breeze happens to match, that's not really solving the root problem if we want things to always look native.

* It still did the compact/full switching, which is very different behaviour from other applications so it stood out as not really being native. Again fixable, but I'd need other people to agree with me before we made that change.

+100

david_edmundson wrote:Make sure to add yourself to PlanetKDE, ping me if you need help.

Gotcha. About the only thing that scares me is the git stuff; I'm terrible at git. But when time comes I'll make a best effort first; the rest of it is pretty easy. Just git. Git git git. >_<;;;

david_edmundson wrote:

Kver wrote:but it can feel more cumbersome to access it, especially if it's in a situation where you may only need it on occasion.

I completely agree with this! The current supposed workflow of adding a plasmoid, using it and then probably deleting it doesn't really make sense.

Running Plasmoids as apps is something we've had in 4.x, they were visible in the runners but it never really took off that much. There were a few reasons I think:

* It listed all the Plasmoids, even the system tray. Having some bad entries made it all just look pointless. Easily fixable. I'd like to see opinions on which plasmoids you would list as applications.

* Plasma previously had a design goal that it must look visibly different to applications. In order to make plasmoid applications work we need to undo this. Ideally we need to make it so that it matches the user selected widget style. Even if Breeze happens to match, that's not really solving the root problem if we want things to always look native.

* It still did the compact/full switching, which is very different behaviour from other applications so it stood out as not really being native. Again fixable, but I'd need other people to agree with me before we made that change.

I added the look'n'feel quote to the main post; I think it can be solved by making a separate theme that kicks in when in 'Plasma App mode'. Either way I don't think super-ultra-native is necessarily the biggest deal, as long as the applications don't actively clash with the general application theme I think it would work; it might even be beneficial as users might intuitively understand that they're using a more limited application (much like a metro application)

Next; Holy ****, Krunner can launch plasmoids as apps! This has probably just changed my current workflow.

Still though, part of it not taking off may have been the fact it was hidden behind krunner; and even when you know you can launch them, it's still non-discoverable (you need to know what plasma app you're going to launch; you wouldn't "know" you could open weather unless you both knew it existed and remembered its name). For this sort of feature to be successful, I think more effort would need to be made to treat these as first-class applications. Icons in the launchers, a 'native' theme, less bugginess (running more than one at once causes issues), traditional menus, and actions the container might have (as opposed to requiring right-click, embed the plasmoids default right-click menu).

The container would need to also need to provide profiles/data retention, theme settings, whether they should be placed in the tray on close, and a simple method to specify how the widget wants to be treated with these respective settings. This is getting a bit technical, but the point is there are considerations that need to be made; launched widgets need to be able to retain data, and the user may want multiple configurations of the same widget to be launchable (such as getting weather in multiple locations, or having different notes), while other widgets would be better off not retaining any data. If we had a simple timer/alarm plasmapp you may want 'closing' it to shrink it to the tray. And if you have it in the tray, you may want it to act like a plasma popup until closed or detached. So, lots of technical considerations should be made.

In terms of widgets I'd like to see as 'launchable' I think notes, weather, dictionary, black board, system monitor, RSS, social news, microblogging, print job manager, KDE connect, quick chat, contacts, and the temperature monitor would be a good start. If certain widgets were improved or added, I'd also include the colour picker (if it kept a history and had an improved interface), any kind of social network clients (twitter, facebook, etc etc), pastebins, maps, along with any simple game plasmoids.

Love the ideas for making plasmoids more accessible and easy to use. The workflow observations you make are spot on IMO. Also David's observation of the need to restore the visual unity of plasmoids and applications is also spot on. And great ideas for a possible SSD use-case.

Lots of ideas germinating in my head from these posts, so please keep em coming!

What-If is DEAD! Long live What-If!
It's time for an update.

So, it's been a while since I posted a what-if, and that's because dark seedy things are afoot! There's been a strong push to get this onto a proper blog for a number of reasons, and that's exactly what I'm doing.

Granted, I'm not going to make a blog just for the what-ifs, so for all intents and purposes I'm finally starting a proper Design & Development blog. So what-if as "my project" is dead, but what-if as one of my recurring themes will totally stay alive; I'll just be talking about other things, too.

This will help me do a number of things; first, I've been working for weeks on a much larger series of design concepts, and having it on a blog means I'll be able to make much more detailed posts. It also will keep things more organised, and design concepts can have their own ongoing discussions. Lastly, and probably more importantly, not all of my work is what-ifs; some of it is starting to go beyond that scope, and I have other work I do. It's probably about time I keep my own little treasure-trove of goodies outside of my random file hosting.

The major downside is that it marginalises the forums a bit; but (at least for what-ifs) I realised that the important thing isn't making sure the discussion isn't in one place - the important thing is that discussions will happen; regardless if I'm there to sheppard the conversation.

For all my other stuff though, I'll totally be on the forums helping out, this is just for what-ifs and more finished work. I'll be posting links in this thread later, and I'll also be trying to get onto PlanetKDE.

About the 'embed widgets in the start menu' thing - might it be a good idea to find a way of displaying widgets in the notifications pane that pops up above the System tray when one of the tray icons are clicked so that:

1 - All of the notification type things that you'll want to look at will be in that pane - whether it's checking the widget to see what the weather's going to do today or checking how much battery your laptop's got left by clicking the System tray icon

2 - the start menu doesn't become cluttered

3 - If you don't use the standard launcher (say you've switched to the homerun kicker) then you don't loose this ability to easily display & hide the widgets you're interested in

Having a 'Notifications' area was a massive step forward for phones - all notifications are in one place, why don't we find a way of having the System tray pane as our equivalent, everything in one place (if you want to do it that way)?