[18:53] <dandrader> bregma, ping
[19:04] <bregma> dandrader|afk, pong
[19:26] <dandrader> bregma, what do you think: https://bugs.launchpad.net/bugs/1080819
[19:27] <dandrader> grail would need something similar, to #ifdef its frame_x11_* calls
[19:28] <bregma> dandrader, the whole point of the frame library was indeed to hide the dirty details of X11, so it's legit
[19:28] <bregma> grail wasn;t supposed to know about X11, so something leaked
[19:28] <bregma> but the same bug could be used for grail, so the changes go in together
[19:28] <dandrader> yeah, it's bad to have fraem_x11_* calls in grail indeed
[19:29] <dandrader> what it uses is frame_x11_accept_touch and frame_x11_reject_touch
[19:30] <bregma> there's also som e X11 calls in geis in the grail back end
[19:30] <dandrader> I think the idea of having it in the x11 namespace instead of in the regular frame_ api was that not all platforms would have the accept/reject concept for touches
[19:31] <dandrader> so in that sense grail would have to know if the frame objects it receives are using the x11 backend or not. which is weird because then it's not really a backend anymore as it's also being exposed on the front side
[19:32] <bregma> there's also a bit of X11 dependency leaking through geis, in that the windowid gets used as a filter, but then again toolkits use that information
[19:37] <bregma> geis uses X11 directly for (1) detecting input devices (2) pumping the frame event loop, and (3) dark xsync magic
[19:38] <bregma> perhaps there is a way to tease those functions out into a separate chunk of code so that geis is also no dependent on X11?
[19:39] <dandrader> so I think the best way would be for the platform-specific calls to be available only on their corresponding platforms. like Qt does. I has a couple of mac  windows and linux specific functions that only existing when Qt is built in those platforms. and then code that make use of those platform-specific functions would have to surround them with #ifdefs
[19:41] <bregma> problem with that is you can;t have the library built both ways on the same platform (which may not be a problem in the long run but may be difficult suring the transition)
[19:41] <bregma> s/suring/during/
[19:43] <dandrader> bregma,  what do you mean by "both ways"?
[19:44] <bregma> well, if we wanted to have, for example, X11 support and some other non-X11 support in the same OS
[19:44] <bregma> you could build the libraries twice and use different SONAMEs and -D options for each build
[19:46] <dandrader> in frame, for instance, we currently have 2 backends:  x11 and platform-independent
[19:46] <dandrader> the platform-independent backend is always built
[19:47] <dandrader> and the platform specific ones would be mutually exclusive
[19:47] <dandrader> well, actually they don't need to be mutually exclusive, just optional/configurable
[19:48] <dandrader> e.g. if you don't have foo libs or passed --disable-foo, don't build foo backend
[19:49] <dandrader> but for the sake of simplicity it might be better to make them mutually exclusive
[20:46] <TheMuso> Hey folks. I've made some progress on the python3 port, but when attempting to run pygeis, I am getting a traceback with relation to the callback wrappers in python and ctypes, and I am not sure what the problem is, as my experience with ctypes limited. https://code.launchpad.net/~themuso/geis/python3
[20:46] <TheMuso> That branch is what I have done so far.
[21:14] <bregma> TheMuso, I'll try to take a look in a few hours, but my ctypes is a little rusty
[21:15] <TheMuso> bregma: Thanks.
[22:56] <MuNk`> general ubuntu UI it just to small, thought Ubuntu had its own Touch U by now?