=== dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === scottb` is now known as scottb === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader [18:53] bregma, ping === dandrader is now known as dandrader|afk [19:04] dandrader|afk, pong === dandrader|afk is now known as dandrader [19:26] bregma, what do you think: https://bugs.launchpad.net/bugs/1080819 [19:26] Ubuntu bug 1080819 in frame "It should be possible to build frame without x11" [High,In progress] [19:27] grail would need something similar, to #ifdef its frame_x11_* calls [19:28] dandrader, the whole point of the frame library was indeed to hide the dirty details of X11, so it's legit [19:28] grail wasn;t supposed to know about X11, so something leaked [19:28] but the same bug could be used for grail, so the changes go in together [19:28] yeah, it's bad to have fraem_x11_* calls in grail indeed [19:29] what it uses is frame_x11_accept_touch and frame_x11_reject_touch [19:30] there's also som e X11 calls in geis in the grail back end [19:30] 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] 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] 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] geis uses X11 directly for (1) detecting input devices (2) pumping the frame event loop, and (3) dark xsync magic [19:38] 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] 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] 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] s/suring/during/ [19:43] bregma, what do you mean by "both ways"? [19:44] well, if we wanted to have, for example, X11 support and some other non-X11 support in the same OS [19:44] you could build the libraries twice and use different SONAMEs and -D options for each build [19:46] in frame, for instance, we currently have 2 backends: x11 and platform-independent [19:46] the platform-independent backend is always built [19:47] and the platform specific ones would be mutually exclusive [19:47] well, actually they don't need to be mutually exclusive, just optional/configurable [19:48] e.g. if you don't have foo libs or passed --disable-foo, don't build foo backend [19:49] but for the sake of simplicity it might be better to make them mutually exclusive [20:46] 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] That branch is what I have done so far. [21:14] TheMuso, I'll try to take a look in a few hours, but my ctypes is a little rusty [21:15] bregma: Thanks. [22:56] general ubuntu UI it just to small, thought Ubuntu had its own Touch U by now?