Are there any movements of merging dolphin/dolphin-plugins?

Can the kcminit stuff be considered plasma-internal API?

The last suggestion was agreed upon by the plasma people, then we can use a standardized symbol name.

On the KF6 weekly it was agreed that the stuff is not considered public API.

There were some choices discussed at the KF6 weekly:

• Install desktop files into specific dir like plasma/kcminit and then query metainfo from there => bad because we would have to open two files and the init phase stuff can be removed. Also the X-KDE-Init-Symbol could be a standardized value.
• The namespace solution as above would work, but as said it is ugly to make systemsettings depend on the kcminit specific stuff
• Just loading them as plugins => the functions are linked to the KCMs because there they are also called on-save. Having a small static lib would work though

In T14840#262669, @ngraham wrote:

On second thought, probably not worth the trouble. We can always re-evaluate what lives where for Plasma 6.

On second thought, probably not worth the trouble. We can always re-evaluate what lives where for Plasma 6.

In general I am wondering if it is a good thing to keep loading this function pointer from the KCMs.

In T14335#261955, @davidedmundson wrote:

I don't think the phase split makes sense,

Ack, I'm happy to drop that.

I think in general the concept of kcminit makes some sort of sense. It allows us to drop specialisations in startplasma, and that's a good thing.

I don't think the phase split makes sense,

@alex it isn't.

How is this tied to kinit at all? As far as I can see a QFunctionPointer is read from the lib and that function is then executed.

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/303 Took care of the virtual load methods.

I did some benchmarking/debugging and there are some other performance issues in kpackage.

I don't particularly care about the exact name, so fine with me

In T14757#261124, @alex wrote:

For KCMs we have a X-KDE-Library key in the metadata, I would suggest we do the same here.

The issue is that this key gets removed when the file is converted to JSON.

Usually this makes sense, because the JSON is embedded in the plugin. In case we convert the deskop files to JSON, as proposed in T14564 we could just as easily add it back.

I will work on the KPackage bits. I have touched the related code recently and a familiar with it.

We could for example assume that for the package structure "Plasma/Applet" the plugin file is "plasma_applet.so".

Something that's quite prominent in KPackage::PackageLoader::loadPackage() is loadPackageStructure. This is because it iterates over all plugins in "kpackage/packagestructures" to find the right plugin. If we could infer the plugin name from the package type that would help speed this up. We could for example assume that for the package structure "Plasma/Applet" the plugin file is "plasma_applet.so". This still would need compatibility code for Plasma 5 though

plasma-pa, plasma-nm and kdeconnect have been ported to have json package metadata, so the desktop->json conversion is not an issue any more on my system

For KCMs we have a X-KDE-Library key in the metadata, I would suggest we do the same here.

Another thing that's quite prominent in the profile is KPluginMetaData::fromDesktoFile()

Ah, darn.

In T11930#260908, @ngraham wrote:

You can force a particular color group though.

You can force a particular color group though.

Proposal to remove: https://invent.kde.org/plasma/systemsettings/-/merge_requests/72

I would be in favor of removing it.

In T11930#259816, @GB_2 wrote:

If this hasn't already been fixed then we should just hardcode the colors, looks the best and should be easy to do.

If this hasn't already been fixed then we should just hardcode the colors, looks the best and should be easy to do.

ahh, alright thanks for explaining

In T14619#259036, @mikeljohnson wrote:

I thought the whole point of this is to use QPallete with above comment being more about that than the syntax

I thought the whole point of this is to use QPallete with above comment being more about that than the syntax

In T14619#259005, @mikeljohnson wrote:

am I correct to assume that with this approach we would go from:

Kirigami.Theme.colorSet: Kirigami.Theme.View

to

palette: Kirigami.Theme.View?

if so, that seems pretty good

am I correct to assume that with this approach we would go from:

I was thinking we might need equivalents to NegativeText, NeutralText and PositiveText in QPalette for this to work out, but then I realized, couldn't we have Negative, Neutral and Positive Contexts instead? Maybe it would be extreme overkill to have a whole QPalette of colors for a negative context, but it would allow us to tint backgrounds or text differently based on the type of GUI element we're giving the negative color to.

Good point, although we already have BasicPlasmoidHeading, which adds upon PlasmoidHeading

On a technical side this ties into T11587 (Making KColorScheme Tier 1, e.g. in KGuiAddons)

I'm not sure this makes sense on a semantic level. The current PlasmoidHeading happens to be very similar to a toolbar, but is that always going to be the case? I don't want us to be locked into a situation where we can't change things later on because they would break other users of ToolBar or because the ToolBar API is not suitable any more

I can search for the names of these two categories (they are named differently now) and I can find these products with the product search bar.

so, just your browser with working microphone, optionally webcam, and there will be a link under meet.kde.org. It will be on kde-hosted bigbluebutton server which is web based and both chrome or firefox works okS

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 :)

In T12433#258028, @mvourlakos wrote:

To close the loop on this, the feature has now been integrated, and I have submitted a merge request to remove the button from the toolbar: https://invent.kde.org/plasma/kwin/-/merge_requests/1104

This is a behavior provided by the upstream QMenu component and it's not something we can override in any KDE code. You would need to report it to the Qt people.

Have you ever wonder about not disappearing popup menu after choosing option ?

No prob for me whatever works best for you. Slots in Wednesday are 16:00 - 19:00 UTC so that makes it evening/night in Greece 19:00 - 22:00 and I can participate.

There are 3 hours booked for plasma on wednesday.
maybe we just can use one of those for this?

I had booked one for Monday, But Marco has a special "Plasma day" which we can maybe move to.

Please report bugs/complaints/proposals for changes to the new widget style to https://invent.kde.org/plasma/breeze/-/issues/

One thing that it looks weird is the pressed state of buttons: they show a gradient effect, but the normal state doesn't have it (or it has, but it's really subtle). I think the button should have a very subtle dark background with a inner shadow.

Media Session API gained "video conferencing actions, could be useful to expose those actions through p-b-i somehow: https://web.dev/media-session/#video-conferencing-actions

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/268

If it is 21 June it works perfectly.

In T12433#257331, @davidedmundson wrote:

Nope, lets go pick a time. All the slots are empty currently.
I have all the availability. Does Monday afternoon work?

Nope, lets go pick a time. All the slots are empty currently.
I have all the availability. Does Monday afternoon work?

@davidedmundson is there any update concerning your proposal to have a BOF for Latte in Akademy?

Personally I agree with the KWin bug report that it doesn't belong in KWin, as this is primarily a notification/audio thing instead of a window management thing.

No matter what, I really like using an arrow to the right of the password field instead of an OK button.

Wouldn't this bring an inconsistent with other parts of the system which has "ok" and "cancel buttons" (like save dialogs, for example)?

In T8569#227191, @ngraham wrote:

No matter what, I really like using an arrow to the right of the password field instead of an OK button.

In T8569#257091, @aronkvh wrote:

here is another option, which would be easy to understand for me:

here is another option, which would be easy to understand for me:

In T8569#257072, @apol wrote:

Would it maybe make sense to style it into Plasma rather than like an application?

In practice, it's 100% a plasma component, on any other DE you'll have the native dialog and it makes sense the concept of "Your system needs authentication" rather than "a window coming from space wants your password".

Would it maybe make sense to style it into Plasma rather than like an application?

In T8569#223421, @manueljlin wrote:

What about something like this?