- User Since
- Apr 15 2017, 7:18 PM (168 w, 6 d)
In general I think it's sub-optimal to maintain two different tools that do essentially the same thing, even if both are working fine. It's confusing for users and it generates extra work for developers. If there are desirable things that KHotkeys can do which KGlobalAccel can't, IMO we should add the missing features to KGlobalAccel and continue with the plan to deprecate KHotKeys.
Cleaned this up a bit and moved it to https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/151
Thu, Jul 9
After living with a 4K 14" screen for a bit now, I've changed my mind.
Tue, Jul 7
Done with that merge request. Thanks!
Mon, Jul 6
Almost all of this is already possible right now. :) Have you tried adding a wide right edge panel (optionally auto-hiding) and adding these widgets to it? It mostly works quite well. In cases where it doesn't (e.g. the search widget doesn't display the search field), those are simple bugs that we can and should fix, for which I would request bug reports at https://bugs/kde.org. Thanks!
That looks great! Feel free to submit it as a merge request!
Fri, Jul 3
I'm pretty sure the Kvantum developer isn't interested in upstreaming Kvantum. Besides that, opening the Kvantum settings window from here should already be possible if it's implemented as a KCM, or wrapped in one when installed on a Plasma system. You'd want to talk to its developer about doing that. The ball is in his court right now.
Wed, Jul 1
Didn't you want to do this, Kai? How's it coming?
Do folks have any ideas for alternative layouts that don't explicitly mimic other platforms?
Thanks, that's better now. However the camera silhouette still doesn't match that of other monochrome camera images we have. I'd like to stick to standard iconography if possible. Do you think we should switch the other related icons to use your new camera icon, or would you like to use the one from, for example, preferences-system-windows-effect-screenshot?
One idea I've been throwing around recently is using the Plasma theme for apps too, by making the QStyle load Plasma theme SVGs. This would eliminate the potential problem of Plasma dialogs having a different appearance from apps, because all of them would be using the same theme in the first place. It would also allow a single theme to apply to the entire system, producing a major consistency win, and these newly-all-encompassing systemwide Plasma themes are share-able via GHNS, which is not currently possible using binary QStyle widgets themes. In so doing, the Breeze QStyle would be essentially transformed into a theme engine. Alternatively I suppose we would fork it into a new one, or write a new one.
Mon, Jun 29
It's the only place that I know of, but knowing KDE, there's some obscure ill-used thing where it's critical functionality lol
Sun, Jun 28
I'm open to re-doing this to expose alternative layouts that don't explicitly mimic other platforms. The problem is, I'm not very creative in my use of this functionality. All I really do is put my panel on the left screen edge. I would need ideas for alternative layouts.
Sure, anything's possible. :) My point was that Neon is explicitly a KDE-centric distro. Breakage in non-KDE software is expected and normal; it's not supported at all. If there's a viable way to enable this only when using KWin, that would be idea. If not, I personally still think it's worth doing anyway to improve the experience for neon's target audience of KDE Plasma users.
Sat, Jun 27
Out of curiosity, why would you do that? What's the advantage of Neon over a different distro if you're not going to use a different DE or window manager?
In fact, I wonder if we even need to expose this as a KCM in the main list at all. It's accessible by clicking on the config button in the web shortcuts entry in the KRunner KCM, which is in practice the only place people will interact with it anyway.
That's exactly how the OSD looks in 5.20. :) It's still positioned in the center of the screen, but it's far less intrusive now.
Thu, Jun 25
Wed, Jun 24
This seems like it would be very useful to alleviate the issues I ran into while trying to implement T10495.
The right approach would be for the GTK developers to accept Vlad's patch to fix it for everyone, but of course nothing's easy with those people. :(
Was there a reason why this never landed?
Plasma now depends on Qt 5.14. Is there anything in there that would allow this to move forward?
Tue, Jun 23
Great, sounds like a path forward.
Mon, Jun 22
@ndavis looks like you may need to. Please feel free to do so. I'd really like to get this shipped for 5.20. It's slipped long enough already.
This is essentially done now with the applets shipped in Plasma 5.19, with the remaining tasks just being incremental polish as needed. Great work, everyone!
Fri, Jun 19
Did you like the format? Anything we can improve upon?
This is basically a simple feature request, so I'm going to close it in favor of https://bugs.kde.org/show_bug.cgi?id=422938.
Ah, that sounds like a sensible idea.
Thanks ! Any chance you could submit this as a merge request on https://invent.kde.org/plasma/kwin/? It will probably get more review eyeballs now that we have moved patch review over there.
Done and landed! You can close this now.
When you have a list of items where some have a subtitle and some do not, maybe all of the list items should have the same height anyway. Lists of items with different heights is really weird looking.
I think you already posted this to reddit, right? https://www.reddit.com/r/kde/comments/h9pkpy/crazy_idea_adopt_the_only_true_approach_to/
Thu, Jun 18
Tue, Jun 16
Needs a rebase.
Sat, Jun 13
Doesn't seem like there's interest in this.
I'd like to land this early in the 5.20 cycle so we have lots of time for testing, if possible.
Not really needed now that the notification has a hamburger menu on it.
Make a way to combine BasicListItem and SwipeListItem so we can have an enforced icon size + actions
I kind of think we should just always use a trash can icon these days. What it will do is perfectly clear and we don't have to make a complicated rule.
Before merging, ti needs a kconf update script to migrate existing config files, or else it needs to not rename config file key names.
Crazy idea: can we do the opposite thing and deprecate QStyle in favor of something more flexible and share-able like the Plasma style--and apply it to desktop apps as well? Perhaps we could even deprecate separate widget styles entirely in Plasma 6 and say that apps and Plasma will just always have the same style (and then make sure that the Breeze theme looks good for both). I've never really understood the use case or desire to have Plasma and your apps look totally different from one another TBH.
I wouldn't be in favor of making config windows have the plasma style. In other respect they would match the desktop style (e.g. titlebar) so that would just be weird IMO.
Fri, Jun 12
We discussed this at the sprint and concluded broadly that we could move forward with it (once the TODOs are addressed of course). We also decided for T11746 that we would go with the approach of a sheet that lets you enable and disable parts of a global theme when you go to apply it.
We discussed this in the Plasma sprint today and decided that a new KCM was overkill. Instead, we decided that when you apply a Global Theme, a sheet will appear showing you the things that will be applied, and allowing you to check and uncheck them as you see fit.
I've been using an effective 125% scale factor on my 13.3" FHD screen laptop and it magically made everything feel a ton better. We might want to consider that.
After discussion at the Plasma sprint, we went with D27845: Replace Task Manager with Icons-Only-Task Manager in the default panel, and thicken it. Aaaand it's now in for Plasma 5.20!
I'm going to stand firm on 2.5x gridUnit for now. That works out to 46px, which is not too tall (IMO) and increases touch friendliness by a lot. Let's all keep in mind that this is super easily configurable.
We discussed this and D29501 at the virtual plasma sprint today and concludes that we should probably do the horizontal version here. Nobody overtly hated the vertical version, but issues displaying the clock +date and system tray items were brought up and we don't really have a great solution for those. So let's shelve that idea for now and stick with this one here.
We discussed this and D27845 at the virtual plasma sprint today and concludes that we should probably do the horizontal version. Nobody overtly hated this proposal, but issues displaying the clock+date and system tray items were brought up and we don't really have a great solution for those. So let's shelve the idea for now and stick with this one.
Thu, Jun 11
We've already done some UI design here for the proposed feature and it doesn't seem like an insurmountable challenge.
Oh hey, Kai did this recently. :)
Related to but necessarily a duplicate of T11558: kill plasma components in favour of qqc2-desktop-style. If we do T11558, we won't have to do this, but we can do this without having to do T11558.
This should really be a bug report on bugs.kde.org.
Jun 10 2020
We should probably just do this now and then remove the redundant copies of FindTagLib later.
Jun 9 2020
Thanks! Can you provide an email address so we can land this with correct git authorship information?
Yep, looks great!