How does one draw pixels directly onto the window in C and Modular X.org X11R7?
 

How does one draw pixels directly onto the window in C and Modular X.org X11R7?
Can anyone give examples or tutorials, please?

Thank you,
Amit Ron

I don't think X11R7 make any difference. There are several X11 primitives to draw pixels, like for example XDrawPoint.
What is exactly the issue you have ?

Well, I was interested in drwing pixels onto the window to create a very primitive toolkit for my programme (as a personal challenge).

Onto what window ?

Assuming you want to use Xlib, here's a tutorial:

http://users.actcom.co.il/~choo/lupg...ogramming.html

Hi,

I hade the same need and I found out you need a "fake" window before since the root window is not a real window. In pinboard.c for Rox-filer i found this comment /* This is a bit complicated...
*
* An icon needs to be a NO_WINDOW widget so that the image can
* blend with the background (A ParentRelative window also works, but
* is slow, causes the xfree86's memory consumption to grow without
* bound, and doesn't even get freed when the filer quits!).
*
* However, the icon also needs to have a window, so we get events
* delivered correctly. The solution is to float an InputOnly window
* over the icon. Since GtkButton works the same way, we just use
* that :-)
*/

and the desktop created uses atom "_NET_WM_WINDOW_TYPE_DESKTOP".

Since i make a kiosk application and have total control I do not have to bather about diffrent tecnics how the desktop is made. If you need that you should look in the code of http://xpenguins.seul.org/ or here http://www.koders.com/c/fid909F1EFD2...W_TYPE_DESKTOP that starts
/*
* Stolen from XPenguins (http://xpenguins.seul.org/)
*
* Some coding style/indentation changes.
*
* Copyright (C) 2003 Daniel Caujolle-Bert <segfault@club-internet.fr>
*
*/

/* toon_root.c - finding the correct background window / virtual root
* Copyright (C) 1999-2001 Robin Hogan
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/

/* Since xpenguins version 2.1, the ToonGetRootWindow() function
* attempts to find the window IDs of
*
* 1) The background window that is behind the toplevel client
* windows; this is the window that we draw the toons on.
*
* 2) The parent window of the toplevel client windows; this is used
* by ToonLocateWindows() to build up a map of the space that the
* toons can occupy.
*
* In simple (sensible?) window managers (e.g. blackbox, sawfish, fvwm
* and countless others), both of these are the root window. The other
* more complex scenarios that ToonGetRootWindow() attempts to cope
* with are:
*
* Some `virtual' window managers (e.g. amiwm, swm and tvtwm) that
* reparent all client windows to a desktop window that sits on top of
* the root window. This desktop window is easy to find - we just look
* for a property __SWM_VROOT in the immediate children of the root
* window that contains the window ID of this desktop window. The
* desktop plays both roles (1 and 2 above). This functionality was
* detected in xpenguins 1.x with the vroot.h header file.
*
* Enlightenment (0.16) can have a number of desktops with different
* backgrounds; client windows on these are reparented, except for
* Desktop 0 which is the root window. Therefore versions less than
* 2.1 of xpenguins worked on Desktop 0 but not on any others. To fix
* this we look for a root-window property _WIN_WORKSPACE which
* contains the numerical index of the currently active desktop. The
* active desktop is then simply the immediate child of the root
* window that has a property ENLIGHTENMENT_DESKTOP set to this value.
*
* KDE 2.0: Oh dear. The kdesktop is a program separate from the
* window manager that launches a window which sits behind all the
* other client windows and has all the icons on it. Thus the other
* client windows are still children of the root window, but we want
* to draw to the uppermost window of the kdesktop. This is difficult
* to find - it is the great-great-grandchild of the root window and
* in KDE 2.0 has nothing to identify it from its siblings other than
* its size. KDE 2.1+ usefully implements the __SWM_VROOT property in
* a child of the root window, but the client windows are still
* children of the root window. A problem is that the penguins erase
* the desktop icons when they walk which is a bit messy. The icons
* are not lost - they reappear when the desktop window gets an expose
* event (i.e. move some windows over where they were and back again).
*
* Nautilus (GNOME 1.4+): Creates a background window to draw icons
* on, but does not reparent the client windows. The toplevel window
* of the desktop is indicated by the root window property
* NAUTILUS_DESKTOP_WINDOW_ID, but then we must descend down the tree
* from this toplevel window looking for subwindows that are the same
* size as the screen. The bottom one is the one to draw to. Hopefully
* one day Nautilus will implement __SWM_VROOT in exactly the same way
* as KDE 2.1+.
*
* Other cases: CDE, the common desktop environment. This is a
* commercial product that has been packaged with Sun (and other)
* workstations. It typically implements four virtual desktops but
* provides NO properties at all for apps such as xpenguins to use to
* work out where to draw to. Seeing as Sun are moving over to GNOME,
* CDE use is on the decline so I don't have any current plans to try
* and get xpenguins to work with it.
*
* As a note to developers of window managers and big screen hoggers
* like kdesktop, please visit www.freedesktop.org and implement their
* Extended Window Manager Hints spec that help pagers and apps like
* xpenguins and xearth to find their way around. In particular,
* please use the _NET_CURRENT_DESKTOP and _NET_VIRTUAL_ROOTS
* properties if you reparent any windows (e.g. Enlightenment). Since
* no window managers that I know yet use these particular hints, I
* haven't yet added any code to parse them. */

#include <stdio.h>
#include <string.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <X11/Xproto.h>

#include "_xitk.h"

/* Time to throw up. Here is a kludgey function that recursively calls
* itself (up to a limit) to find the window ID of the KDE desktop to
* draw on. It works with KDE 2.0, but since KDE 2.0 is less stable
* than Windows 95, I don't expect many people to remain using it now
* that 2.1 is available, which implements __SWM_VROOT and makes this
* function redundant. This is the hierarchy we're trying to traverse:
*
* -> The root window
* 0 -> window with name="KDE Desktop"
* 1 -> window with no name
* 2 -> window with name="KDE Desktop" & _NET_WM_WINDOW_TYPE_DESKTOP
* 3 -> window with no name and width >= width of screen
*
* The last window in the hierarchy is the one to draw to. The
* numbers show the value of the `depth' argument. */


I hope this is a start. It took me a long time to get this far. Happy programming.