Qt Designer Does Not Support QKeySequence::StandardKey
-
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.
-
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.
-
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.
-
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.