----- Carlos R. Mafra <[email protected]> a écrit : > On Sun, 16 Jun 2013 at 17:56:15 +0200, Christophe wrote: > > > > ----- Carlos R. Mafra <[email protected]> a écrit : > > > On Sat, 15 Jun 2013 at 14:38:42 +0200, Christophe wrote: > > > > From: Christophe CURIS <[email protected]> > > > > > > > > The 3 patches propose a fix for little problem arising with certain X > > > > servers > > > > which do not handle the Xkb extension. > > > > > > Which X servers are these? > > > > In the present case, that's 'vncserver', the free edition from RealVNC. > > I use it (amongst other things) because it is handy to give a try to a dev > > wmaker version without breaking current environment. There are other > > options, but that's the one I'm used to... > > > > I was actually trying to see if I could reproduce Juan's crash, but could > > not: Alt-Tab is going to the main wmaker, it is not captured by VNC... So I > > tried (without believing it) to see if I could change the shortcut, and > > faced the WPrefs crash. > > > > I would also point that it is likely that smallX/tinyX/Kdrive have the same > > no-Xkb situation as they are used in low memory environment, although I did > > not try. > > Ok, but reintroducing the deprecated functions just doesn't seem right, > and the new warnings we get as a result are an indication of that. > > Would it be possible to make this branching at compile time?
Unfortunately, no, that's not possible. Xkb is done at server side, the library functions handling just the discussion with the server, as for most X functions. So you cannot know at compile time if the server you'll connect to will support it or not... Typically in my case it would have compiled with Xkb support as I have it, but XkbKeycodeToKeysym always returned 0 because vncserver did not have the Xkb extension on its side... > Instead of using > > + if (xext_xkb_supported) > + ksym = XkbKeycodeToKeysym(dpy, > ev.xkey.keycode, 0, 0); > + else > + ksym = XKeycodeToKeysym(dpy, ev.xkey.keycode, > 0); > > one could do call a new function unconditionally > > wm_keycode_to_keysym(dpy, ev.xkey.keycode); > > and that function would have > > #ifdef XKB > ksym = XkbKeycodeToKeysym(dpy, ev.xkey.keycode, 0, 0); > #else > ksym = XKeycodeToKeysym(dpy, ev.xkey.keycode, 0); > > or something along these lines. > > Then someone who's using the standard X servers which support xkb by default > would not see the warnings, and only people wanting to do non-standard things > would see them. Actually the problem is on X.org side only. They decided to mark the function XKeycodeToKeysym as deprecated, which is not true. The function is still valid and will "always" be (it's part of the legacy standard), the attribute being set only to invite programmers to switch to Xkb (which is *only* an extension) because of modern locale constraints. A choice that cannot be condemned, but... -- To unsubscribe, send mail to [email protected].
