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???

This seems more of a Redox goal than a KDE goal ;-)

For real, Somebody would either need to completely port QT and all KDE Tooling to Redox, or reimplement everything in their native tooling.
Also, Redox ships its own Desktop Orbital.

@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?

Can you try to come up with a catchier title?

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.

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

In T17388#307240, @notakitten wrote:

In T17388#307238, @snoweuph wrote:

In T17388#307224, @notakitten wrote:

In T17388#307191, @snoweuph wrote:

I don't think this would suffice as a goal for the whole KDE team for the next 2-3 Years.

In T17378#306948, @nicolasfella wrote:

A goal is supposed to be something the entire KDE community should focus on for the next two years. If the proposal can be summed up as one bug report it is not a suitable goa

I Also have Tiling inside of my More Polish Goal Ticket, how about you extend the Part related to tiling in it?

Oops, my bad.
You're right, it should be in your ticket. I added my idea to the tiling section in your ticket.

👍, I did edit it a bit, to better fit into formatting, and make it a bit more readable, without changing the context.

I also added you in the interested section

Great, thanks.
(great editing by the way, looks a lot better now)

In T17388#307527, @wstyler wrote:

I'd very much like this as well, and would happily test. Even something replicating the old Kwin tiling scripts, which worked great on X11/Plasma 5, would be very welcome. This is one of few blockers for me for Plasma 6.

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

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! 😆

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.

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.

In T17372#307761, @ngraham wrote:

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

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.

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"

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.

I got AMD and NVIDIA GPUs in devices, and I don't get any Wayland specific issues anymore, only general NVIDIA related ones.

• AMD RX 6650 XT
• Nvidia RTX 3050TI Optimus
• Nvidia GT 710

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.

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

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

In T17388#307224, @notakitten wrote:

In T17388#307191, @snoweuph wrote:

I don't think this would suffice as a goal for the whole KDE team for the next 2-3 Years.

In T17378#306948, @nicolasfella wrote:

A goal is supposed to be something the entire KDE community should focus on for the next two years. If the proposal can be summed up as one bug report it is not a suitable goa

I Also have Tiling inside of my More Polish Goal Ticket, how about you extend the Part related to tiling in it?

Oops, my bad.
You're right, it should be in your ticket. I added my idea to the tiling section in your ticket.

👍, I did edit it a bit, to better fit into formatting, and make it a bit more readable, without changing the context.

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 don't think this would suffice as a goal for the whole KDE team for the next 2-3 Years.

In T17378#306948, @nicolasfella wrote:

A goal is supposed to be something the entire KDE community should focus on for the next two years. If the proposal can be summed up as one bug report it is not a suitable goa

@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.

If this is done, it definitely should be opt in, I personally would dislike having that feature on my System, and I know a lot of people think the same towards Crypto Currency.
Though I guess, that for people, who like Crypto, it would be an awesome thing