Remove unused include

This feature need to be discoverable easily by end user. We spoke about beginners

Adapt to method rename on wayland server

Simplify the patch and adapt unittest

Default indicator discussion is now on https://phabricator.kde.org/T13008

In D28221#657482, @dfaure wrote:

Ah! Now it actually makes sense to me. If we are changing what revertToDefault() does, then it makes sense to change the if() condition for calling it. Basically, now that it does the right thing in both cases (default from C++ and default from system file) it can be called in both cases, while before it was only called if there was no default from a system file. Right?

I'm still wondering about this though: "If we're saving a value equal to the C++ default, then we have to write it out, otherwise upon reading the global-file default will interfer."
Your unittest shows that revertToDefault() will lead to the global-file value being read.
Doesn't this mean that this code is wrong then?

 if (value == "cppdefault") {
    cg.revertToDefault(key);
} else {
    cg.writeEntry(key, value);
}

That's the code you're using everywhere, so that's actually the code that would be good to unittest ;-)
Isn't this buggy when the value actually *is* cppdefault, and there is a system config file with another default value?

Indeed probably need to update configuration too.

Did you mean documentation? I know this is all about configuration ;) but the bit that's missing is to update the documentation, and add a task to get rid of the hasDefault() everywhere before revertToDefault is called. Assuming I'm wrong above about there being a bug left :-)

• Fix comments
• Ensure we don't have problem if we set value to "defaultcpp" and a global setting override it

ok then ship it

Follow up on gitlab
https://invent.kde.org/kde/kwayland-server/-/merge_requests/1

I don't think we will have same behavior, we don't only check name but also size, type...
If we are ok to fallback in all case to the same font that can work.

Inhibit only modifier shortcut too

OK for me, as long as VDG is ok with this behavior

I will fix that and allow meta inhibition

In D29272#659598, @davidedmundson wrote:

"The Wayland compositor is however under no obligation to disable
 all of its shortcuts, and may keep some special key combo for its own
 use, including but not limited to one allowing the user to forcibly
 restore normal keyboard events routing in the case of an unwilling
 client. The compositor may also use the same key combo to reactivate
 an existing shortcut inhibitor that was previously deactivated on
 user request."

Do we think it's important to have this when this lands or just deal with it if it becomes an issue?

I think it should be relatively easy, just an earlier filter that calls:
waylandServer()->keyboardShortcutsInhibitManager()->getShortcutsInhibitor(surface, seat)->setActive(false);

Simplify code arround QHash and QPair

fix qobject macro indentation

fix test, and take in consideration zzag feedback

Use client not display for KeyboardShortcutsInhibitorInterface

added const to wrong line

Cyril feedback

In T13008#227633, @zamundaaa wrote:

I feared that the overview isn't easily possible. Would it be feasable to show a list of KCMs that have non-default values? I'm not sure how useful that would be though, if the user would already know the setting they're searching for is in a particular KCM they probably would've found it themselves.

add space and rename variable

fix variable name

take in consideration zzag review

Add missing const ref and fix coding style

In T13008#227538, @zamundaaa wrote:

I know this is a bit outside the scope of this task but maybe a backup & restore page with a reset button would be good? This page would of course have to have appropriate warnings but it would probably help some users if they could

• get an overview of all settings they changed, with a list of links to the actual settings pages?
• backup their configuration
• restore old configurations
• reset all settings This would enable users to freely experiment with the settings without the fear of breaking something / toggling some behaviours they'll not find again. Just back up and everything's safe. Backups into a file then that would also easily allow users to synchronize their settings from PC to PC without needing to copy their whole home or .config folder (possibly integrate KDE Connect here?). I definitely agree that a reset button is dangerous but I think if we display appropriate warnings and require the user to put in their password then it should be just fine. After all, how many users have accidentally reset their Android phone?

Expose plasma window management interface instead of internal id to avoid another window id exposed

Increase protocol version and use const ref for QVector parameter

• Send stack order on bind
• Check ressource have good protocol version

We don't manage default for volume for example so nobody as idea to put revert to default for volume, those icons need only to be when that make sense.
I guess we can use this task to also discuss https://phabricator.kde.org/D28461 because they are linked.

Indeed probably need to update documentation too.
Not sure why we didn't allow to track default value from file in the past by the way.

In D28740#652419, @broulik wrote:

This is for displaying whether do not disturb is on. The "until disabled" option just sets it to one year in the future. But it's odd to show "until 2021", so we don't show the date when it's too far in the future.

According to settings.h documentation
When invalid or in the past, do not disturb mode should be considered disabled.

Add KConfig unittest

Ok I will add a kconfig test

fix build

Fix import order (remove unused one)
Remove QTimer m_timer (field not used). Let me know if you want this one in a separate commit.

fix leak and style

In D28817#647930, @anthonyfieroni wrote:

In D28817#647912, @bport wrote:

I don't think we have a leak, on destructor we delete all view
qDeleteAll(m_views);

At that point, when rootObj is nullptr, view is not added to m_views.

Remove border and shadow

I don't think we have a leak, on destructor we delete all view
qDeleteAll(m_views);

update commit message

update commit message