Bug 444730 - Kmenu entries launched with assigned shortcut do not execute command properly
Summary: Kmenu entries launched with assigned shortcut do not execute command properly
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 5.87.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-31 17:13 UTC by Dominik Kummer
Modified: 2024-05-02 13:17 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Kummer 2021-10-31 17:13:15 UTC
Application launched by shortcut do not respect command argument quotes as expected.

STEPS TO REPRODUCE
1. Start kmenuedit
2. Copy "Falkon" entry to "Falkon Creative"
3. Change command to 'falkon --no-remote --wmclass="falkon creative" --profile creative %u'
4. Assign keyboard shortcut to launch entry "Falkon Creative"
5. Launch Application with shortcut
6. Open window rule settings, add new rule, detect Window Properties from previously shortcut-launched "Falkon Creative" entry
7. Observe window class being set to ' "falkon' instead of ' "falkon creative"' set by --wmclass parameter
8. Close "Falkon Creative", restart it with Krunner
9. Recognize the correct window class "falkon creative" being set

OBSERVED RESULT
Application window class set by command argument --wmclass="class name" is obviously not respecting argument quotes if application is started via keyboard shortcut.

EXPECTED RESULT
Handle Krunner launches and Keyboard shortcut launches in the same way
Comment 1 Nicolas Fella 2021-10-31 17:48:38 UTC
It seems like this works fine once the kglobalaccel5 process is restarted
Comment 2 Bug Janitor Service 2021-10-31 18:06:56 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/31
Comment 3 Dominik Kummer 2021-10-31 20:10:03 UTC
I just tried to restart kglobalaccel5 but still observe the same behavior.
It seems that 
--wmclass="class name" 
is parsed as 
--wmclass="class 
or something
Comment 4 Nicolas Fella 2021-10-31 20:17:28 UTC
That seems to be an additional issue unrelated to the one I am describing.

Looking at the code I see why it is failing, it splits the string on spaces, ignoring the shell syntax: https://invent.kde.org/frameworks/kglobalaccel/-/blob/master/src/runtime/kserviceactioncomponent.cpp#L41
Comment 5 Dominik Kummer 2021-10-31 20:23:55 UTC
Oh I see, maybe another "splitter" is used in krunner? Something like QCommandLineParser ?
Comment 6 Bug Janitor Service 2021-10-31 20:28:27 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/32
Comment 7 Dominik Kummer 2021-10-31 20:36:36 UTC
well KShell::splitArgs
perfect!
not even based on QCommandLineParser
Thanks!
Comment 8 Nicolas Fella 2021-10-31 20:54:49 UTC
Git commit 8a213c78cf1acfef28f7b7ba2bb5c4414100dc19 by Nicolas Fella.
Committed on 31/10/2021 at 20:24.
Pushed by nicolasfella into branch 'master'.

Properly split exec line args

Splitting at space breaks when using spaces escaped by shell syntax.

Consider the following exec line: app --arg="foo bar"

Previously this would be split into: (app, --arg="foo, bar)

Now it is correclty split into: (app, --arg="foo bar")

M  +3    -1    src/runtime/kserviceactioncomponent.cpp

https://invent.kde.org/frameworks/kglobalaccel/commit/8a213c78cf1acfef28f7b7ba2bb5c4414100dc19
Comment 9 Nate Graham 2021-11-03 19:51:34 UTC
Anything left to do here, or is this fully fixed now?
Comment 10 Dominik Kummer 2021-11-03 19:54:03 UTC
unfortunately I havent compiled and tested the solution yet, but the code snipped looks very promising!
Comment 11 Nicolas Fella 2021-11-03 19:54:37 UTC
well, https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/31/ isn't merged yet, other than that we should be good