Bug 110469 - Existing shortcut does not work in newly titled window
Summary: Existing shortcut does not work in newly titled window
Status: RESOLVED WORKSFORME
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_khotkeys (other bugs)
Version First Reported In: 5.20.3
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Jansen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-09 15:18 UTC by Carl Hudkins
Modified: 2021-04-17 04:33 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carl Hudkins 2005-08-09 15:18:30 UTC
Version:           unknown (using KDE 3.4.2, Gentoo)
Compiler:          gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)
OS:                Linux (ppc) release 2.6.10-gentoo-r6

I have several "Keyboard Input" shortcuts programmed to activate only when I'm working in a particular web-based application.  I have found that they are not available when the window for this app is first created (and is active, has focus), but if I switch away from it and then right back, khotkeys will pick up my shortcuts as programmed.  I have now discovered this is because khotkeys does not detect when an existing window, that did not previously qualify, changes its title so that it now should qualify.  Here is the relevant section from khotkeysrc (only first action copied; the rest are basically the same):

[Data_3]
Comment=Shortcuts for frequently-used sequences when proofing for DP.
DataCount=3
Enabled=true
Name=DP Keystrokes
SystemGroup=0
Type=ACTION_DATA_GROUP

[Data_3Conditions]
Comment=Only in DP proofing window
ConditionsCount=1

[Data_3Conditions0]
Type=ACTIVE_WINDOW

[Data_3Conditions0Window]
Comment=DP Proofing Interface
WindowsCount=1

[Data_3Conditions0Window0]
Class=konqueror Konqueror
ClassType=2
Comment=DP Proofing Interface
Role=konqueror-mainwindow#3
RoleType=0
Title=Proofreading Interface
TitleType=1
Type=SIMPLE
WindowTypes=1

[Data_3_1]
Comment=
Enabled=true
Name=[ee]
Type=KEYBOARD_INPUT_SHORTCUT_ACTION_DATA

[Data_3_1Actions]
ActionsCount=1

[Data_3_1Actions0]
ActiveWindow=false
Input=[:e:e:]
IsDestinationWindow=false
Type=KEYBOARD_INPUT

[Data_3_1Conditions]
Comment=
ConditionsCount=0

[Data_3_1Triggers]
Comment=Simple_action
TriggersCount=1

[Data_3_1Triggers0]
Key=Win+E
Type=SHORTCUT

To Reproduce:  
1. Create Test group; conditions: Window simple:Window title:Contains "Slashdot"; Window class:Is "konqueror Konqueror".
2. Create new action in this group, such as Keyboard input: "Blah!"; Send input to: Action window.
3. Open Konqueror (to blank page or home dir) and then go to Slashdot.
4. Hotkey doesn't work until you switch away and back.

Expected:  Hotkeys should be available as soon as the target window exists, *NOT* as soon as it's switched to.
Comment 1 Carl Hudkins 2006-06-05 15:23:47 UTC
This bug is still present as of KDE 3.5.1.  

So, 10 months after reporting, it's still unconfirmed?  Surely somebody else has noticed this behavior...
Comment 2 Andrew Crouthamel 2018-11-02 04:28:47 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Andrew Crouthamel 2018-11-16 02:41:19 UTC
Dear Bug Submitter,

This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version?

Thank you for helping us make KDE software even better for everyone!
Comment 4 Justin Zobel 2021-03-18 04:25:31 UTC
As this bug was reported a long time ago, can you please test and confirm if this issue is still occurring.

I've set this bug to NEEDSINFO. Once you have added the required information please change the bug back to REPORTED so we know it's ready for investigation or RESOLVED/WORKSFORME if the issue is now resolved.
Comment 5 Bug Janitor Service 2021-04-02 04:33:31 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Bug Janitor Service 2021-04-17 04:33:19 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!