On Nov 22, 2010, at 1:16 PM, Alan Coopersmith wrote: > Richard L. Hamilton wrote: >> I think libXt uses select(); > > Yes. > >> one could imagine an alternate implementation >> that used event ports and a high-resolution timer. It might take >> a lot of testing to get right though, and high resolution timers require >> the user to have an additional fine-grained privilege. And since we're >> all supposed to turn our noses up at libXt, mutter "legacy", and move on >> to using GTK instead, I doubt anyone will bother trying to give >> XtAppAddTimeOut finer grained resolution without the need for >> a systemwide change. > > Anyone who wants to work on enhancing libXt is free to do so and propose > improvements to X.Org. No one has cared enough to do so in many years. > (I've just applied upstream a number of patches to fix things like missing > NULL pointer checks, which are among the few bug fixes we've gotten for > libXt since the X.Org Foundation took over maintenance in 2003.)
That's appreciated! And I know you're just telling how it is. Better to hear it straight than not, but doesn't mean I'm going to like what I hear. :-/ (I think it's time to nag the guy that filed the petition to open source CDE, to find out if he's heard anything more in the last year or two...) >> (In case you hadn't noticed, I haven't yet gotten over the move to GNOME, >> which I think was a loser. If one had to move to some non-Xt toolkit, >> I'd have preferred Qt (KDE). Not that I've _written_ anything using either, >> but KDE apps always seem to me to look prettier and respond just a bit >> faster.) > > At the time the choice was made, there were many reasons GNOME & Gtk were a > better fit for Sun & Solaris than KDE & Qt - many of those have since been > solved (like the Qt license issues), but one huge obstacle remains: Qt is > a C++ API, and the multitude of C++ ABI issues on Solaris really make that > unsuitable for use in system libraries. On Linux, where there's only one > C++ compiler that matters, and you just recompile the world when it's ABI > changes, life is simpler - but Solaris users who want binary compatibility > to be measured in decades, a choice of Studio or GNU C++ compilers, and > support for the various versions of ISO/ANSI C++ standards, really have a > hard time. I think the C++ problem (the general case) could be solved if the will were there. From what I've heard, the GNU implementation is more flexible/more fully covers some cases (maybe at a slight performance cost or something). If (outside of language updates) they could stabilize on it, I would think that Studio could move to that approach for new code (keeping some level of old ABI support for awhile for compatibility). http://forums.oracle.com/forums/thread.jspa?threadID=1996354&tstart=90&messageID=8451795#8451795 said that Studio 13 was expected to include g++ ABI compatibility, although that was early 2009, presumably before it took just slightly less than a deity (I wonder if some at that level remember the "slightly less" part, or all the cautionary tales about hubris) to approve comments about future products. But for now, I suppose we're stuck with GNOME. The RAM vendors must be making a killing... _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
