[Xcb] Porting the rest of the X.Org apps to xcb
At least at a quick glance, I think these could be fairly straightforward to port to XCB, though whether it's worth the effort for all of them is debatable: backlight, ico, xcmsdb, xcompmgr, xdriinfo, xhost, xinit, xkill, I took a stab at porting xhost to xcb, but it looks like some host family definitions are only available in Xau. With Krb5 currently disabled, there are no protocol requests to depend on; however, there are host family definitions such as FamilyLocalHost and FamilyNetname that are only defined in Xauth.h. Should these be included in xcb_family_t? I also couldn't see any defition of server interpreted address structure in xcb. Cheers, Lev ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
In message 4c406a89.7080...@oracle.com you wrote: Given what I learned on the xwininfo port I took a quick pass across the rest of the X.Org app/* modules to see what it would take to port each to xcb. Thanks huge. That looks like it was a lot of work. These depend on libXft, and I'm not sure what to do about that in a xcb port: x11perf (plus like rendercheck, we'd still want to be able to use it to test libX11 for a while) I've got a very partial port of x11perf going. It was what inspired me to write the xcb_image library. If someone wanted to finish it, that would be awesome; I'll dig up the code. Otherwise I'll get there eventually. I think we'll need to do some kind of libXft replacement; maybe I'll work on that. These depend on libXt and/or libXaw, which use Xlib types like Display in their API, so a pure-xcb-port is not possible without first porting to another toolkit (which doesn't seem worth the effort for most of these, since there already are similar programs for other toolkits, or doesn't make sense since they're specifically for Xt resource management): beforelight, bitmap, oclock, proxymngr, smproxy, twm xbiff, xcalc, xclipboard, xclock, xconsole, xditview, xdm, xedit, xeyes, xfd, xfindproxy, xfontsel, xgc, xload, xlogo, xmag, xman, xmessage, xmh, xmore, xsm, xvidtune I'd really like to see a lot of these ported, but many of them are going to require *some* toolkit. I wish someone would do XCB-Gnome again and get it into mainline. :-) Failing that, maybe I need to (get a student to) do a C version of my Blackboard GUI. Sigh. Don't know when I'll find time... lbxproxy - calls xtrans directly since it's a X11 proxy, plus, it's LBX, so it's just special anyway. (Also, since Xorg no longer supports LBX, not widely used anymore.) Why do we even still ship this? Just kill it. xpr - only uses XInitImage from libX11 I don't even know what this is. I don't seem to have one on any of my computers... xscope - uses xtrans directly to proxy X protocol, printing it on the way for debugging - though it would be nice if extension decoders could be xcb-generated instead of handcoded This work has been done for wireshark / tshark, and maybe for xscope---I forget. Bart ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
Vincent Torri wrote: On Fri, 16 Jul 2010, Alan Coopersmith wrote: At least at a quick glance, I think these could be fairly straightforward to port to XCB, though whether it's worth the effort for all of them is debatable: backlight, ico, xcmsdb, xcompmgr, xdriinfo, xhost, xinit, xkill, xrandr, xrdb, xrefresh, xrestop, xsetroot, xshowdamage, xstdcmp, xvinfo, xwd, xwud Arnaud Fontaine wrote an XCB-based composite manager. Is it necessary to port xcompmgr ? It's not necessary to port any of these, and certainly ones for which there's already a good xcb replacement are not that useful. I suppose I left out my thinking about why it's useful to port the X.Org apps to xcb. Clearly the mainstream distros are going to have to ship libX11 until approximately the end of time_t - there's just too many thousands of existing applications out there from the last 25 years. I could see embedded or minimized systems being able to get by without libX11 in the not-too-distant future, once we get all the software they need to use ported (and I'd think they're more likely to use modern/maintained software from GNOME, KDE, etc. than our ancient Xaw sample apps for their core desktop software) - from the above list the top priority for that would probably be xinit. But every app we port ourselves gives us more insight into what is needed to port apps, and figure out how to make it easier for authors/maintainers of the much more complicated apps out there in the rest of the world. From the xwininfo port, at least I learned that a set of functions to convert properties between the various encoding types (STRING/iso8859-1, COMPOUND_TEXT/iso2022, UTF8_STRING) would be very useful to save replicating that in every program. I imagine porting xrdb would give some similar insight into what's needed for all the Xlib helper functions around resource management. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
On Fri, Jul 16, 2010 at 05:32:32PM +0300, Tiago Vignatti wrote: On Fri, Jul 16, 2010 at 04:24:04PM +0200, ext Vincent Torri wrote: On Fri, 16 Jul 2010, Alan Coopersmith wrote: Given what I learned on the xwininfo port I took a quick pass across the rest of the X.Org app/* modules to see what it would take to port each to xcb. I am *not* volunteering to do these all, just offering some insight into which are going to be easier/harder/not possible and hoping that others will step up to do some of these. At least at a quick glance, I think these could be fairly straightforward to port to XCB, though whether it's worth the effort for all of them is debatable: backlight, ico, xcmsdb, xcompmgr, xdriinfo, xhost, xinit, xkill, xrandr, xrdb, xrefresh, xrestop, xsetroot, xshowdamage, xstdcmp, xvinfo, xwd, xwud Arnaud Fontaine wrote an XCB-based composite manager. Is it necessary to port xcompmgr ? xcompmgr is a nice example of a tiny compositor manager. My quickly at Arnaud's tells that it isn't that much. Mm, there's a lot in xcompmgr that makes it a great example of how not to design a compositing manager. Unless you don't care in the least about efficiency or aesthetics (which is sort of the point of a compmgr). Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
Date: Fri, 16 Jul 2010 07:39:16 -0700 From: Alan Coopersmith alan.coopersm...@oracle.com I suppose I left out my thinking about why it's useful to port the X.Org apps to xcb. Clearly the mainstream distros are going to have to ship libX11 until approximately the end of time_t - there's just too many thousands of existing applications out there from the last 25 years. I could see embedded or minimized systems being able to get by without libX11 in the not-too-distant future, once we get all the software they need to use ported (and I'd think they're more likely to use modern/maintained software from GNOME, KDE, etc. than our ancient Xaw sample apps for their core desktop software) - from the above list the top priority for that would probably be xinit. Heh, that's reassuring. But every app we port ourselves gives us more insight into what is needed to port apps, and figure out how to make it easier for authors/maintainers of the much more complicated apps out there in the rest of the world. From the xwininfo port, at least I learned that a set of functions to convert properties between the various encoding types (STRING/iso8859-1, COMPOUND_TEXT/iso2022, UTF8_STRING) would be very useful to save replicating that in every program. I imagine porting xrdb would give some similar insight into what's needed for all the Xlib helper functions around resource management. On the other hand, it is also beneficial to leave some of the core applications use libX11 to make sure it doesn't suffer too much bitrot. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
Hello, On Fri, 16 Jul 2010 07:39:16 -0700, Alan Coopersmith alan.coopersm...@oracle.com wrote: But every app we port ourselves gives us more insight into what is needed to port apps, and figure out how to make it easier for authors/maintainers of the much more complicated apps out there in the rest of the world. Most of the much more complicated apps use X through some kind of UI toolkit framework. So I would guess that porting one of those frameworks is what's most needed to port apps. Keeping in mind that things like GTK, Qt and the likes are intended to *hide* the underlying windowing system, most out there applications do not actually use Xlib directly at all. And then there's the impossible case of GLX :-( Just for the self-centric purely informative reference, the remaining Xlib stumbling blocks in (Lib)VLC are: - GLX, - libSDL, - ASCII Art (don't ask me why libaa needs libX11 ?!), - PulseAudio (libpulse), - Qt4, - VLC's own skin engine, of which only the last item is up to VLC developers to address. -- Rémi Denis-Courmont http://www.remlab.net http://fi.linkedin.com/in/remidenis ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
On Fri, Jul 16 2010, Owain Ainsworth wrote: There is a port of libXft to xcb. I have been meaning to try and get it commited to git for a while now (It is not my work). The only link I can find is: http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/libXft/ Last I looked (a while ago) it looked pretty straightforward. 79 #if defined (USE_XCB) 80 XftFontOpen (xcb_connection_t *dpy, int screen, ...) 81 #else 82 XftFontOpen (Display *dpy, int screen, ...) 83 #endif That's never going to be accepted. OTOH, adapting the code to use XGetXCBConnection might be quite easy. -- Julien Danjou // ᐰ jul...@danjou.info http://julien.danjou.info pgpcQM9ATeDa1.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
Rémi Denis-Courmont wrote: Most of the much more complicated apps use X through some kind of UI toolkit framework. So I would guess that porting one of those frameworks is what's most needed to port apps. Absolutely - one of the clear lessons I learned with the xwininfo port was that our traditional advice to write apps to a toolkit instead of raw Xlib should be much stronger with XCB. Keeping in mind that things like GTK, Qt and the likes are intended to *hide* the underlying windowing system, most out there applications do not actually use Xlib directly at all. Unfortunately, a lot of the toolkits exposed Xlib API so that apps could do things that the toolkits didn't directly support, like setting EMWH properties before the toolkits got there or calling new/uncommon X extensions. I actually wonder how many apps have absolutely no calls to any functions from libX11 or the libX11-based extension libraries. For instance, just as a quick example, nm shows these Xlib calls in gnome-terminal which otherwise uses the gtk toolkit: [931] | 134629136| 0|FUNC |GLOB |0|UNDEF |XChangeProperty [1177] | 134629104| 0|FUNC |GLOB |0|UNDEF |XCreateWindow [1123] | 134629168| 0|FUNC |GLOB |0|UNDEF |XDestroyWindow [1340] | 134637552| 0|FUNC |GLOB |0|UNDEF |XFlush [1130] | 134637392| 0|FUNC |GLOB |0|UNDEF |XFree [871] | 134637472| 0|FUNC |GLOB |0|UNDEF |XGetSelectionOwner [1059] | 134637376| 0|FUNC |GLOB |0|UNDEF |XGetWindowProperty [895] | 134637456| 0|FUNC |GLOB |0|UNDEF |XGrabServer [776] | 134629120| 0|FUNC |GLOB |0|UNDEF |XInternAtom [1517] | 134637520| 0|FUNC |GLOB |0|UNDEF |XSendEvent -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
On Fri, 16 Jul 2010 15:58:21 +0100, Daniel Stone dan...@fooishbar.org wrote: Mm, there's a lot in xcompmgr that makes it a great example of how not to design a compositing manager. Unless you don't care in the least about efficiency or aesthetics (which is sort of the point of a compmgr). xcompmgr was written purely as a way of testing the Composite extension, it was never 'designed'. A nice, simple, xcb-based demo compositing manager would be a useful replacement (something that just does compositing, without any special effects). I found the hardest part to be tracking the X stacking order without ever calling XQueryTree. -- keith.pack...@intel.com pgpjZs0D5vvJ6.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
On Fri, Jul 16, 2010 at 05:13:34PM +0200, Mark Kettenis wrote: Date: Fri, 16 Jul 2010 07:39:16 -0700 From: Alan Coopersmith alan.coopersm...@oracle.com I suppose I left out my thinking about why it's useful to port the X.Org apps to xcb. Clearly the mainstream distros are going to have to ship libX11 until approximately the end of time_t - there's just too many thousands of existing applications out there from the last 25 years. I could see embedded or minimized systems being able to get by without libX11 in the not-too-distant future, once we get all the software they need to use ported (and I'd think they're more likely to use modern/maintained software from GNOME, KDE, etc. than our ancient Xaw sample apps for their core desktop software) - from the above list the top priority for that would probably be xinit. Heh, that's reassuring. But every app we port ourselves gives us more insight into what is needed to port apps, and figure out how to make it easier for authors/maintainers of the much more complicated apps out there in the rest of the world. From the xwininfo port, at least I learned that a set of functions to convert properties between the various encoding types (STRING/iso8859-1, COMPOUND_TEXT/iso2022, UTF8_STRING) would be very useful to save replicating that in every program. I imagine porting xrdb would give some similar insight into what's needed for all the Xlib helper functions around resource management. On the other hand, it is also beneficial to leave some of the core applications use libX11 to make sure it doesn't suffer too much bitrot. On the contrary, the more we port away from libX11, the more we don't bother making new changes in it or making new libraries support it, and the closer we get to a model in which only people who have ancient programs that still use libX11 bother maintaining it. :) - Josh Triplett ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
Mark Kettenis wrote: From: Alan Coopersmith alan.coopersm...@oracle.com But every app we port ourselves gives us more insight into what is needed to port apps, and figure out how to make it easier for authors/maintainers of the much more complicated apps out there in the rest of the world. I also should have mentioned that each app ported is another test case for xcb to help us find/fix bugs, and another bit of sample code for others to reference. On the other hand, it is also beneficial to leave some of the core applications use libX11 to make sure it doesn't suffer too much bitrot. Well, as noted in my original list, I see a lot that just don't make sense to port or aren't worth the effort, like most of the libXaw programs, so I'm sure there will be plenty around for a while. So far the ones we've ported (x*info / xls* type apps) are atypical clients, not really serving as good examples/tests of what a normal app does (none of them even open a window for starters). And the specific test suite apps (rendercheck, x11perf, XTS) it makes sense to explicitly keep libX11 code around, even if we make it a build time configuration, so that we can continue to use it to test libX11. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Xcb] Porting the rest of the X.Org apps to xcb
Barton C Massey wrote: In message 4c406a89.7080...@oracle.com you wrote: lbxproxy - calls xtrans directly since it's a X11 proxy, plus, it's LBX, so it's just special anyway. (Also, since Xorg no longer supports LBX, not widely used anymore.) Why do we even still ship this? Just kill it. It's not part of the current katamari, and mostly abandoned, but we don't delete the old modules from git or remove the tarballs from the download site. (We still ship it in Solaris since I've never gotten around to doing the deprecation/removal process, and you could be connecting to an older system that stil supports it.) xpr - only uses XInitImage from libX11 I don't even know what this is. I don't seem to have one on any of my computers... Prints xwd window dumps (well, converts them to postscript/pcl/etc.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
