codestyle++

As per the api docs you can QConcatenateTablesProxyModel starting with Qt 5.13

Rebase once more

In D23316#572942, @ngraham wrote:

All functionality works perfectly for me. However this regressed the default width of the settings window. Not it's not wide enough to accommodate all controls without an ugly horizontal scrollbar:

I still think this a cool feature, but I have the feeling this can be done in a much shorter patch. This seems to me a bit like overkill. Would be awesome if maybe somebody else could weigh in.

rebase

Need a bit more height

const

According to https://community.kde.org/Frameworks/Policies

In addition, a Qt LTS release remains supported until the next Qt release after the next Qt LTS release. For instance, when Qt 5.15 is released, Qt 5.12 remains supported until Qt 5.16, to give time for people to migrate from Qt 5.12 LTS to Qt 5.15 LTS. When Qt 5.16 is released, both Qt 5.12 LTS and Qt 5.13 are dropped, to go back to "last 3 minor Qt releases".

That means we would support 5.12 until the end? Can we still mark it as deprecated sometime?

There is also the case of the Konqueror gesture things? Are these gestures only local to Konqueror or are they somehow global and go for that reason through khotkeys? As I'm not a user of Konqueror maybe @dfaue can offer some insight?

In D25626#569714, @kossebau wrote:

Yay, thanks for fixing this. Not sure if if(MSVC) is the proper condition, due to not being into the windows side of things, so that part better has someone check who enters the dark side now and then. :)
Otherwise +1 for this.

I used it because it is the same condition inside ECMGenerateExportHeader.cmake which enables __declspec(deprecated(text)).

In T12275#211936, @davidedmundson wrote:

Do we need additional API compared to https://doc.qt.io/qt-5/qml-qtquick-tableview.html?

That tableview is a grid of delegates in a flickable.

It does not have the frame + scrollbars + themed delegates

Maybe it is enough to have a common flickable container and have every user duplicate that little bit?

In Breeze it uses the window color I think? See breezestyle.cpp#L5767 and the following lines

address comments

Do we need additional API compared to https://doc.qt.io/qt-5/qml-qtquick-tableview.html?

Gwenview has a quality thingy in it's save dialog D23106

Ping.

Correctly read default value dependent on another config entry

In T2050#210134, @davidedmundson wrote:

Good to see this porting in place. +++

With my Plasma hat on, is it worth leaving this alone till Plasma 6
(if it ain't broke...)

Or is it worth dropping before the next LTS so we don't have a burden to maintain?

Thoughts?

I think we can't remove it right now without having 100% feature parity. For example there is this weird action available by default that opens google in your browser (see https://cgit.kde.org/khotkeys.git/tree/data/defaults.khotkeys#n307).

In T7267#208671, @GB_2 wrote:

Also, I think the search should look through all components/categories instead of you having to manually find the correct component/category.

In D25369#566318, @guoyunhe wrote:

I didn't find good solutions for QQC2. It has been a blocker for a long time https://bugs.kde.org/show_bug.cgi?id=403153

I added a similar fix earlier today to
D23316

Also use enum for the last selected captureMode

• Fix typo in update file

address comments

In D25427#565364, @meven wrote:

In D25427#565342, @davidre wrote:

This approach will probably fail when the geometry stretches across multiple outputs with different scales.

I am well aware, this a naive and basic approach to gather some learning feedback.
And Those changes are only needed for Wayland.
I need to break the geometry by screen get their scale and then put all together in a virtualScreenGeometry according to the passed Geometry.
But I need to learn how to get there, dig in the code and/or ask questions if I may.
I have a two screens system at home to test this.

This approach will probably fail when the geometry stretches across multiple outputs with different scales.

In T12063#208760, @davidedmundson wrote:

In the future if we want to embrace the use of desktop files also for shortcuts.

IMHO having a desktop file specifying DBus callbacks is working well enough that it should be the sole way of an app registering global shortcuts. Then we only need code in client apps if they want to do any kind of configuration

The old method suffers from not working before an app is first run, and not cleaning up when an app is removed.

It'd be a radical change, but global shortcuts are generally used by plasma not apps.

We have this new infra in-place already, so we could try and build on that, port things and see how it goes already.

Another thing is the magic isConfigurationAction property that is used which changes behavior of some functions if present which doesn't make things easier if you want to configure stuff and you have to read the code to see if you need it or not.

Why KDE/Qt Application style? Every Qt Application will have that style and not only KDE Applications. I also fear that somehow this will strengthen the false idea of some users that Applications and Plasma are intertwined.

No, I wanted to let David take a second look. But I can commit later.

In D25307#562652, @esjeon wrote:

Also, I don't see anything wrong with adding this, since it merely exposes deleteEntry method already in the API. Some projects do rely on it, so why should it be kept away from actual human beings?

In D25307#562613, @esjeon wrote:

What shortcuts had you in mind to delete?

My specific interest is deleting shortcuts of removed KWin scripts. ( e.g. https://github.com/esjeon/krohnkite/issues/31 ) Such shortcuts keep appearing on Global Shortcuts dialog unless manually deleted. Also, while developing the script, I leave garbage values behind, and having this around will be handy.

As noted in that issue for removing shortcuts modifying kglobalshortcutsrc is not enough as kglobaccel will write back. A reliable way to do that is via DBus.

I don't think deleting a entry from a config file makes sense. If you delete an entry you will get the default value on the next read.

Is the FooBar class for testing? I don't see it used anywhere. (and would guess soofrom the name)

In D25293#562511, @ngraham wrote:

In D25293#562309, @davidre wrote:

Sorry, it doesn't work for me either. I didn't relog before testing and I guess it was still using the qdbus commands. KLauncher gets the right arguments I think:

What does this mean? Sorry, I'm pretty new to dbus.

I don't know but KGlobalAccel uses KLauncher to execute the command found in the Exec line of the desktop file.
However I noticed something weird when manually using your dbus-send commands. dbus-send --session --dest='org.kde.Spectacle' --type=method_call '/' 'org.kde.Spectacle.StartAgent' only seemed to work every second time.

Maybe we can do this for 20.03 with 19.12 now branched. This would leave us some time to test it. What do you think @ngraham?