Re: Bug in Enlightenment?
- From: raster redhat com
- To: mhw wittsend com
- cc: Moredhel earthling net, gnome-list gnome org, eldrik logrus com, e-develop rasterman com
- Subject: Re: Bug in Enlightenment?
- Date: Wed, 27 Jan 1999 12:57:23 -0500 (EST)
On 27 Jan, Michael H. Warfield scribbled:
-> email@example.com enscribed thusly:
-> > On 27 Jan, Mark R. Bowyer scribbled:
-> > ->
-> > -> >From: "Bruce Z. Lysik" <firstname.lastname@example.org>
-> > -> >To: email@example.com
-> > -> >
-> > -> >I'm noticing a /serious/ bug in Enlightenment (from the CVS) right
-> > -> >now. At least I think it's from Enlightenment.
-> > -> >
-> > -> >Basically things start up okay, but after a while I'm unable to change
-> > -> >focus to one window. Then another, then another. Even killing the
-> > -> >process doesn't completely solve the problem. I'm left with a big,
-> > -> >black window frame that the process was running in.
-> > -> >
-> > -> >Anyone else see this, or have a solution? Thanks.
-> > ->
-> > ->
-> > -> Yup, I've noticed this - on Solaris/SPARC with 2 screens, since Raster fixed up
-> > -> the Focusing code (and thus fixed a previous bug that was annoying, but not
-> > -> *this* annoying). I reported it to the e-develop list 2 days ago, but until
-> > -> now, no-one else had seen it - so I'm really pleased for your misery, as it
-> > -> means I'm not going insane. ;O)
-> > ->
-> > -> I'm trying to figure out the cause now, since unfortunately Raster is unable to
-> > -> reproduce it, so of course can't fix it. I was under the impression it was due
-> > -> to the Focus of a window that *didn't* have direct focus on one screen being
-> > -> lost when you move the mouse to another screen. The Xserver is responsible for
-> > -> transfering Focus at this point - not the WM - so I figure something is getting
-> > -> confused around here. Raster has only the one screen, so...
-> > ->
-> > -> It's therefore *very* important to me that you let me know what configuration
-> > -> you have - OS, processor, number and type of framebuffers, versions of most
-> > -> every underlying library etc. This may help me figure out the problem. If you
-> > -> have just the 1 framebuffer too, I need to do a complete rethink =OZ
-> > ->
-> > -> As an aside, which version of libtool do you have? This has happened since I
-> > -> upgraded to 1.2d, but I've just rebuild Enlightenment from the 2nd January, and
-> > -> this bug isn't in that release, so that looks an unlikely cause =OZ
-> > ->
-> > -> Of course if you're able to debug this too, that'll help more ;O)
-> > And I'd like to point out - I'm MORE than happy to accept patches to
-> > fix this - if I could reporduce it I'd be looking into it ASAP, so I'm
-> > pleading with you who can reproduce it to please help. :)
-> I've been playing with Focus policy a lot (trying to get SOMETHING
-> similar to what I use under FVWM2) and noticed this problem. It has
-> NEVER occured for me when in CLICK_TO_FOCUS. It appears to be under
-> SLOPPY focus, but I was switching back and forth when it blew, so it's
-> hard to tell for sure. When it happened, it seemed that I would lose
-> control of an existing window when I openned up a new xterm.
-> Next point on the curve... I found that I COULD return keyboard
-> focus to the "dead" windows by switching to CLICK_TO_FOCUS and clicking
-> on the title bar. The title bar did not change highlight, but the cursor
-> in the xterm window changed and I could type into the window. If I typed
-> "exit", the xterm went away but the window stayed (solid black) and the
-> window decorations remained (but none of the buttons on the window
-> decorations responded to any mouse clicks).
-> I also found I could not "raise" a window over one of the dead
-> When it started happening, I switched to CLICK_TO_FOCUS and
-> I didn't loose a single window after that.
-> I'm working on narrowing down the conditions under which this
-> occures to help repo it...
-> BTW... This is on a Linux system (RedHat 5.2 Linux 2.2.0) with
-> enlightenment from the cvs tree.
-> On the subject of FOCUS policy... My preferred FOCUS policy is
-> CLICK_TO_FOCUS. Under FVWM2, clicking anywhere in a target window will
-> change focus and then raise the window to the top. (Is this what
-> RAISE_WINDOW_ON_NEXT_FOCUS is suppose to do?) Enlightenment will only
-> switch focus and raise the window if I click on the window decorations.
-> That can get to be a problem if the decorations are hidden by other
-> windows. Sometimes, it seems like it won't raise the window unless I
click to focus shoudl work just by clickign anywhere in the client
window.. not just decorations
-> specifically click on the title bar, clicking on the sides or resize
-> handles don't raise the window. I'm not quite sure what causes that.
-> I'm guessing that I'm largely missing the correct combination of control
-> parameters to do what I want to do.
-> > --
-> > --------------- Codito, ergo sum - "I code, therefore I am" --------------------
-> > firstname.lastname@example.org /\___ /\ ___/||\___ ____/|/\___ email@example.com
-> > Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
-> > 218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
-> > Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
-> > +1 (919) 929 9443, 801 4392 For pure Enlightenment http://www.rasterman.com/
-> > \|/ ____ \|/ For those of you unaware. This face here is in fact
-> > "@'/ ,. \@" a Linux Kernel Error Message.
-> > /_| \__/ |_\
-> > \__U_/
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
firstname.lastname@example.org /\___ /\ ___/||\___ ____/|/\___ email@example.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenment http://www.rasterman.com/
\|/ ____ \|/ For those of you unaware. This face here is in fact
"@'/ ,. \@" a Linux Kernel Error Message.
/_| \__/ |_\
] [Thread Prev