Xlib Docs and/or How do I tell my WM to hide borders and title bar...

[Sergei Mutovkin]

Thank you very much Carl,

well one of the people from the newsgroups recommended me to follow:

    att.override_redirect = 1;
    XChangeWindowAttributes(display, win, CWOverrideRedirect, &att);

technique to make window fullscreen. Though now I'm fighting with how
to make my window trap all the pointer events and not give them back
to WM.

I wanted raw Xlib for my touchscreen calibration utility for Elotouch
which I have already finished more or less.. May be some more
finetuning if I have more time scheduled for touchscreen. I needed
small and fast approach.. My "gelocal" utility is only 11Kb... and
starts instantly...

Sincerely,
Sergei

On Wed, 20 Oct 2004 09:23:08 -0400, Carl Worth <cworth at cworth.org> wrote:
> On Thu, 7 Oct 2004 17:38:20 -0400, Sergei Mutovkin wrote:
> > I'm writing my first ever program with Xlib, either I look in the
> > wrong places or there is no documentation with example available
> > anywhere (except the most basic stuff)... I wonder about some very
> > simple techniques...
> 
> First, it's worth pointing out that using raw Xlib is somewhat
> incompatible with "simple techniques". It's generally much easier to use
> a toolkit (such as GTK+ or QT) that sits on top of Xlib.
> 
> > 1. I want to create full screen window that will be on top of any
> > other window...
> 
> That feature requires interaction with the window manager. The X
> protocol doesn't mandate how this should occur, but external
> conventions have grown up. First, there is the ICCCM (Inter-Client
> Communication Conventions Manual):
> 
>         http://tronche.com/gui/x/icccm/
> 
> And, more recently, the Extended Window Manager Hints (EWMH) which
> extend the ICCCM:
> 
>         http://freedesktop.org/Standards/wm-spec/wm-spec-1.3.html
> 
> I notice that EWMH supports _NET_WM_STATE property with a value of
> _NET_WM_STATE_FULLSCREEN. So, if your window manager supports EWMH
> (which any WM worth its salt should), then you should be just one
> property away from getting this to work.
> 
> > 2.  How do I tell X to cache the graphics that I have drawn on the
> > screen, so that if something gets on top of my window, I will not have
> > re-draw everything after catching this event? (i.e. i don't want to
> > sit in a loop listening and checking if event to redraw has arrived).
> 
> You can draw to a pixmap and set that pixmap to be the window background
> with XSetWindowBackgroundPixmap. After that, the server will handle all
> expose events so that you don't have to.
> 
> > 3. xClock application if loaded with Render enabled X has anti-aliased
> > graphics... I wonder if anti-aliasing is achievable on simple graphics
> > function of Xlib like XDrawLine, etc?
> 
> Not with these graphics calls. Xlib is intended to bind rather tightly
> to the X protocol. And the protocol specifies precisely the pixelization
> that must occur when drawing lines, etc.
> 
> The new approach, (and what xclock uses), is that the Render extension
> provides a new protocol request for drawing antialiased, primitive
> polygons (trapezoids). To make that easy to work with, you'll need code
> to break up the shapes you want to draw into these trapezoids. That's
> what the cairo library is intended to do:
> 
>         http://cairographics.org
> 
> With cairo, the analogue of XDrawLine would be:
> 
>         cairo_move_to (cr, x1, y1);
>         cairo_line_to (cr, x2, y2);
>         cairo_stroke (cr);
> 
> But with the advantage that you can specify the endpoints with sub-pixel
> precision and that the coordinates can pass through an arbitrary affine
> transformation (for scaling, rotating, etc.).
> 
> > 4. By default XDrawString doesn't use Anti-aliasing on the fonts, how
> > would anyone go enabling it?
> 
> Again, XDrawString is a now old-fashioned way to draw text. It relies on
> the text support inside the X server with server-side fonts. The new way
> is to use client-side rendering of fonts with the glyph support in
> XRender. Again, there are libraries to help with this such as Xft and
> cairo.
> 
> And, again, a modern toolkit will take care of most of these issues for
> you automatically. The font work is there already, and we're working to
> get the cairo graphics support into upcoming major releases of toolkits.
> 
> > I hope I didn't ask too many questions to annoy people here... I feel
> > I'm ready to run and buy some book like "XLib In A Nutshell",
> 
> Something like that wouldn't be of much use for the modern approaches to
> graphics in X. It's very likely that it's time for somebody to write a
> new book.
> 
> I hope that helps,
> 
> -Carl
>