In D27540#615129, @ervin wrote:

In D27540#615105, @davidre wrote:

In D27540#615092, @ervin wrote:

In D27540#615061, @davidre wrote:

How does it look? Will this be opt in for other users of KConfigDialogManager?

I'd say you should try it. ;-)
I really need wider feedback on how it behaves in different context. Currently the patch makes it mandatory for everyone.

I use KConfigDialogManager to manage the settings in Spectacle MainWindow which are instant apply by
connect(mConfigManager, &KConfigDialogManager::widgetModified, mConfigManager, &KConfigDialogManager::updateSettings); and I don't like it that they appear there too

You mean they appear and stick around? Or they appear/disappear immediately?
If they stick around I'd indeed have to check why the state isn't recomputed on the updateSettings call...

a setting which is currently dirty or which differs from default value.

What is your idea behind this? After first seeing this patch my intuition was that it would show for unsaved changes. But then I was confused when I open a SettingsDialog that there were already marks even though I changed nothing! I would expect them only for unsaved changes, I don't know how other platforms handle this if they have something similiar?

Currently it helps the user find out the unsaved changes (the least useful in some way, or your immediate memory is not good) but it also helps the user find out which of her settings differ from the default values (and that's indeed something you will forget over time and wonder "why the hell is the defaults button enabled").

Hope the extra context helps.

In D27540#615092, @ervin wrote:

In D27540#615061, @davidre wrote:

How does it look? Will this be opt in for other users of KConfigDialogManager?

I'd say you should try it. ;-)
I really need wider feedback on how it behaves in different context. Currently the patch makes it mandatory for everyone.

The editmarks should probably respect the visibility of the associated widget. In this picture I use a invisble lineedit to manage the settings of the QButtonGroup beneath (QButtonGroup isn't supported by KCOnfigDialogManager)

How does it look? Will this be opt in for other users of KConfigDialogManager?

So I think this is ready to be merged and I would do so this weekend

Code style and typos

In D27481#614167, @davidre wrote:

I think the deisgn og the spacer could be better in edit mode to clearly mark it as a spacer but that can be done in the future if desired.

I think the deisgn og the spacer could be better in edit mode to clearly mark it as a spacer but that can be done in the future if desired.

Could you also add documentation to whatever https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html is generated from?

In D27484#613770, @kossebau wrote:

I would push to release/19.12, given this is also a typo fix, okay?

In D27470#613348, @meven wrote:

This looks like a good kcms to convert to KConfigXT...

In D27450#613086, @crusader wrote:

In D27450#612700, @davidre wrote:

Can you explain the process of choosing which frameworks to highlight?

Why are we listing flatpack as the first deployment option and distros last? Is the order random or do you want to show a preference here?

For frameworks, 3 of them were suggested by Carson Black. And the other were mentioned in a couple of places outside api.kde.org . I guess you can consider that the choosing was random

for packaging, It was random. Pls suggest the preference order so that I can make the necessary changes

Very well thought through proposal! +

Do your second step here imo

If you touch the xsd do you neeed to increase the version number?

In D27438#613050, @The-Feren-OS-Dev wrote:

In D27438#612719, @davidre wrote:

There is now not clickable space between items:

At least it should be clickable

For future reference, how do you get that size examining mode in Plasma Desktop Workspace?

There is now not clickable space between items:

units is the id of the Object in the org.kde.desktop style (and in the default units file). But that is not true for all styles: In kirigamiplasmadesktopstyle it's unitsRoot and in kirigamiplasmastyle it doesn't have an id. The proper way to acess Units is through Kirigami.Units. If you are using plasma.core it also clashes with units. (I hope that's correct)

Can you explain the process of choosing which frameworks to highlight?

Can we not add more stuff to krdb, please?

I think the commit message got bit messed up David, pls fix before commiting :)

After clicking through the before after I still think it's to much

I think 0 doesn't look cramped at all. Increasing the spacing also increases the space usage . -1 from me

I guess? Note that I authored this diff :)

Add new files

remove debug remains

Explicitly set TextColor and palettes of the labels and react to parent changes . For example necessary for konsole
that uses stylesheet which break palette propagation and reparents the widget after creation.

Stretch is in https://doc.qt.io/qt-5/qfont.html#Stretch-enum

remove unused variable

For reference the dialog from plasma-framework:
https://cgit.kde.org/plasma-framework.git/tree/src/plasmaquick/configview.h

Ping

In D27272#608602, @ngraham wrote:

I think the emblem icons look great in your "After" screenshot.

Wouldn't it be easier to have KDevelop use these emblem icons from their current names rather than symlinking the icons you want to use to new files with different names? Semantically it seems wrong; status icons are monochrome and use the action icon style. See https://hig.kde.org/style/icons/action_status.html.

As I said on Telegram, consistency is not merging two on the outside similar looking things. It's making our software look and behave in similar ways like having reusable components and solutions or the most common elements (hello Frameworks!). The same is true for KParts using this technology we can build applications that all serve their specific purpose but have the same look and behavior of their core part (for example Konsole and Yakuake). Of course you could merge all these apps but that way you end up with behemoths of apps with giant codebases and complicated configuration options to support all possible use cases with code that is overly complex and brittle because of said options.

Ping

Ping, how should I proceed?

If you land this please update the summary before. No need to have all the variants in the commit message it should be about the actual change. Thanks :)

I just took a look at KSelector and it actually inherits minimum and maximum properties from QAbstractSlider so we could just drop these custom properties for KF6

Update comment

I would drop the KDE/Qt Part because the settings are not specific to them but general settings and this service is needed to apply those settings to some applications. So "Applies Settings to Gnome/GTK applications'

Something like this:

In D27035#604026, @ngraham wrote:

Uh-oh, now it looks like this in Konsole:

Compare to the current appearance:

I recall wrestling with this issue in D12508. Might be worth looking over that.

In D27035#603619, @dhaumann wrote:

Better :) with corners I mean the 1-3 pixels left due to the rounding corners. These pixels were once also drawn as background although they are outside of the frame. It may be a minor detail, but imho such details are important. But indeed, the screenshots look good.

Next test: open a file in kate. Now either change the file externally or delete it. Kate should show an animated KMessageWidget. Does it also correctly work with a small kate? I.e. small width of kate window?

Use parentWidget()

It's harder to fix because on 19.12 we save not the last capture mode but the index of the combobox which doesn't map directly to the capture mode. And I don't want to change what's being saved in the config on stable or duplicate the combobox mapping here (which also is broken) so I will push this only to master

Kate with this patch and Oxygen style:

Draw opaque and mix the colors manually again.

Fix code style

In D27035#603460, @dhaumann wrote:

Does that also work in Kate for floating messages like when the search wraps? What I want to know is whether the corners behind the green frame are transparent in this case, or whether the corners are painted solid. If I remember correctly, these kind of bugs were the reason to use Qt StyleSheets. And it must work with all styles.

Please do NOT yet commit, especially since we'd only have two days of testing period: Saturday, 1st of February is the next frameworks tag.

In D27035#603460, @dhaumann wrote:

Does that also work in Kate for floating messages like when the search wraps? What I want to know is whether the corners behind the green frame are transparent in this case, or whether the corners are painted solid. If I remember correctly, these kind of bugs were the reason to use Qt StyleSheets. And it must work with all styles.

Please do NOT yet commit, especially since we'd only have two days of testing period: Saturday, 1st of February is the next frameworks tag.

Should or shouldn't it be transparent? Also I don't understand which part should be transparent and which shouldn't? The border was never transparent and the background also not. Screenshots: