That's a really good list of some real productivity/QoL improvements. Nothing too crazy, but well-thought out.
I'm especially interested in:

• custom touchpad gestures
• even better tiling (I'm looking to try out polonium, but expanding native support is probably desirable)
• extending the screen to another computer (maybe this could be done through a portal? So that we might even make it compatible between different compositors?)

I also would like to see some refactoring of the config files of the various KDE Apps and Plasma components. I'm using plasma-manager to configure my desktop declaratively with Nix, and I've noticed that many files contain both general user-defined settings (read: stuff I want to declare and sync across all my computers) and device-specific stuff ("last updated at", monitor-specific settings, etc.). I would love if we could have a clear, well-documented split between these aspects of configs, so it's easier to sync and backup settings.

@lordkekz for your config, you could just use the multiple layers, in which they are overridden (documented in the Kiosk API), and just write your general things down on one layer, and sync that, while allowing device specific config, which won't conflict with it.

You said:

I'm especially interested in:

so I'm going to add you to the interested section

One QoL feature that would be amazing to have is the option to mirror panels.
I picture it being a switch within panel edit mode that when toggled on, will mirror this panel to all new displays added, just like dash to panel does on gnome.

In T17372#307198, @medalzz wrote:

One QoL feature that would be amazing to have is the option to mirror panels.
I picture it being a switch within panel edit mode that when toggled on, will mirror this panel to all new displays added, just like dash to panel does on gnome.

I added it in ^^

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

Just giving a list of semi-related feature requests isn't particularly useful, we do have bugs.kde.org for that

In T17372#307262, @nicolasfella wrote:

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

Just giving a list of semi-related feature requests isn't particularly useful, we do have bugs.kde.org for that

I did update the description to fit a bit better.
I'm going to see, if there are already feature requests/ bug tickets for the examples of things to polish, and replace them with URLs to them. (and for the ones without a fitting one, I'm going to create one / tell the other people to create theirs for)

In T17372#307262, @nicolasfella wrote:

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

Just giving a list of semi-related feature requests isn't particularly useful, we do have bugs.kde.org for that

I did as many as I could for Today, I've run into the limit for new accounts on discuss.kde.org

What I would add, is fix the sharp corners on the bottom of every window in KWin. KDE is moving to a more rounded design, but the bottom corners haven't been fixed already for a long time, which would improve consistency immensely.

In T17372#307312, @xcroatoanx wrote:

What I would add, is fix the sharp corners on the bottom of every window in KWin. KDE is moving to a more rounded design, but the bottom corners haven't been fixed already for a long time, which would improve consistency immensely.

Following @nicolasfella advice, I suggest that you take a look at bugs.kde.org and discuss.kde.org, and if you don't find anything related, create a post over there.
If you find something, then get active in that post, to expand it with your opinions, if soemthign is missing

• Krunner:

If I may, regarding *Tiling*, it would be very useful if one could save a tiling scheme for each Virtual Desktop and Activity. Right now (at least in Plasma 5.27), when you create a new tiling profile or re-arrange a previous one it is saved across the board. This defeats some of the purpose of tiling with virtual desktops because usually one would have distinct Virtual Desktops for actually arranging windows in different manners.

• KDE Connect:

In addition to screen extension, I think it would be very useful if KDEConnect have an embedded and integrated way that mirrors your smartphone on your laptop screen, where you can type directly on it, move mouse and click, copy/paste, and hopefully drag and drop pics and files back and forth. Mostly like iOS and MacOS does right now.

In T17372#307434, @Abroas wrote:

• KDE Connect: In addition to screen extension, I think it would be very useful if KDEConnect have an embedded and integrated way that mirrors your smartphone on your laptop screen, where you can type directly on it, move mouse and click, copy/paste, and hopefully drag and drop pics and files back and forth. Mostly like iOS and MacOS does right now.

That is only possible with Wifi/USB Debugging, I suggest using GUI Scrcpy.
And you might see that this isn't a feature which can be implemented that seamless, because the user will allways have to setup ADB per Wifi first, which on most devices is just a pain in the ass

I also suggest reeading the comments, and moving your specific feature requests to bugs.kde.org and discuss.kde.org

In T17372#307437, @snoweuph wrote:

In T17372#307434, @Abroas wrote:

• KDE Connect: In addition to screen extension, I think it would be very useful if KDEConnect have an embedded and integrated way that mirrors your smartphone on your laptop screen, where you can type directly on it, move mouse and click, copy/paste, and hopefully drag and drop pics and files back and forth. Mostly like iOS and MacOS does right now.

And you might see that this isn't a feature which can be implemented that seamless, because the user will allways have to setup ADB...

Thanks for that part of the reply.

In T17372#307267, @snoweuph wrote:

In T17372#307262, @nicolasfella wrote:

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

Just giving a list of semi-related feature requests isn't particularly useful, we do have bugs.kde.org for that

I did update the description to fit a bit better.
I'm going to see, if there are already feature requests/ bug tickets for the examples of things to polish, and replace them with URLs to them. (and for the ones without a fitting one, I'm going to create one / tell the other people to create theirs for)

My main point wasn't so much about linking to existing requests but that the proposal should be more than a loosely connected list of your personal requests. It should tell a story that's more concrete than "let's have nice things"

In T17372#307460, @nicolasfella wrote:

In T17372#307267, @snoweuph wrote:

In T17372#307262, @nicolasfella wrote:

A goal should be more than a list of your personal feature requests. It should articulate a vision for a specific topic/area of focus. Everyone should be able to look at the goal description and derive their own ideas/todo items from it.

Just giving a list of semi-related feature requests isn't particularly useful, we do have bugs.kde.org for that

I did update the description to fit a bit better.
I'm going to see, if there are already feature requests/ bug tickets for the examples of things to polish, and replace them with URLs to them. (and for the ones without a fitting one, I'm going to create one / tell the other people to create theirs for)

My main point wasn't so much about linking to existing requests but that the proposal should be more than a loosely connected list of your personal requests. It should tell a story that's more concrete than "let's have nice things"

My General Goal Suggestion is:
Don't do anything too big and new, and fancy, and Focus on the Minor annoyances, to make Plasma more polished, basically, what was done for the last plasma release.
The List of stuff was to show, that even though Plasma has gotten pretty polished, it's still the main area in which it needs some work.

It should tell a story that's more concrete than "let's have nice things"

I don't quite get what you mean with story, are you talking about the classical "User Stories" you learn about at school?

You said that everybody should be able to look at the goal, and think about things they can work on themselves, and I personally think, that "More Polish" is such a thing.
Because, nobody would come to the conclusion, to add the biggest new features, when hearing Polish, but would consider looking at small annoying stuff. (whether it's bugs, or relatively small features).

Looking at old Goals, one of them was "KDE For All" https://community.kde.org/Goals/KDE_For_All, which was about improving Accessibility
And in the case of its Motivation section (which I'm comparing to this year's Description section), it basically was: "Accessibility needs more Work", with a list of features, and for which kind of people they would be useful.

So I don't quite get, where

I wish for KDE (Plasma) to get even more polished. The release of v6 brought a lot of polish, but there are still some small and annoying bugs, or inconveniences.
This Goal of "Polish" means, to make KDE Plasma an even smother experience for everybody, while focusing on existing things, and small features, from which a lot of people would get a benefit.

+ A list of features is so far of.

Do you in general think this Goal suggestion is a lot of Crap, or it's just the formulation?
And in the case it's just the formulation, might you be so kind and share suggestion on how to actually improve it?
,because I don't quite see a difference in structure to previous ones, and don't get what you mean with a "concrete story"

@ngraham @davidedmundson bringing this to your attention

Each goal needs Champions. If no-one is found it will unfortunately not be eligible for voting.

This reminds me of my Usability & Productivity goal, which to a certain extent was also a random grab bag of bug reports and feature requests. What really helped was to gather them around one or two core principles; in that case "Usability" and "Productivity".

In this case, the message I'm receiving so far is "make things that already exist more impactful and product-friendly."

That would be something I could get behind. I've often felt that in KDE we build these amazing technologies, but then fail to adequately productize them. Then someone else does it, and then we go, "oh, duh" and put together the pieces we already had available for years to do the same thing. If we had done it first, we could have been seen as leading instead of following.

So maybe this could be something like "Productize existing technologies"? Some examples might be:

• Use your phone via KDE Connect as a method of getting data into your desktop apps. Authentication via the phone's fingerprint reader, pipe in camera images or microphone audio as raw input or file transfer, etc.
• Deploy David E's "input method playground" stuff and polish the heck out of it
• Rejigger Activities to allow true separation of tasks, per https://invent.kde.org/plasma/kactivitymanagerd/-/issues/6#note_507027
• Day/night changes to the color scheme and brightness, hooking into the solar cycle data we already have with Night Color
• Tesseract-based OCR via an API available to any KDE app, and also built into the Baloo file indexer so it can pull words out of images

Basically, take core technologies that KDE developers have already built, and re-package them for relevance and user impact.

In T17372#307761, @ngraham wrote:

This reminds me of my Usability & Productivity goal, which to a certain extent was also a random grab bag of bug reports and feature requests. What really helped was to gather them around one or two core principles; in that case "Usability" and "Productivity".

In this case, the message I'm receiving so far is "make things that already exist more impactful and product-friendly."

That would be something I could get behind. I've often felt that in KDE we build these amazing technologies, but then fail to adequately productize them. Then someone else does it, and then we go, "oh, duh" and put together the pieces we already had available for years to do the same thing. If we had done it first, we could have been seen as leading instead of following.

So maybe this could be something like "Productize existing technologies"? Some examples might be:

• Use your phone via KDE Connect as a method of getting data into your desktop apps. Authentication via the phone's fingerprint reader, pipe in camera images or microphone audio as raw input or file transfer, etc.
• Deploy David E's "input method playground" stuff and polish the heck out of it
• Rejigger Activities to allow true separation of tasks, per https://invent.kde.org/plasma/kactivitymanagerd/-/issues/6#note_507027
• Day/night changes to the color scheme and brightness, hooking into the solar cycle data we already have with Night Color
• Tesseract-based OCR via an API available to any KDE app, and also built into the Baloo file indexer so it can pull words out of images
  
  Basically, take core technologies that KDE developers have already built, and re-package them for relevance and user impact.

Love this ❤️

Day/night changes to the color scheme

This would be especially Cool, with the ability to switch full custom themes (Nord Light at Day, Gruvbox at night)

I will rewrite the Goal

In T17372#307761, @ngraham wrote:

What really helped was to gather them around one or two core principles; in that case "Usability" and "Productivity".

I guess the two Things I would build this around are:
"Features" & "Users"

Users

• Convenience - Make the user experience as simple and hassle-free as possible.
• Intuitivity - Ensure that the features are easy to use and understand
• Empowerment - Provide users with powerful tools that give them greater control.

Features

• Refinement - Improve and polish existing features to enhance their performance.
• Enrichment - Add value to existing features by expanding their capabilities.

Yeah, though that's still pretty broad. I feel like we need to articulate the specific principle that guides these strands of work. I'm not trying to hijack your proposal, but in everything I read, the underlying current is "turn promising technologies and nerdy features into products suitable for normal people". Or, like, "focus on real-world use cases and workflows", maybe? Just brainstorming.

In T17372#307810, @ngraham wrote:

Yeah, though that's still pretty broad. I feel like we need to articulate the specific principle that guides these strands of work. I'm not trying to hijack your proposal, but in everything I read, the underlying current is "turn promising technologies and nerdy features into products suitable for normal people". Or, like, "focus on real-world use cases and workflows", maybe? Just brainstorming.

Honestly im fine with you hijaking it xD

Heh ok. Well if you change the goal description accordingly, I'd be happy to help out on the team with communications, design, and some technical stuff. But I can't commit to being a primary goal champion this time around.

In T17372#307812, @ngraham wrote:

Heh ok. Well if you change the goal description accordingly, I'd be happy to help out on the team with communications, design, and some technical stuff. But I can't commit to being a primary goal champion this time around.

I dont think I can be a Primary Champion as well, especialy, because I got here from a Post, saying that its about making it easy for people to get into contributing.
I prolly can spend ~5 hours every weekend (+10; -3)

I gonna Edit the post later, when I have the time

I was the sole goal champion for the Usability & Productivity goal when I had only been an infrequent contributor to KDE for fewer than 6 months; it's more feasible than you might think!

But ultimately, yes, these goals do involve some responsibility for helping to advance the goal. They're not just an idea you throw over the wall and then other people do all the work! 😆

In T17372#307814, @ngraham wrote:

I was the sole goal champion for the Usability & Productivity goal when I had only been an infrequent contributor to KDE for fewer than 6 months; it's more feasible than you might think!

But ultimately, yes, these goals do involve some responsibility for helping to advance the goal. They're not just an idea you throw over the wall and then other people do all the work! 😆

well, I never Contributed to it before, only did really minor contribution in the foss space so far (Small Bugfixes to tooling I use, like Neovim Plugins)

How much time would you say, will I need to invest, after all its a commitment

I'd say at least a 5 hours a week if you want to be effective, but it probably also depends on on what role you want. As Lydia's blog post said, there are three champion positions:

• Vision/leadership
• Technical lead
• Promotion/communication

In T17372#307935, @ngraham wrote:

I'd say at least a 5 hours a week if you want to be effective, but it probably also depends on on what role you want. As Lydia's blog post said, there are three champion positions:

• Vision/leadership
• Technical lead
• Promotion/communication

Okay, 5 hours seems reasonable.
I Personally would love to be leading Technical, but because I never even touched the Plasma Codebase before, I guess that would be stupid of me.
I also don't feel like i'm the best person for promotion, so I guess It would make most sense for me to steer the Vision.

@ngraham @nicolasfella I did some editing, is this now better as a Goal?

Can you try to come up with a catchier title? The current one is so generic it could encompass anything, and it's too long too. Finally, it only mentions Plasma, but the KDE community is much larger than just Plasma. It needs to be relevant to everyone, not just Plasma devs.

Finally, it only mentions Plasma, but the KDE community is much larger than just Plasma. It needs to be relevant to everyone, not just Plasma devs.

Well, wasn't a previous goal: "All about the Apps" ? didnt that kindof disclude Plasma? isnt this kindof tho oposite in this case?
Also aren't multiple goals chosen?
And Isnt stuff like Klipper or KDE Connect their Own Project?

But yes, this goal doesn't really includer stuff like Krita, or Kdenlive directly, though if I remove the Plasma from the title, this goal, could also be seen more broad, and adapted for other projects, right?

Can you try to come up with a catchier title?

That's definitely not my strong site xD

Hello,

Please note that the deadline just around the corner on Wednesday, so now is the time to finalize your proposal. Remember that proposals without a Goal Champion will be disqualified, so this step is crucial to ensure your idea moves forward. If you need help or have any questions, please let me know.

If you’re unable to finish your proposal but still want to participate, consider contributing to other ongoing tasks.

Thank you for submitting your ideas for the KDE Goals!

@nicolasfella @ngraham
Is this Goal okay the way it is, or is there something I'm missing (need to improve, for this to go forward) or could improve?

To be honest it still seems too general for me, without a clear enough unifying goal. "Users" and "features" kind of encompass everything, right? So this is phrased a bit like "make everything better", and, OK yeah, we all want that and are already working towards it!

Late to the game, but, it seems a shared display / screen casting technology is one of the basic underpinnings to this proposal...which brings us to the "standards" in this area.

I've had a long term interest in some kind of native Miracast within Linux. There are two existing open source projects: Gnome Network Display and MiracleCast.

1. Gnome Network Display is available and generally works but is wholly or mostly userland based. It supports both Miracast and Chromecast.
2. MiracleCast is ... bad. It proposes to be a display service more integrated with Linux but, in contrast, lacks coherent and responsive development.

See: https://discuss.kde.org/t/built-in-miracast-support-wireless-display-specification/5570/5

Gnome Network Display is definitively the more robust solution over MiracleCast. MiracleCast has been persistently forked with various attempts to fix. The main developer looked into collaboration with the Gnome Network Display developer at one time. One of the main issues with MiracleCast is the network card issue and could "easily" be fixed by implementing a virtual NIC as per Gnome Network Display.

In any event, by adopting a Miracast framework, this project would not only benefit KDE and some of the main goals of this project, it potentially adds a critical missing Linux feature that has frustrated many users.

Additionally, most (if not all) Android distributions (except STUPID Google Pixel devices because idiotic Google Chromecast "business" decisions) include a Miracast solution. It might prove fruitful to reverse engineer the Android solutions (Miracast + Chromecast) into a general Linux solution.

Gnome Network Display is likely the best base project to leverage. It has a native Mutter screencast integration. Is there a native KDE equivalent???

In T17372#310161, @atescomp wrote:

Late to the game, but, it seems a shared display / screen casting technology is one of the basic underpinnings to this proposal...which brings us to the "standards" in this area.

I've had a long term interest in some kind of native Miracast within Linux. There are two existing open source projects: Gnome Network Display and MiracleCast.

1. Gnome Network Display is available and generally works but is wholly or mostly userland based. It supports both Miracast and Chromecast.
2. MiracleCast is ... bad. It proposes to be a display service more integrated with Linux but, in contrast, lacks coherent and responsive development.
   
   See: https://discuss.kde.org/t/built-in-miracast-support-wireless-display-specification/5570/5
   
   Gnome Network Display is definitively the more robust solution over MiracleCast. MiracleCast has been persistently forked with various attempts to fix. The main developer looked into collaboration with the Gnome Network Display developer at one time. One of the main issues with MiracleCast is the network card issue and could "easily" be fixed by implementing a virtual NIC as per Gnome Network Display.
   
   In any event, by adopting a Miracast framework, this project would not only benefit KDE and some of the main goals of this project, it potentially adds a critical missing Linux feature that has frustrated many users.
   
   Additionally, most (if not all) Android distributions (except STUPID Google Pixel devices because idiotic Google Chromecast "business" decisions) include a Miracast solution. It might prove fruitful to reverse engineer the Android solutions (Miracast + Chromecast) into a general Linux solution.
   
   Gnome Network Display is likely the best base project to leverage. It has a native Mutter screencast integration. Is there a native KDE equivalent???

I suggest Posting that to: https://discuss.kde.org/t/kde-connect-extend-display/17493
which is thing inthe list fo stuff in this goal that fits best. Your talking about a specific way to implement it, while we are still at a much higher level of planing, and Im trying to keep this some what broad, so that it fits for most of the plasma community.

The voting process is over, the votes are being tallied and the chosen proposals will be announced at Akademy. In the meantime we would like to invite you all to join the KDE Goals matrix room to stay in the loop, get in touch with other people and team up on other proposals if yours doesn’t make it—or rally some support if it does.