changes in keycodes between 2.6 and 2.8

Franz Steinhaeusler wrote:

Hello NG,

my DrPython keyboard shortcuts are not working anymore.

There are changes between 2.6 and 2.8 in numerous keycodes.
For example left cursor it was 316 and now it is 314.

Don't use the numbers. Use the wx.WXK_* constants that already exist.

I know, this is not good, but I expected no change.
The numbers are stored externally in a preferences file.

Is there a table anywhere to see, what keycodes have changed?

WXK_NEXT and WXK_PRIOR were made equivalent to WXK_PAGEDOWN and
WXK_PAGEUP, so everything after that spot in the enum had their values
changed.

Thank you for your information!

···

On Thu, 28 Dec 2006 11:51:42 -0800, Robin Dunn <robin@alldunn.com> wrote:

--

Franz Steinhaeusler

I'm guessing that you use the numbers because it's awkward to convert
to and from a string representation for saving in/loading from your
config file.

Converting the wx enums into some kind of Enumeration object might
really help. I'm using a wrapper for a C++ library that provides this
and it's really convenient.

Here's a sample of what the class could look like, based in part on
what this other wrapper provides:

class KeyCodes(object):
    _values = {
        "WXK_PAGEUP":100,
        "WXK_PAGEDOWN":100

    }
    def __init__(self, name):
        assert (name in KeyCodes._values)
        self.value = name

    def __str__(self):
        return self.value

    __repr__ = __str__

    def __int__(self):
        return KeyCodes._values[self.value]

    def __hash__(self):
        return KeyCodes._values[self.value]

    def __cmp__(self, other):
        try:
            return cmp(int(self), int(other))
        except ValueError:
            return cmp(str(self), str(other))

    @staticmethod
    def load(name):
        #Returns a KeyCodes object based on the
        #symbolic name provided, for loading
        #from a string.
        if name in KeyCodes._values:
            return getattr(KeyCodes, name)
        else:
            raise KeyError, "Not a KeyCode"

#these values and the dictionary auto-generated by swig
for value, key in KeyCodes._values.iteritems():
    setattr(KeyCodes, value, KeyCodes(value))

#testing
assert(100 == KeyCodes.WXK_PAGEUP)
assert(KeyCodes.WXK_PAGEUP == 100)

assert(101 != KeyCodes.WXK_PAGEUP)
assert(KeyCodes.WXK_PAGEUP != 101)

assert(KeyCodes.WXK_PAGEUP == KeyCodes.WXK_PAGEUP)

assert(KeyCodes.WXK_PAGEUP == "WXK_PAGEUP")
assert("WXK_PAGEUP" == KeyCodes.WXK_PAGEUP)

assert("WXK_PAGEDOWN" != KeyCodes.WXK_PAGEUP)
assert(KeyCodes.WXK_PAGEUP != "WXK_PAGEDOWN")

assert(KeyCodes.WXK_PAGEUP is KeyCodes.load("WXK_PAGEUP"))

One way that this is different than the wrapper I'm using is that it's
the string value (the symbolic name) that is stored in each instance,
rather than the numeric value. This means that, for example, you can
pickle these instances and they will have the correct numeric value
when loaded, even if wx changes underneath them. The current wx.WXK_
constants could be (I think?) transparently replaced with the class
members.

The only thing this needs is a way for SWIG to iterate over members of
an enum. I'm looking at the docs now to see if it's possible.

···

On 12/29/06, Franz Steinhaeusler <franz.steinhaeusler@gmx.at> wrote:

On Thu, 28 Dec 2006 11:51:42 -0800, Robin Dunn <robin@alldunn.com> wrote:

>Franz Steinhaeusler wrote:
>> Hello NG,
>>
>> my DrPython keyboard shortcuts are not working anymore.
>>
>> There are changes between 2.6 and 2.8 in numerous keycodes.
>> For example left cursor it was 316 and now it is 314.
>
>Don't use the numbers. Use the wx.WXK_* constants that already exist.
>

I know, this is not good, but I expected no change.
The numbers are stored externally in a preferences file.

>>
>> Is there a table anywhere to see, what keycodes have changed?
>
>WXK_NEXT and WXK_PRIOR were made equivalent to WXK_PAGEDOWN and
>WXK_PAGEUP, so everything after that spot in the enum had their values
>changed.

Thank you for your information!

Nitro wrote:

The only thing this needs is a way for SWIG to iterate over members of
an enum. I'm looking at the docs now to see if it's possible.

Since Robin is parsing the xml output of SWIG anyways (to generate the %rename s), one could probably add a bit to the xml parsing script which iterates over an enum and does some %pythoncode inserts or whatever.

Actually, I'm not doing that anymore. There is a new feature in SWIG that lets me get rid of that xml parsing step, and cuts a significant chunk of time off of the build.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

The Java generator for SWIG does something like what I'm suggesting
here, but I can't see how to do it for Python. There's an old post to
the SWIG ML that suggests using the XML output. I'll file it under "a
good idea someday".

···

On 12/29/06, Robin Dunn <robin@alldunn.com> wrote:

Nitro wrote:
>
>> The only thing this needs is a way for SWIG to iterate over members of
>> an enum. I'm looking at the docs now to see if it's possible.
>
> Since Robin is parsing the xml output of SWIG anyways (to generate the
> %rename s), one could probably add a bit to the xml parsing script which
> iterates over an enum and does some %pythoncode inserts or whatever.

Actually, I'm not doing that anymore. There is a new feature in SWIG
that lets me get rid of that xml parsing step, and cuts a significant
chunk of time off of the build.

--

Are you using the %rename with regular expressions? I saw that it was added in SWIG's changelog, but even the SWIG guys couldn't tell me/didn't answer whether it works or not. Can you confirm it works? I have a SWIG project where I do a lot of renaming myself and my build times are going up extremely (the xml output is >250 MB now). This feature would really cut short on my build time, too.

-Matthias

···

Am 29.12.2006, 23:18 Uhr, schrieb Robin Dunn <robin@alldunn.com>:

Nitro wrote:

The only thing this needs is a way for SWIG to iterate over members of
an enum. I'm looking at the docs now to see if it's possible.

Since Robin is parsing the xml output of SWIG anyways (to generate the %rename s), one could probably add a bit to the xml parsing script which iterates over an enum and does some %pythoncode inserts or whatever.

Actually, I'm not doing that anymore. There is a new feature in SWIG that lets me get rid of that xml parsing step, and cuts a significant chunk of time off of the build.

Nitro wrote:

Nitro wrote:

The only thing this needs is a way for SWIG to iterate over members of
an enum. I'm looking at the docs now to see if it's possible.

Since Robin is parsing the xml output of SWIG anyways (to generate the %rename s), one could probably add a bit to the xml parsing script which iterates over an enum and does some %pythoncode inserts or whatever.

Actually, I'm not doing that anymore. There is a new feature in SWIG that lets me get rid of that xml parsing step, and cuts a significant chunk of time off of the build.

Are you using the %rename with regular expressions? I saw that it was added in SWIG's changelog, but even the SWIG guys couldn't tell me/didn't answer whether it works or not.

I think I had problems with the regex renamer too, but I think it may have been build problems with the 3rd party regex lib or something like that. What I used was the string encoder interface of %rename, and I added a custom encoder to swig's source code. In my .i file I have just this to run the encoder on every name:

%rename("%(wxpy)s") "";

And in SWIG's Source/Swig/misc.c I added the patch listed below. IIRC there is also an encoder that can run an external command (such as awk) to get the new names, but I figured that with a huge number of names like wxPython has that it would end up being slower than parsing the xml output...

Index: Source/Swig/misc.c

···

Am 29.12.2006, 23:18 Uhr, schrieb Robin Dunn <robin@alldunn.com>:

===================================================================
RCS file: /cvsroot/swig/SWIG/Source/Swig/misc.c,v
retrieving revision 1.57
diff -u -4 -r1.57 misc.c
--- Source/Swig/misc.c 6 Mar 2006 22:51:00 -0000 1.57
+++ Source/Swig/misc.c 5 Jul 2006 00:50:19 -0000
@@ -899,8 +899,26 @@
  }
  #endif

+
+/* -----------------------------------------------------------------------------
+ * Swig_string_wxpy()
+ *
+ * Drop a leading 'wx' for all wxNames, except for wxEVT*
+ * ----------------------------------------------------------------------------- */
+String *Swig_string_wxpy(String *s) {
+ String* ns = NewStringEmpty();
+ char* cptr = Char(s);
+ if (cptr[0] == 'w' && cptr[1] == 'x') {
+ if ( ! (cptr[2] == 'E' && cptr[3] == 'V' && cptr[4] == 'T')) {
+ ns = NewString(&cptr[2]);
+ }
+ }
+ return ns;
+}
+
  /* -----------------------------------------------------------------------------
   * Swig_init()
   *
   * Initialize the SWIG core
@@ -928,8 +946,11 @@
    DohEncoding("undercase", Swig_string_ucase);
    DohEncoding("firstuppercase", Swig_string_first_upper);
    DohEncoding("firstlowercase", Swig_string_first_lower);

+ /* wxPython's rename encoder */
+ DohEncoding("wxpy", Swig_string_wxpy);
+
    /* Initialize the swig keys */
    Swig_keys_init();

    /* Initialize typemaps */

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!