We have plasma-open-settings as an agnostic tool to open systemsettings/plasma-settings with fallbacks to kcmshell.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 26 2024
Oct 30 2023
Oct 20 2023
Oct 5 2023
I am interested, also in attending Contributor Summit right after
Aug 1 2023
Apr 24 2023
Feb 6 2023
In T12141#287378, @nicolasfella wrote:Do we allow to configure the shortcuts for applet actions in the UI anywhere?
Feb 3 2023
I think it has proven to be not effective, there were two users at time of this task creation over 1 year ago, every other applet added some sort of "Open $foo" manually if needed.
Dec 8 2022
For service menus KService is used to read it as well
https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/kfileitemactions.cpp#L602
Aug 31 2022
Jun 21 2022
Mar 24 2022
Since QSettings doesn't work ootb see https://mail.kde.org/pipermail/kde-frameworks-devel/2021-December/120057.html
what about
- moving KColorScheme and KColorSchemeModel to KConfigGui
- KColorSchemeManger stays
Mar 22 2022
Yeah let's go with an info button for now.
There is also the Kirigami AboutItem/AboutPage, but that seems overkill to me:
Mar 8 2022
I remember also once wanting to access xdg_surface which you can do in Qt6 but what I can't remember in which context
Mar 7 2022
Mar 6 2022
Mar 5 2022
kwayland-integration to get a seat for a window:
auto seat = waylandWindow ? waylandWindow->display()->defaultInputDevice()->wl_seat() : nullptr;
I guess that would be also available via nativeResource* or a future NativeInterface.
I am gonna add deprecation markers
Jan 13 2022
IDoes the code matter for platforms other than plasma since the kcm is plasma only?
If not maybe it could go to our platform theme?
Nov 24 2021
This has been done elsewhere
Oct 4 2021
we could install an icon into hicolor as fallback
Aug 3 2021
In T12265#261244, @alex wrote:Thanks for the preview, I think it goes in a really good direction.
plugin KCMs are determined by the X-KDE-ConfigModule
I am not sure about this. Shouldn't ideally be all KCMs be in a namespace specific to the app? Like kf5/krunner/kcms.
Jul 21 2021
In T14733#260695, @nicolasfella wrote:After some digging I learned that systemsettings can show an about dialog for KCMs. It's only exposed when using the icon view, which we are on the verge of getting rid of it anyway. The fact that nobody bothered to add it to the sidebar view is a hint about how useful it is
Jul 1 2021
Yeah could make sense, the saving was in fact async and then just made all the calls in saving sync to avoid not saving settings
https://invent.kde.org/plasma/plasma-desktop/-/commit/fcb04768142f6fbc4173f45516decf1182f4a206
Jun 24 2021
So the idea is
- don't export colors to kdeglobals, only save current colorscheme
- because we only need to read one value, we don't need any actual cascading
I think we might be thinking about QJSEngine::setInterrupted
https://doc.qt.io/qt-6/qjsengine.html#setInterrupted
In T13198#258732, @paulb wrote:Changing the release version was an interesting idea, but it didn't really get a lot of support.
We can of course take it to the mailing list if we really want to push for it and keep the discussion going. No promises.That is a pity. Guess we will have to continue insisting, until we wear the devs down 😈.
Or that, or nothing changes in the internal version numbers, and we just call it "Plasma, 25th Anniversary Edition" in promotional materials, making it the leitmotiv of the release, like we called 5.21 "pretty" and 5.22 "stable".
Yes that was also my idea and also changing the user visible places to say KDE Plasma 25th Anniversary Edition like in Kinfocenter, or maybe add it to KSplash, the plymouth theme...
Jun 11 2021
For android we likely want to use the system spellchecking or do we also want sonnet there?
Oh I think we are thinking of different things. I think during the spring the idea was to provide a object that one could use in order to opt into spell checking
Jun 10 2021
What's the problem that we are facing that we need to copy textArea? You probably encountered some issue that makes just adding the spellchecker ( which would also provide the menu ) to the textarea/input not feasible?
May 7 2021
I think one of the problems was that if you do findPlugins and you have the same kcms in two different directories that are in the search path, the returned list contains both plugins. Now if the using code doesn't manually maintain a list of already instantiated plugin ids, this will cause you to load the same plugin twice. Even worse if you use a QMap or a similiar data structure to store your plugins, you will end up using the most unpreffered version since it comes last in the list.
May 5 2021
So it's a workaround for OpenSuse's weird session submitted by them (Fabian)? Imo I would just drop it, they forcing XWayland downstream should not require us carrying patches for that.
Apr 30 2021
Nate I think you created a general task instead of a sysadmin task
Apr 26 2021
So you are saying the ratio between margins/content should always be 8? Does that hold for the other sizes?
In T14397#254578, @iothes wrote:Anyway, so.. you have 16 icons in actions with 2px margins. 16/2=8 yet 22/3≠8. But 24/3=8.
Needs Investigation why 22 was chosen and what benefit 24 would bring.
Apr 22 2021
In T11549#254272, @alex wrote:Is KAbstractFileItemActionPlugin::actions a problem?
What about KFileItemActions::setParentWidget?QMenus needs a QWidget as a parent, see https://invent.kde.org/network/kio-extras/-/blob/master/activities/fileitemplugin/FileItemLinkingPlugin.cpp#L103 as an example.
I am unsure about how relevant the error reporting part is, because not the KAbstractFileItemActionPlugin have a proper feedback channel to report errors.
Apr 14 2021
Would probably make sense to use some Quick thing t oshow the merssage but it's bad at doing proper Dialogs...
Apr 12 2021
Apr 7 2021
Should this be a sysadmin task?
Apr 6 2021
Solution 1: we find a solution for KRecentDocuments (like forking it in KService or below, under a new name), we fork CommandLauncherJob in KService (no name clash, thanks to the KIO namespace), and we can then have these jobs in KService right away. When I say forking, the old class could become a wrapper for the underlying (new) class, but that's more work [for a job it means using the other as a subjob...].
We would also need desktopexecparser and potentially add KWindowSystem dependency for the startup id handling
Solution 2: we (I) just implement these jobs in KIO, and solve the dependency issue at KF6 time.
Seems like the easiest solution to me
Apr 2 2021
That sounds like something like that could make sense indeed. Not sure if just a signal saved would be enough instead of assuming after save() returns that everything will be saved. But as you said an enum is extendable.
Mar 27 2021
std::function has compiler dependent implementation details, but nice to pass callbacks
KLanguageName was mentioned at T12429
Mar 18 2021
I did not link directly to it before, but the standard sound names are in http://0pointer.de/public/sound-naming-spec.html
Mar 16 2021
Considered that and then lamented that C++ doesn't allow redefining a template.
And FWIW code that wants to maintain compatibility with older Qt5 versions can't use this way of declaring the d-ptr, e.g. (backporting a patch):
Feb 26 2021
per the licensing policy https://community.kde.org/Policies/Licensing_Policy
8. Media files such as images may be licensed under the CC-BY-SA-4.0 or compatible licence. Note: Image files must be committed together with their preferred modifiable form such as SVG. Note: CC-BY-SA 4.0 can be one-way converted to GPL 3.
Define which sounds need to be replaced
Feb 18 2021
I rebased it because of the rewrite that happened, can you check if everything is still ok @filipf
Rebase
Feb 17 2021
Everybody ok if I push this, before it is forgotten again?
Jan 27 2021
I think I missed some, so next try:
There is interest in Plasma to indicate the current color scheme only with it's name in kdeglobals in the future. Currently we need to have complicated logic in multiple places because in addition to colors and names in kdeglobals, we need to factor a look and feel (and default look and feel!) into it. Also some users rely on actual colors being in kdeglobals which means we depend currently on kde4breeze update script which does this for kcolorscheme to work correctly (see https://bugs.kde.org/show_bug.cgi?id=428771).
This would remove the need for cascading the single colors. Apps could still overwrite colors by overwriting the current scheme name.
Jan 26 2021
Update from the sprint: We want to look into if we can fully deprecate KWaylandClient for KF6 and use QWaylandClientExtension everywhere. Current usage in KDE (searched KwaylandClient on lxr):
- plasmashell protoocl for positioning and plasmashell
- plasmashell and and dialog (of course)
- Yakuake
- krunner
- ksplash
- logout-greeter
- latte (and shadow)
- spectacle
- plasmashell protoocl for positioning and plasmashell
- FakeInput
- KDE Connect
- KWayland Integration uses a bunch of stuff for its plugins
- idletime
- keystate
- kwindowsystem plugin uses blur, contrast, slide, shadow, plasma window management, plasmashell, shm
- KScreen uses dpms and output
- Oxygen shell, seat and pointer to get a serial for requesting a move
- the platformtheme uses surface, appmenu and our decoration protocols
- KInfoCenter lists every interface and information about seats, keyboards and outputs by listening to the registry
- taskmanagement by the things that do task managemnt
- plasma phone components homescreen and taskpanel
- libtaskmanager
- powerdevil dpms
- xdg-desktop-portal-kde
- plasmawindowmanagement
- output
- fakeinout
- datatadevive by KWIn and klipper
- Of course KWaylandServer and KWin tests which should move to generated code according to the above plan
Jan 22 2021
Do they just not liek the feature or do not how it looks in their titlebar? (The bug report reads more like the latter to me)
Just that is writen somewhere the final key used was: X-KDE-ConfigModule
Dec 11 2020
I am looking into what Qt calls "compile time selection" with Qt6. On the first look it looks exactly what we had with manually importing PlasmaComponents.
Dec 10 2020
Thanks for the explanation!
The Q_DECLARE_PRIVATE, Q_DECLARE_PUBLIC and Q_Q and Q_D
Would it make sense encourage the use of the Qt Macros to also have some uniformity in this way or is it not needed?
Dec 1 2020
In T12200#245744, @aacid wrote:Or even maybe add the action to KStandardAction, given that you need to hook it up manually either way?
That would be a bit of a layering violation, KStandardAction is for standard actions, and i'd say KNS isn't really "very standard", but sure, that'd be an option
Nov 30 2020
No need to throw away the whole thing, it could just return an action without the standardaction and allow slots via template. In summary move to KStandardAction api.
Nov 23 2020
Not yet I think. We still need a new place for KeySequenceItem and not sure if we are happy with KKeySequenceWidget in XmlGui. Currently both do conflict checking and need KGlobalAccel and KConfig(Gui) for that. On top of that they show message boxes so also Widgets
Nov 20 2020
KeySequenceRecorder is now in GuiAddons and both controls are using it
Nov 17 2020
Ping?
Nov 10 2020
Will my terminal always be a service? For example if I manually select a random binary in the kcm?
Oct 23 2020
Beta is out, anyone has found out if the documentation is out there?
KDeclarative MR:
https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/27
Oct 22 2020
Oct 21 2020
So KXmlGui supports being build without KGlobalAccel. The only dependecy I need from other frameworks right now is KKeyServer::isShiftAsModifierAllowed which is a big switch. If I copy that, it can even be put into KGuiAddons. There could be other ways to achieve the same but for let's do a 1:1 transfer of the logic.
Oct 20 2020
If we believe single click is better than we should keep it as default. It makes no sense to have the better option off and the worse option on by default. Otherwise only people who already used single click because it was the default in the past will enable the thing we believe to better and everybody else will stay on what we think is the inferior setting.
Why do you expect this? Microsoft and Apple have 30 years of usability and Microsoft is very much locked to backward compatibility so to change a fundamental user experience navigation behavior . . . very unlikely.
In my opinion, Microsoft and Apple have zero incentive to change this and millions of reasons not to. (you know the millions of people who will be mad because they would be changing a fundamental thing of computing)
No, it isn't. If it were then when Windows tried about 20 years ago they would've kept it. They had a ton of backlash and switched it back to double click.
This does not follow. They had backslash because they switched something not because double click is objectively better.
- It can not be superior when you have to train someone how to do something in contrast to what they expect.
- It is true that you have to train people double click as well but there has been 35+ years of people already trained for this behavior. The superiority argument is irrelevant when you are battling a fundamental usability structure with decades of training.
As you said people also have to train double clicking. And double clicking is even more complicated because some things respond to double clicking but other only to single click. So you need to know where to apply which technique.
In T8187#243302, @clel wrote:
Oct 19 2020
For now I would like to start by moving the recording logic to KGlobalAccel so we don't have two copies and subtle differences between both and bugs because of that because one gets fixed and the doesn't.
Oct 9 2020
Oh nervermind me then, I was a bit confused
In T13729#242488, @nicolasfella wrote:I assume you are worried about plugin KCMs showing up in the launcher although they shouldn't? That's kind of unrelated to that patch.
I see a few possible solutions, all somewhat magic or error prone to some degree though. We could have some kind of hint like X-KDE-ShowInLauncher/X-KDE-DontShowInLaucher. Maybe we should only show KCMs that have X-KDE-ParentApp=kcontrol.
Oct 7 2020
One thing to consider is the settings io slave maybe? (Enter settings:/// into dolphin to see what it does)
In T13729#242282, @ahmadsamir wrote:Note that not all .desktop files are the same, e.g.:
https://lxr.kde.org/source/kde/workspace/bluedevil/src/kcm/package/metadata.desktop
https://lxr.kde.org/source/kde/workspace/plasma-desktop/kcms/autostart/package/metadata.desktopA .desktop file that launches an executable should have an Exec= line as the spec says (IIUC), so we can leave the Exec line in and ignore it if we want.
Ideally the Exec line should be used and not the file name... :)
My 2 p's
Oct 5 2020
If we want to go the icon theme route we could create an icontheme for the flags and breeze could inherit from that. So we could still do QIcon::fromTheme("flag-DE")
option 2 has the advantage that we do not need to maintain the flags (country changes flags or new country appearing). However we do not have control about the appearance of the flag which we would have with option 1.
I don't see how changing navigation/kcm hierachy introduces incosistencies itself.
Oct 2 2020
The histrocial reason is that you could change the color scheme and the changes were written to kdeglobals. But now we only allow modifying color schemes that are writeable so both should be in sync if you change colors/edit schemes now. (Please correct me if I'm wrong, @broulik)
In T12443#217034, @davidedmundson wrote:We don't want to do anything that will break searching - typing "colours" should still work as-is.
To a large extent it seems like we're reinventing something that already exists.
Effectively we just want to have one entry at level 2 and move everything into level 3 and then the searching still works.
The other key difference is that the KCM you open from level 2, doesn't appear at level 3 to indicate it's some sort of parent - but maybe we can find a less invasive way to visually hint that within the current architecture.
Sep 30 2020
Thanks!