Qt Designer Does Not Support QKeySequence::StandardKey
-
As far as I can tell you can't do it unless you set it from your code. I hope I'm wrong. As if you want to move your app from platform to platform it sucks.
As the documentation says.
bq. As a result, both human-readable strings and hard-coded key codes can both be problematic to use when specifying a key sequence that can be used on a variety of different keyboard layouts. Only the use of standard shortcuts guarantees that the user will be able to use the shortcuts that the developer intended.
bq. It is preferable to use standard shortcuts where possible. When creating key sequences for non-standard shortcuts, you should use human-readable strings in preference to hard-coded integer values.
I think that this needs to be fixed. It makes perfect sense to me why you want native shortcuts.
-
I am not sure I understand the problem?
-
@Andre: that unfortunately the Action editor doesn't allow you to specify a QKeySequence::StandardKey, but only to type in your shortcut (like inputting "Ctrl+A", which is not truly cross platform).
-
Ah, ok, I get it. There is indeed room for improvement there, I guess. Please "file":http://bugreports.qt.nokia.com a wish against QtCreator. I found that the Creator team is quite receptive to (reasonable) suggestions.
-
Will do.
-
Thanks for the bug tracking system. For some reason I could not find it. (even though looking back I could have just googled it). Anyway, it seems that this has been addressed and declared Wontfix. But, I noticed that they said they didn't like the proposed idea. Mabey if there was a better solution proposed...
I was thinking that because Qt Designer uses strings to construct it's key sequences, there could be s special syntax for setting standardKeys. It appears this method lacks support for standard keys. Maybe for example if the string starts with a semicolon (or two) unless escaped some way. Then it would be useable to the string constructor/cast and therefor Qt Designer.
But, now that I think about it, how would you cast from a standard key to a string? I guess you could give the primary one as a string.
-
IMHO it just should provide a combobox with the standardkeys, or allow you to specify a custom shortcut. That's it.
-
I agree, it would be best to have a combobox or something like that to select a standard key.
@youarefunny: do you have a link to the issue?
-
http://bugreports.qt.nokia.com/browse/QTBUG-1278
There is also a link to another bug there. But there they have a getter and i think that is the problem. I think if it could be a string it could be run-time.
-
I think either the StandardKey getter patch should be accepted, or there should be a patch written for the string format interpretter to accept & return standard keys. I don't quite see why it is conceptually wrong to have a getter for a StandardKey in QKeySequence though.
-
Apart from that, there's no need of such a getter in order to implement the feature inside Designer (and thus uic). Just save in the .ui, along the action data, the fact that it uses a StandardKey.
-
The reason I see is that UI forms can be loaded run time. This means that if you want to want to use a standard key it will have to be a string anyway. Otherwise you would have a Designer only method to accomplish the same thing.
To me I think they are right in saying that it would be bad to have a different interface. I believe they try to keep the .ui files as close to the code as possible. As you see it is just declaring the classes specified and calling the proper functions with the strings, integers or boolean values given in the XML node and attribute values. I think that that is truly beautiful and to be preserved.
-
So what? How is saving
@<action id="foo" shortcutType="standardKey" key="Undo">@
inside the .ui problematic at all? (Except that it may break with old uics, but who cares?) -
The thing is how to translate into a ui_*.h file. I mean it isn't really a big deal at all but it isn't direct. I personaly love it but I am just trying to be critical so that we get the best answer for the devs (and one that they hopefully won't shoot down).
I think that this should be attached as to a bug report as a proposed fix.