Bug 444730

Summary: Kmenu entries launched with assigned shortcut do not execute command properly
Product: [Frameworks and Libraries] frameworks-kglobalaccel Reporter: Dominik Kummer <admin>
Component: generalAssignee: kdelibs bugs <kdelibs-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: nate, nicolas.fella
Priority: NOR    
Version First Reported In: 5.87.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

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