Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?



On Tue, Jun 26, 2012 at 11:56 PM, Mark Vender <markv743 yahoo co uk> wrote:
> On 06/26/2012 07:57 PM, Matthias Clasen wrote:
>>
>> On Tue, Jun 26, 2012 at 11:10 AM, Mark Vender <markv743 yahoo co uk>
>> wrote:
>>
>>
>>> It's impossible for an application to break when enum values are added.
>>> They
>>> end up as integers within the code anyway and unless their values change,
>>> API/ABI stays the same.
>>
>>
>> I could think of some ways. But anyway, the keysyms are defines
>> because that's how they were done initially, and there's no compelling
>> reason to change it.
>>
>
> Well, using enums would make wrapping keysyms much easier on the gtkmm side.

It will also help other bindings to stop doing things such as this:

http://git.gnome.org/browse/pygobject/tree/gi/overrides/keysyms.py

> Currently the only possible solution is to parse gdkkeysyms.h using  a
> script similar to gdkkeysyms-update.pl.
>
> What I don't understand is why a patch must necessarily demonstrate a
> big improvement. I'm suggesting only to change

In my opinion it would be quite a big improvement.

Regards,

Tomeu

> #define GDK_KEY_***
> <...>
>
> to
>
> typedef enum {
>     GDK_KEY_*** = ***,
>     <...>
> } GdkKeySym;
>
> which has no chance of negative effects. Even if we add values, they are
> still stored in an int, that is, GdkKeySym is never used. Thus, in my
> opinion, even a small improvement is worthwhile.
>
> Cheers,
> Mark
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]