This seems to be (given my limited understanding) similar to what
acme-sac is doing.

Is there any way we could solve the current state of affairs with
slightly diverging gui/draw codebases for p9p, drawterm, 9vx, acme-sac
and inferno-os? Each seems to have a set of bugs that somewhat
overlaps with the other projects, and they have to be rediscovered,
and the fixes moved around again and again.

That also would mean that new ports, to for example win32, would
propagate much more easily (or at least as far as the gui code is
concerned).

Peace and best wishes

uriel

On Thu, Jul 3, 2008 at 4:57 PM, andrey mirtchovski
<[EMAIL PROTECTED]> wrote:
> I think the problem comes from 9vx picking up the main display's
> dimensions as the preallocation for "full screen". Drawterm has a fix
> for that which loops through all the currently attached displays and
> picks up the one with the largest size to decide what the "maximum
> dimensions" should be.
>
> here's the relevant code from drawterm:
>
> /* figure out which display is the largest and return its bounds so we can
>  * preallocate drawterm's screen to that
>  */
> Point
> get_largest_screen()
> {
>        CGDirectDisplayID       *displaylist;
>        CGDisplayCount          displaycount;
>        OSErr                           err;
>        int i;
>        Point max = Pt(0, 0);
>        Point curr;
>        err = CGGetActiveDisplayList(0, NULL, &displaycount);
>        if(err != noErr)
>                sysfatal("can not enumerate active displays");
>
>        displaylist = (CGDirectDisplayID *)malloc(displaycount *
> sizeof(CGDirectDisplayID));
>        if(displaylist == NULL)
>                sysfatal("can not allocate memory for display list");
>
>        err = CGGetActiveDisplayList(displaycount, displaylist, &displaycount);
>        if(err != noErr)
>                sysfatal("can not obtain active display list");
>
>        for(i = 0; i < displaycount; i++) {
>                curr.x = CGDisplayPixelsWide(displaylist[i]);
>                curr.y = CGDisplayPixelsHigh(displaylist[i]);
>
>                if(max.x < curr.x)
>                        max.x = curr.x;
>                if(max.y < curr.y)
>                        max.y = curr.y;
>        }
>
>        free(displaylist);
>
>        return max;
>
> }
> you will need to modify _screeninit() in 9vx/osx/screen.c to something like:
>
> Point max = get_largest_screen();
> osx.fullscreenr = Rect(0, 0, max.size.width, max.size.height);
>
> this is tentative. i have no second screen to test right now.
>
> On Thu, Jul 3, 2008 at 8:38 AM, Anthony Sorace <[EMAIL PROTECTED]> wrote:
>> I have a 10.5 MacBook with an external display attached. When I start
>> 9vx, things look normal. I can resize the window on the main display.
>> If I move it to the second display and resize, the window goes from
>> "good" to "bad":
>>
>> http://strand1.com/who/anthony/bug/good.png
>> http://strand1.com/who/anthony/bug/bad.png
>>
>> Resizing the window back to the original geometry makes the window "good" 
>> again.
>>
>> Note that this is "just" a display issue. Things within 9vx continue
>> to run just fine, and can update the display (although that becomes
>> unreliable, especially in the portion of rio windows to the left of
>> where they should be). Dragging my mouse over where the rio window
>> border should be causes the cursor to turn into the "resize" cursor,
>> and resizing works fine, dragging the still-slanted window around.
>>
>> This happens independent of what's running within 9vx: I see the same
>> thing even with no rio.
>> Anthony
>>
>>
>
>

Reply via email to