On 21.11.2011, at 18:06, Paul Fox wrote: > bert wrote: >> On 21.11.2011, at 15:22, Paul Fox wrote: >> >>> it quickly became clear (to me, at least) that it would be confusing >>> if user-dimming behaved differently than auto-backlight-control, with >>> respect to monochrome mode. whether or not it's confusing to the >>> user, it's definitely confusing to the code, since it's difficult to >>> always do the right thing if the user and the sensor are both changing >>> the brightness at the same time. so i disabled the switch to >>> monochrome entirely -- using the brightness keys doesn't change the >>> color/mono setting. >> >> IMHO (and not having tried it yet) the current behavior (switching >> to mono when manually reducing brightness) is fine, and the best >> compromise we found so far. > > have we actually tried anything else? the coupling of monochrome to > brightness has been this way forever, as far as i know.
I remember the command line interface, and some GUI tool with checkboxes. Admittedly that's from before the XO-1 was even mass-produced. But I do remember discussing how the keyboard control should work. > honestly, i'm surprised people consider this coupling to be so > important. I personally would like to have a way to toggle it on and off all the time, independent of backlight brightness. I'm just saying coupling it to the brightness control is a brilliantly simple way to make it work for users who aren't even aware of the details. > given how subtle the difference between color and mono > modes with the backlight off, i really doubt most users would even > notice the change. To me it's striking how much sharper the image gets all of a sudden. But then I do have a graphics background and am a hobby-typophile. Most users wouldn't consciously notice the change, agreed. But that's not the same as saying it doesn't matter. >> When you add the auto-turnoff, it should only toggle the backlight, >> not the mono-color setting. I don't think that would be too >> confusing, from a user's POV it just means when it's bright >> outside, the backlight's power gets cut. >> >> I can see how it would lead to confusion if you map this desired >> behavior onto the existing olpc-brightness command. What's needed >> I think is an additional "override" independent of the brightness >> setting that just turns the backlight off. Everything else would >> stay the same. > > it's not that easy. unless neither brightness mechanism messes with > the mono setting, then they need to be coupled somehow. otherwise > if the backlight is auto-offed (still color), then the user uses the > "dim" key (no brightness change, but now mono), and then the backlight > auto-ons, it will now be in mono. That's not what I had in mind. Taking your example, the display would not auto-on since the user explicitly set it to off. Auto-off should be completely independent of the user adjusting the brightness. E.g.: Brightness is set to 10. User goes outside, ambient sensor overrides, turning backlight off. User presses brightness-down, level is set to 9. Backlight is still overridden due to ambient light. User goes inside, ambient override stops, backlight comes back on at level 9. See what I mean? The user shouldn't have to care about the ambient light sensor turning off the display. All the controls would still work the same. Just like on older XOs. > do you also object to the new color/mono toggle, via the control > key (or via the UI)? Not at all. > please try os12, when available, and see how it feels. > > paul Will do. - Bert - _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel