- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jun 2 2020
May 29 2020
May 28 2020
May 26 2020
Remove unused include
May 18 2020
This feature need to be discoverable easily by end user. We spoke about beginners
May 12 2020
Adapt to method rename on wayland server
May 11 2020
Simplify the patch and adapt unittest
Default indicator discussion is now on https://phabricator.kde.org/T13008
May 5 2020
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
May 4 2020
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
Apr 30 2020
Apr 29 2020
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
Apr 27 2020
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
Apr 24 2020
take in consideration zzag review
Apr 22 2020
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
Apr 21 2020
- 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.
Apr 20 2020
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
Apr 18 2020
Ok I will add a kconfig test
Apr 17 2020
Apr 15 2020
fix build
Apr 14 2020
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