newbie =?utf-8?B?77+9?=resource temporarily unavailable � qu esti on
Glynn Clements
glynn at gclements.plus.com
Sat Jun 30 06:31:02 PDT 2012
Alan Corey wrote:
> Well, you see, I just really dislike C++. I've tried on and off for
> years and I just can't get it through my head. I want a toolkit I can
> program in C. FLTK seems great, same with GTK, but not without C++.
> I'm familiar with OO programming concepts from Java, Delphi and Perl
> but C++? Uh-uh.
I would have thought that GTK would fit the bill.
> > I wouldn't advise putting too much effort into Xt/Xaw stuff; they've
> > fallen so far into disuse that if X.org shipped a totally
> > non-functional version of one of those libraries, it might take a year
> > before anyone actually noticed.
>
> Wouldn't that break a bunch of things that rely on them?
Such as? The typical Linux desktop environment doesn't have any
Xt-based applications; Gnome uses GTK and KDE uses Qt.
Okay, Xt isn't quite dead yet (e.g. XEmacs (which I'm using at this
moment) requires it), but it's quite definitely "legacy" at this
point.
> > And Xlib itself is slowly heading the same way; XRender and OpenGL are
> > frequently preferred for the graphics side.
>
> Yeah, I should probably learn OpenGL, but I'm more interested in
> scientific plotting type graphics than artsy 3D stuff. I don't do
> games at all. I just want control of my pixels.
OpenGL isn't just for 3D. Also, XRender (normally used via cairo) is
quite similiar but limited to 2D.
One of the main problems with the core Xlib graphics functionality is
the lack of support for resolution-independence (most programs which
try to do graphics using pixel coordinates result in many features
being far too small when run on a 1920x1440 monitor).
> > OTOH, a basic understanding of the principles underlying X is never a
> > bad thing to have.
>
> I guess I don't have a clear idea of what's built on what. I know
> Athena's just a "suggested" toolkit, but I thought Xt was built into
> X. I'm not doing much of anything with Motif, open or otherwise. The
> main thing I dislike about the older stuff is scrollbars like in XTerm
> where you have to right click to go up in tiny steps.
Xt was part of the original monolithic X distribution, but that no
longer exists. If you don't like the original Athena, Xaw3D has a more
Motif-y look and "normal" scrollbars, but it still lacks keyboard
traversal.
> > This is particularly applicable to "resource temporarily unavailable",
> > which is the message for the EAGAIN code. This often just means that a
> > non-blocking operation (such as read() or write() on a non-blocking
> > descriptor) cannot produce any data available right now (read() cannot
> > return 0 in this situation because that indicates EOF).
>
> But it could set errno.
If read() on a non-blocking socket finds no data available, it will
return -1 and set errno to either EAGAIN or EWOULDBLOCK. Unless
something explicitly clears errno, it will stay set until it gets set
to something else or explicitly cleared by a library function (system
calls and C library functions never clear errno).
> > As for your black rectangle, you'll need to look elsewhere. Are you
> > copying the correct plane? Are the foreground and background colours
> > of the GC set correctly? If you used an XColor to determine the
> > numeric value for the colours, don't forget that XColour uses 16-bit
> > values (0..65535) for the components; if you use 8-bit values
> > (0..255), you can have any colour you like so long as it's black.
>
> I'll look into these things. I'm running 24 bit color, and editres
> shows the depth of my widgets is 24. I haven't found a good
> discussion of GCs yet but I'll look for one. For example programs I'm
> using XLoad and the XBitmap programs from the O'Reilly book. I was
> mostly using anything to satisfy compiler warnings for GCs, but it
> makes sense that they could have an effect like this. And no, I don't
> know that I'm copying the right plane. I was using XCopyArea until I
> changed it to plane at the last minute because the depth wasn't 1.
XCopyArea is used when you have a pixmap with the same depth as the
screen and you want a direct copy. XCopyPlane is mostly used when you
have a 1-bpp bitmap; selecting a single plane from a multi-bpp pixmap
is valid but less common.
A GC is just a collection of drawing parameters (colours, line style,
font, etc), so that you don't have to pass a dozen parameters to each
drawing function, and as an optimisation (it's typically faster to
create a separate GC for each "style" and select the correct one
foreach drawing operation than to create a single GC and continually
change its state).
--
Glynn Clements <glynn at gclements.plus.com>
More information about the xorg
mailing list