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.)
> (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.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
