Welcome to the most active Linux Forum on the web.
Go Back > Forums > Non-*NIX Forums > Programming
User Name
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.


  Search this Thread
Old 10-13-2006, 06:26 PM   #1
LQ Newbie
Registered: Oct 2006
Posts: 3

Rep: Reputation: 0
Post How does one draw pixels directly onto the window in C and Modular X11R7?

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

Thank you,
Amit Ron
Old 10-14-2006, 01:23 PM   #2
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Tribblix, Ubuntu/WSL
Posts: 9,767

Rep: Reputation: 467Reputation: 467Reputation: 467Reputation: 467Reputation: 467
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 ?
Old 10-15-2006, 02:49 AM   #3
LQ Newbie
Registered: Oct 2006
Posts: 3

Original Poster
Rep: Reputation: 0
Well, I was interested in drwing pixels onto the window to create a very primitive toolkit for my programme (as a personal challenge).
Old 10-15-2006, 03:37 AM   #4
Registered: Feb 2004
Location: Outside Paris
Distribution: Solaris 11.4, Oracle Linux, Mint, Tribblix, Ubuntu/WSL
Posts: 9,767

Rep: Reputation: 467Reputation: 467Reputation: 467Reputation: 467Reputation: 467
Onto what window ?

Assuming you want to use Xlib, here's a tutorial:
Old 10-15-2006, 06:54 AM   #5
Registered: Aug 2003
Location: Mallorca, Spain
Distribution: xubuntu
Posts: 551

Rep: Reputation: 38

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 or here that starts
* Stolen from XPenguins (
* Some coding style/indentation changes.
* Copyright (C) 2003 Daniel Caujolle-Bert <>

/* 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
* 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 and implement their
* Extended Window Manager Hints spec that help pagers and apps like
* xpenguins and xearth to find their way around. In particular,
* 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.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Mapping CTRL+Click as right click using xmodmap in Modular X.Org 7 on Gentoo amitron Linux - General 0 10-12-2006 12:25 PM
Modular X.Org help requested hakktheplanet Linux - Software 2 03-22-2006 07:10 AM
Java: how can I draw individual pixels? johnMG Programming 2 06-05-2005 10:03 PM
Strange mouse resolution ? 2 pixels by 2 pixels Creak Linux - General 8 04-18-2004 08:17 PM
X window change pixels tank728 Slackware 1 09-17-2003 10:57 PM > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 06:05 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration