Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
sys_indirect()sys_indirect()Posted Nov 22, 2007 10:28 UTC (Thu) by nix (subscriber, #2304)In reply to: sys_indirect() by drag Parent article: sys_indirect()
I wasn't aware there was any intent to have apps migrate en masse to XCB (does anyone know of anything other than Xlib that uses XCB yet?). What is more likely to be useful is to have *widget sets* migrate, as they already implement most of what Xlib does themselves, and don't need most of the rest except for the raw comms stuff which XCB provides. As far as I know the XCB-based Xlib is here to stay.
(Log in to post comments)
sys_indirect() Posted Nov 22, 2007 22:36 UTC (Thu) by njs (subscriber, #40338) [Link] GTK+ does use XCB in one or two obscure places, but most of it is still Xlib-based. The big advantage of Xlib-on-XCB is that it becomes possible to mix Xlib and XCB calls in the same program, talking on the same X connection -- so you can have a gradual transition. Aside from toolkits themselves, interesting programs often have *some* direct calls to Xlib in addition to all the ones that go through the toolkit, because toolkits don't expose everything. (And toolkits are explicitly architected to allow for this, e.g. there is a way to get an Xlib Display* out of a GdkDisplay*.) For some of those apps, being able to use a sane and more-async-able API might well be valuable, and in general it is probably smart to use XCB in new programs. I have no idea what the equivalent for "libc migration" would be. When would you want to use two different libcs from the same program? How would the compiler even know which version of fork() you were trying to call?
sys_indirect() Posted Nov 23, 2007 0:22 UTC (Fri) by nix (subscriber, #2304) [Link] I suspect that the only way to `migrate' libcs would be a big bang with interface back-compatibility (which is, of course, exactly how glibc upgrades work). Nothing else works because of the presence of critical global data structures whose format must be understood by everything that accesses them (I'm thinking mostly of malloc() and free() here, but the exception unwinder is another example, which is why libgcc_s.so exists at all as opposed to just libgcc.a).
|
|||||||||||