[Sugar-devel] Screen Reposition?

[Art Hunkins]

At:
http://dev.sugarlabs.org/ticket/39
I found the following observation:

"I think that the right solution for such a tiny display is to globally 
scale the display, using the bin/sugar to set SUGAR_SCALING to 72. The 
question is, how to detect display resolution from this shell script? The 
only solution I can think of is an evil hack involving xrandr and sed, and 
there has to be a better way."

I'd like to experiment with setting SUGAR_SCALING, but cannot locate 
bin/sugar on SoaS. Can anyone give me the appropriate file/location?

My idea is that if this variable works to "resize the screen", maybe this 
value might be temporarily "reset" by a python script.

Art Hunkins

----- Original Message ----- 
From: "Tomeu Vizoso" <tomeu at sugarlabs.org>
To: <bens at alum.mit.edu>
Cc: "Art Hunkins" <abhunkin at uncg.edu>; <sugar-devel at lists.sugarlabs.org>
Sent: Monday, August 03, 2009 11:28 AM
Subject: Re: [Sugar-devel] Screen Reposition?


On Mon, Aug 3, 2009 at 17:12, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> Tomeu Vizoso wrote:
>> On Mon, Aug 3, 2009 at 16:55, Art Hunkins<abhunkin at uncg.edu> wrote:
>>> Is it still possible that resize capability, at least for PyGTK code 
>>> without
>>> absolute positioning, might be included in SoaS?
>>
>> I don't know if it's possible, anyone has an idea of how feasible is 
>> this?
>
> I feel like I'm reading a conversation among Dadaists. This conversation
> doesn't make any sense at all.
>
> PyGTK code without absolute positioning resizes automatically by default,
> if you can even call it that. If you haven't specified absolute sizes,
> then there is no size from which to "resize", and GTK simply chooses the
> best size to fit the window. There is no question of feasibility, because
> this is the default behavior on every platform, and has always been.
>
> It may be that Strawberry is not correctly configured to handle high-DPI
> screens. That's a bug, but it's not preventing automatic resizing. It's
> just sizing based on an incorrect model of the screen.

The issue here isn't activity windows not taking all available space,
but rather UI elements not keeping the proportions that the author
intended.

Regards,

Tomeu

> --Ben
>
>