On Tue 23 Jan 2007 at 08:32:40 +0100, Matthew D. Fuller via RT wrote:
Speaking of funny behavior of the Occupy window, has anybody ever seen
anything like my post ~1.5 years ago about odd sized Occupy windows
not [re]drawing? I'm still stuck with manually sizing them up a pixel
or two every
On Tue 23 Jan 2007 at 00:06:31 +0100, Olaf Seibert via RT wrote:
Do the following steps to see some funny behaviour of the Occupy window:
(etc)
I think I've fixed all of this nonsense by a big simplification of the
Occupy/Workspacemanager related code, such as calculating the position
Yes, I think that is the right thing to do. I'm closing this ticket.
Is this still the case in the current version? I have something similar
and it seems to work.
# control alt delete
Delete = c | m : all : f.exec echo 'What do you think I am, a f*cking
PC?^M' /dev/console
-Olaf.
In events.c in HandleExpose() there is this code:
if (Tmp_win == Scr-workSpaceMgr.occupyWindow-twm_win) {
PaintOccupyWindow ();
flush_expose (Event.xany.window);
return;
That means that an Expose event that only covers some of the subwindows of
the
On Thu 15 Feb 2007 at 07:22:16 +0100, Richard Levitte via RT wrote:
It seems that the TwmWindow field HiliteImage is overwritten with
some random value.
This is precisely the kind of thing to find with Valgrind (see
http://valgrind.org/ ) but it's only for Linux, and I have NetBSD.
Apart
One difference with the original report that I should mention is that I
encounter the crash only when I move the transient window off-screen.
This seems fairly expected, since the NULL dereference occurs inside an
if-block which tests for exactly such a condition. I used a transient
window of xmh
On Thu 27 Dec 2007 at 16:25:54 +0100, Olaf Seibert via RT wrote:
I suppose this must be cleaned up, to at least initialise all other
fields to some sane default.
I committed and pushed that patch, revision
a8cae659665e273b3e4176d24da78ddfe0e33371.
-Olaf.
--
___ Olaf 'Rhialto' Seibert
