|
Bugzilla – Full Text Bug Listing |
| Summary: | Profile Chooser adds ampersand '&' to profile name | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Egbert Eich <eich> |
| Component: | Mobile Devices | Assignee: | Helmut Schaa <hschaa> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | behlert, dmueller |
| Version: | RC 4 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Fix | ||
|
Description
Egbert Eich
2005-11-14 11:03:02 UTC
Is the ampersand also printed in the "Switch to profile"-list? No, it isn't. This is really strange. Could you kill profile_chooser and run it in a terminal? It should print the command it going to run on stdout. Strangely after restarting the profile chooser the problem went away. Should we close this and I reopen it when it happens again? Yes, please do so. 'heisenbug'. Will reopen when the next alpha particle hits. For the record: I've just encountered the same problem. It's also interesting that the place where the & appears in the profile name the following character in the profile list has an underscore. It seems like this is a malfunction of the hotkey (aka accelerator) system in Qt (or KDE libs). It's quite difficult to debug, as it is not reproduceable. I'll set keyboard shortcuts for the popup menu to disabled, which is default according to the documentation anyway, but you'll never know. Created attachment 114135 [details]
Fix
It looks like the ampersands get added by KDE to create hotkeys. This seems to be unrealated to the accellerator keys which are explicitely assigned (and who will be printed after the menu).
I can't say under which circumstances these hotkeys are generated - they seem to appear after kscpm has been running for a while. Our experienced KDE folks may be able to help enlighten us, thus adding Dirk Mueller to Cc:
Still fixing the problem is not all to hard. See attached patch as a possible solution.
Dirk, could you please look at comment #8? You may have an idea why the hotkeys (shown as an underscored character in the menue and reresented by an 'ampersanded' character in the corresponding QString) appear after this tray application has been running for a while. Dirk, could you help us with comment 8? Just as an additional information: If for whatever reason the profile name isn't found in the list the function passes an empty string to the profile switcher. This will most likely trigger an error. It would be better to check for this case before composing the command and create an error dialog. I wasn't able to think of any situation where this may happen so I didn't want to go thru the trouble and just added the test and the empty string fallback to keep the app from crashing in this unlikely event. The patch from Egbert looks correct. I've not looked at kscpm source, but it seems it uses KAccelGen (probably indirectly via one of the standard KDE API toolkit classes), which automatically assigns keyboard shortcuts to actions that can be triggered by the user. This is an accessibility feature. I believe it is possible to disable this per widget, though I can currently not find it (and I'm in a hurry, will check later). The correct fix is to not rely on gui widgets text() to not change, which is what egbert's patch achieves. Submitted to stable. Ok, so let's close this bug then. Thanks Helmut. |