Re: [STUMP] Interesting Bug...

[Brit Butler]

> Are you saying you get into a situation where (screen-heads (current-screen)) 
> is (#S(frame 0 NIL 0 0 1680 1050)) (as above), but the windows are still 
> 1280x800?

Or vice versa, yes. It's quite curious because they will resize under
some circumstances but it isn't immediate. For example, I just
switched from VGA to laptop in a group with a hsplit and a vsplit, a
file manager on the left and two terminals on the right. The file
manager resized immediately but the terminals didn't. Launching
lxrandr in one of the terminals made it resize right away. Here's a
screenshot: http://redlinernotes.com/docs/2010-01-23.png

I run fix-layout so that everything resizes immediately, rather than
eventually. :)

>  Did you have any luck with setting *top-level-error-action* to :break? I 
> haven't been able to reproduce your crash here so a backtrace would be very 
> useful for diagnosing it.

It's a bit embarrassing but I can't narrow this down enough to
reproduce it with complete reliability. I just managed to cause the
error a few times, once with *top-level-error-action* set to :break
and once set to :abort but I only saw the same restarts from before.

Essentially, the bug is: input becomes trapped in whatever frame I was
in as stump is unresponsive, the mode-line goes blank. Switching to
tty1 and running htop shows stumpwm using ~90% cpu, running emacs -nw
in this tty and slime-connecting works, (in-package :stumpmw). I
generally try to run (loadrc) and after a second it gives me the
restart options I mailed before. Selecting abort returns the system to
normal. It's worth noting that the lxrandr window doesn't close after
switching screens as it should. It just stays open (and no frames
resize) until I've selected a restart for the type-error.

Regards,
Brit

On 1/23/10, Ben Spencer <address@hidden> wrote:
> On Fri, Jan 22, 2010 at 10:21:33PM -0500, Brit Butler wrote:
>> 2) laptop enabled, VGA enabled with these results:
>> address@hidden paktahn-dev]$ xdpyinfo -ext XINERAMA | grep head
>>   head #0: 1680x1050 @ 0,0
>>   head #1: 1280x800 @ 0,0
>> STUMPWM> (screen-heads (current-screen))
>> (#S(frame 0 NIL 0 0 1280 800))
>
> This is a bug (or feature, depending on how you look at it).  When
> there are overlapping heads, make-screen-heads removes duplicates
> without looking at the size of the heads involved.  So in your case,
> head #0 is eliminated just because it happens to be first and you get
> a 1280x800 head.
>
> What I'm not too sure about is what the correct behaviour should be
> when this happens.  I can think of the following options:
>
> 1) Use the intersection of all the overlapping heads.  This would
> result in wasted pixels on the larger ones.
>
> 2) Use the union of all overlapping heads.  I think this is a
> non-starter because you could end up with sections that weren't
> visible on any head.
>
> 3) Use the biggest head, relegating the smaller heads to second-class
> citizens who can't see the whole desktop.
>
> 4) Subdivide the union of all the heads into visible rectangles and
> treat those as 'heads'.  This would allow for effective use of every
> visible bit of screen but is weird and unintuitive.
>
> Of these, 2) and 3) would give you the behaviour you want, but both
> would be less than ideal under other circumstances.
>
>
>> 3) laptop disabled, VGA enabled with these results:
>> address@hidden paktahn-dev]$ xdpyinfo -ext XINERAMA | grep head
>>   head #0: 1680x1050 @ 0,0
>> STUMPWM> (screen-heads (current-screen))
>> (#S(frame 0 NIL 0 0 1680 1050))
>>
>> The reason I switch completely, only running one display at a time, is
>> because of my other problem. You'll notice (screen-heads (current-screen))
>> remains at 1280x800 with the laptop + VGA monitor enabled. So enabling
>> both
>> "heads" only gets me one head listed for (screen-heads (current-screen))
>> which fails to take advantage of the new screen space. This is why I wrote
>> my fix-layout defcommand but that too only works when there is a single
>> display enabled.
>
> I'm still unclear on one point.  You say you have to disable the
> laptop display for fix-layout to work, but when you do that stumpwm
> should notice and resize the windows for you.  Are you saying you get
> into a situation where (screen-heads (current-screen)) is (#S(frame 0
> NIL 0 0 1680 1050)) (as above), but the windows are still 1280x800?
>
> Did you have any luck with setting *top-level-error-action* to :break?
> I haven't been able to reproduce your crash here so a backtrace would
> be very useful for diagnosing it.
>
>
> Ben
>
>
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>