On Mon, Sep 22, 2008 at 3:14 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Mon, Sep 15, 2008 at 12:59:52AM -0400, Mikus Grinbergs wrote: >> 760. Running (on my XO) a ported Linux application which puts up >> multiple screens. As far as I could tell. I was able to access all >> of those screens by using the alt-tab procedure. But while doing >> this the Frame was unacceptably intrusive. For instance, I could >> not see the titles on the top line, which identified each screen. >> >> If I rapidly pressed alt-tab and released -- the XO would not bother >> to switch screens. If I slowly pressed alt, then tab - the XO would >> bring up the Frame. I would need to release and press tab another >> time to get the XO to switch to the next screen (while still showing >> the Frame). I would need to release alt to get the XO to stop >> overlaying the screen edges with the Frame. [And it seemed to me >> that sometimes the Frame would not go away even then - I would have >> to press and release the Frame key to ensure that it was gone for good.] >> >> -------- >> >> One of the first things I did upon getting my G1G1 was to go into >> one of the .py files and __NOOP__ the "autoraising" of the Frame. >> That gave me Sugar screen behavior that was under *my* control. >> >> Now, Sugar has again started to interfere with what I am doing -- >> by raising the Frame when I alt-tab. I HATE THAT! I HATE THAT! >> I thought the idea was to have the human in control of the computer, >> instead of the computer dictating what the human may see. >> >> I would like the Frame function in the Control Panel to allow me to >> optionally disable the automatic showing of the Frame upon alt-tab. >> [Let *me* decide when I want to see the Frame !] >> >> In the meantime, I guess I will have to go back to modifying the .py >> files in Sugar - to reclaim Sugar screen behavior that does not >> interfere with my use of the computer. >> > > I think the idea is to use the frame to show you which windows you can > alt+tab between, such as is done in Gnome or other WMs. This is, in my > opinion, quite useful. However, I am unsure of the utility of clumsily > animating the transition of the frame into view, or the lack of > configurability of this option. > > So perhaps the best thing to do is to add a configuration option to > allow the user to enable or disable this behavior? > > Would it be better if the frame was quickly displayed instead of sliding > into view? Maybe generally we need a configuration option to turn on > and off fancy animations to improve system responsiveness?
Perhaps in the short term a boolean (exposed or not...I'd lean toward not) would suit. The big isue is lack of composition support. The Frame currently "slides in" about 1/2 as fast as I'd like it to, and choppily at that. With composition we could get smooth motion and also speed it up significantly. (The only reason it's so slow now, I believe, is because without composition we can't draw frames fast enough to convey the motion unless we increase the length of the reveal.) - Eben > Erik > _______________________________________________ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar