On 09/27/2010 05:36 PM, Timo Juhani Lindfors timo.lindf...@iki.fi
wrote:
3) show-window is just a quick'n'dirty helper application to make the
xterm visible:
alternatively, how about
xterm -xrm 'XTerm.overrideRedirect: true' -geometry 100x100+100+100
and
XSetInputFocus (dpy, PointerRoot,
On 09/23/2010 04:43 PM, Carsten Haitzler (The Rasterman) wrote:
On Thu, 23 Sep 2010 15:40:47 +0200 Eeri Kask eeri.k...@mailbox.tu-dresden.de
said:
No I don't, though it looks like the current server implementation
only ensures WMs have no advantage in knowing something about
On 09/24/2010 02:25 PM, Clemens Eisserer linuxhi...@gmail.com wrote:
My attemp tried to find a 32-bit visual, and pass that to
XCreateWindow:
XVisualInfo info;
int cnt;
XVisualInfo *visInfos = XGetVisualInfo(display, 0, NULL, cnt);
info.screen = XDefaultScreen (display);
info.depth =
, or
(2) don't discriminate less widespread X11-technology use cases?
(Looking statistically computer users on the planet run windows
anyways, so following this argument why fiddle with X11 at all,
then?) :-)
Greetings,
Eeri Kask
___
xorg mailing list
pays developers to
work on Xorg drivers because it brings in revenue for them.)
Oh indeed ... which pragmatically implies the dual economic
imperative,
(4) lacking significant paying customer base demanding removal of
classic multiscreen support...
Jokingly,
Eeri Kask
,
Eeri Kask
P.S. To prove it is XftDrawString8() problem please change
#if 1 /* enable/disable exposures */
to
#if 0 /* enable/disable exposures */
few lines below and rerun.
/*
gcc -o textbitmapshape_bugdemo TextBitmapShape_BugDemo.c -lX11 -lXext -lXft
-L/usr
and the
composite extension don't work together very well if at all:
consequently following the above reasoning would mean both of the
compositing routines, XRenderComposite() and XRenderFillRectangle(),
should be restricted to the clip-area of the XShape-extension.) :-)
Greetings,
Eeri Kask
Hello,
it appears configure_win() lacks a call to determine_mode() so
window mode is uninitialised in subsequent call to win_extents().
Greetings,
Eeri Kask
--- xcompmgr.c.DetermineMode.orig 2009-09-25 15:18:10.0 +0200
+++ xcompmgr.c 2009-09-25 15:18:56.0 +0200
started _after_ starting xcompmgr, and
which therefore are not yet 'mapped', but will be 'configured' first.
Greetings,
Eeri Kask
--- xcompmgr.c.AddWinDetermineMode.orig 2009-09-25 18:08:07.0 +0200
+++ xcompmgr.c 2009-09-25 18:07:34.0 +0200
@@ -1479,6 +1479,8 @@
*p = new
Am 09/25/2009 03:54 PM, Yann Droneaud schrieb:
Le mercredi 23 septembre 2009 à 21:10 +0200, Eeri Kask a écrit :
Hello,
it appears xcompmgr does not decorate windows with ARGB 32-bit
visuals; which at first sight seems probably a preference of
artistic taste than a result of engineering
)
+while ((o = getopt (argc, argv, D:I:O:d:r:o:l:t:b:scnfFCaSA))
!= -1)
{
switch (o) {
case 'd':
needs a minor edit.
Greetings,
Eeri Kask
--- xcompmgr.c.orig 2009-09-23 14:51:38.0 +0200
+++ xcompmgr.c 2009-09-23 14:54:08.0 +0200
@@ -190,6 +190,7
this name
into RGB values used by XRenderFillRectangle() in root_tile() in
xcompmgr.c.
Greetings,
Eeri Kask
--- xcompmgr.c.orig 2009-09-19 19:45:12.0 +0200
+++ xcompmgr.c 2009-09-19 19:54:07.0 +0200
@@ -760,6 +760,8 @@
NULL,
};
+static XRenderColor RootFill = {.red
of setting farther and child to root (and width, height to
zero), why not use XTestFakeMotionEvent()?
Extending your application by eye blink detector you could cleanly
implement mouse buttons by XTestFakeButtonEvent(), or even create a
complete air keyboard.
Greetings,
Eeri Kask
consider executing
XSetInputFocus (dpy, None, RevertToNone, CurrentTime);
right in front of exit(0); a good idea even if they don't own the
focus... and all like that.
Greetings,
Eeri Kask
___
xorg mailing list
xorg@lists.freedesktop.org
Daniel Stone wrote:
On Tue, Sep 30, 2008 at 07:20:25PM +0200, Eeri Kask wrote:
Having tweaked the TWM since last year to turn it into something
contemporary in look and handy in function, today as a landmark of
approaching zero items in my own kept TWM bugs-, todo- and wish-list may
I
Maarten Maathuis wrote:
On 12/23/2008 12:14 PM, Eeri Kask wrote:
Maarten Maathuis:
On 12/19/2008 08:42 PM, Carl Karsten wrote:
The placement logic is output driven, and doesn't take panning into
account. So you end up with strange overlap. If dual head + panning
was a goal you might
as
meaningful interpretation/behaviour can be almost always invented even
in case of a sudden framebuffer size change (who knows in future the
framebuffer can be effortless dynamically resized as X11-windows do today).
Greetings,
Eeri Kask
___
xorg
17 matches
Mail list logo
