The best possible way of course would be that we support activating desktop actions via dbus and do so in kglobalaccel:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus

Hmm that requires that we have qtpaths at build time which is for example shipped in qttools5-dev-tools. And that between build system and run time qdbus is in the same location. Is that an assumption we can make? I'm not an expert but I think there is never a case where you would compile on one distro and then try to run it on another?

Comments

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.