User Details
- User Since
- Apr 15 2015, 5:09 PM (465 w, 5 d)
- Availability
- Available
Jul 31 2023
Jul 10 2023
- Replacement for Dialog is in progress
- Issues of FrameSvgItem are still valid on KSvg's FrameSgItem
- Theme.cpp in general is here to stay as an helper class to make KSvg retrocompatible with old plasma themes, with svg stuff gone will be possible to delete almost half of its code
- However will be removed from QML bindings.
- the "2 themes per process" thing is partly solved: Kirigami.Theme uses plasma colors in plasmoids and system colors in config dialogs now
- the other part of "2 themes per process" is not solvable right now, which is what forces us to use the PlasmaComponents3 import in plasma rather than generic controls, I think this will stay for whole Plasma6 lifecycle
current status:
SortFilterModel still to be adressed (port every plasmoid to the kitemmodels version)
We have 2 splitted things:
Done indeed
Plasma::Package should be removed as it's already split
Feb 3 2023
I strongly disagree on this one.
Sep 9 2022
May 12 2022
I'm not convinced this is neede.
Apr 21 2022
that's needed in the pacgages metadata itself, but probably yeah, not needed in the package structure metadata itself, I wouldn't oppose that
Mar 5 2022
done since a long time
we should go class by class in plasma core and mark deprecated those that shouldn't be there anymore and where others should go
Jan 16 2022
Nov 15 2021
Nov 12 2021
do we need regular kweathercore releases in worksoace? (or even.. framework?)
Oct 29 2021
Aug 17 2021
So would always keep the kpackagestructure key in installed metadata for completeness
Not only cmake is used, knewstuff also installs them downloaded from the store
Jun 24 2021
Jun 15 2021
I indicated the last hour 18-19 utc as Plasma/LAtteDock, though we can discuss about it at any point if is better for you as timing.
Of course you're invited to participate on the rest as well :)
Jun 14 2021
sure
There are 3 hours booked for plasma on wednesday.
maybe we just can use one of those for this?
Jun 9 2021
I agree with the proposal.
Since this would correspond to the PackageStructure to load, it could even be called KPackageStructure
Apr 24 2021
Apr 22 2021
the problem is really having item views with more than one action per item.
Apr 19 2021
Whether it needs to be maintained for the lifetime of kf6 depends if we manage to port every dataengine beforehand.. but is probably something that can be dropped during kf6 lifetime
Apr 9 2021
Attempt with activities
Apr 8 2021
This is a rough idea:
The concern i have abut the whole thing is how the configuration is disconnected from the actual desktop and panels (also having panel1/panel2 and what not that can't give you any idea what it is). the only reason this is necessary at all, is that some may be invisible due to a disconnected screen.
If the screen() is the connector name, what happens wrt the "primary" screen? if i attach an external screen to laptop, and the external screen is set as primary, i expect desktop and panels to migrate to the new primary screen, therefore swapping their associated connector
Mar 29 2021
Also, some general considerations:
back then when measuring the performance gain offered by that index was measurable, but somewhat small anywyas... if the format gets ported we don-t need a migration strategy as the index is not necessary and canbe recreated, but if the on disk index is just killed... i think all considered i wouldn-t be against such a decision
Mar 28 2021
> I cleared the in memory cache to make sure they are newly loaded. @mart is that correctly done?
Mar 27 2021
Mar 5 2021
one way i would see it working without hover and in some/most cases is if we pay attention to have always at most one visible action and put everything on a menu: most of those actions really aren't that important to warrant to be always reachable with one click only
Mar 2 2021
i do agree that keyboard navigation should always work even on hover only controls (so make all the buttons appear also on focus)
As i said previously I was and still am very against the commit which changed kirigami listviews and i'm still considering to revert it.
The result looks very cluttered and not any more explanatory than before, as you have giant label-less columns of icons all the same. it makes something very ugly and very confusing for no advantage whatsoever.
Feb 25 2021
perhaps the disk cache could even be ported in normal text json format?
Dec 14 2020
Nov 30 2020
As background, back in the last KF6 sprint (december 2019, before the world ended) it was done a big review of each framework in order to untangle the dependency tree as much as possible (and remove dependencies between frameworks, if possible making them rise in tiers. (this task is part of the kf6 workboard)
Nov 26 2020
Oct 28 2020
the api which plasmoids use to notify "apply needed" is kinda weird.
the "final product" must be not in Kirigami, but somewhere it can depend from KConfig (and better, KconfigXT so KConfigSkeletonItem and what not)
Oct 20 2020
first thing: this settings should be published by kuserfeedback and see how many actually go to the lengths of changing the default (and have this data point independent of those from distributions that come with the default changed)
Oct 14 2020
here is current status:
Oct 12 2020
I like the idea, and i can work on some infrastructure to make some kind of loading kcms from within other kcms work correctly.
I would open them with that breadcrumb mechanism whem opened..
Sep 8 2020
Jul 31 2020
Jul 22 2020
There are several arguments against it:
- the thing that triggered my attention on it is the desktop context menu entry: usually context menus should have actions and description of what the action does as text
Jul 20 2020
I ask to reconsider this.
KRunner is a terrible jargon name, which is perfectly ok for a framework, but that's it.
This was a terrible decision.
KRunner is the worst jargon one can imagine and shouldn't be anywhere in user facing UI
Jun 29 2020
Jun 13 2020
go for it :)
Jun 12 2020
after discussing it a bit thoroughly during the sprint we came to the conclusion is the best solution for now
Jun 11 2020
feasible technical solutions at the moment are
- QQmlAbstractUrlInterceptor based solution: kinda error prone but easy to do
- configuration windows in a separate process: quite complicated and error prone, would take a year to do
- having config windows with the plasma style
the simple fact is that we can't just dump all the custom plasma themes in kde-look.org, there are just too many users likeing, using and creating those.
especially, is a no-go replacing it with a completely inflexible, obsolete and hard to create/share system like QStyle
If that ever is to be done, a theme engine that can load styles which are mostly images and text files (so, sharable on the store) that works on both widgets and qml should be done
please no.
it may sound attractive, but besides the technical diffivulties of writing in the proper place in the plasma config, there is the question of background which monitor of which activity that would require doing a quite complicated spacial ui mapping in systemsettings, where just clicking configure on the actual wallpaper one needs to change requires no mental mapping, it's just there.