Re: [gtk-list] Re: Crashing X



Well the first time, I switche straight back, but the next time, I waited
several seconds on the VT, and checked that the proces had terminated
properly and cleaned up after itself. But as _soon_ as I switch back to
graphics, it goes down, it dosen't even do a screen redraw first. I was in
a GTK menu, or had one open at one point when I did this, and so the
keyboard and mouse were not functioning in normal windows anyhow as GTK
menus are modal (ruddy nuisance but they are) sometimes I wish people
would write TK menus that aren't modal, or at least had the option not to
be, cos you can't cross reference menu entries with, say, an xterm, or
kill the program if a menu crashes.

--
S.
GM/CS/MU -d+ H+>++ s+: !g p2 au0 !a w+++ v-(---) C++++$ UL++++$ UB+
US++ UI+++$ P+>++++ L++++$ 3+ E--- N+ K !W(-----) M+(-) !V -po+ Y+ t+
5++ !j !R G' !tv b+++ D++ B--- e+ u+* h++ f? r-- n---- y?


On Sun, 3 May 1998, fractture wrote:

> Shevek wrote:
> 
> > I better admit I'm a lame programmer before I start this, cos you'll only
> > realise it after 5 lines.
> >
> > I made a GTK application that looped. Now I had set up a kill event in a
> > xterm just incase of that, but with a menu open, the mouse focus can't
> > move to it. So I changed to a text terminal, sent the GTK program an
> > ordinary kill signal, and it totally munged the X server, the whole of X
> > exited down the drain. I've done this twice now, much to my annoyance. As
> > soon as I switch back to the X vt, it goes down.
> 
> Did you move the mouse or hit a key?
> X often times crashes if you switch to a virtual terminal and move the mouse
> or hit a key to soon.  If there is a blinking curser somewere, let it start
> blinking before you touch anything.
> or 2-5 seconds does the trick if not.
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]