SRU insanity

[Thomas Jaeger]

This is going to be a little bit of a rant.  I was originally going to
address this issue in a less confrontational tone after those issues
have been fixed, but it's almost two months since intrepid has been
released, and I just can't take this crap any longer.

It certainly makes sense that we want SRU bugfixes to be thoroughly
vetted before they make it into the distribution.  I can even understand
why you would err on the side of caution in some cases, but there
absolutely needs to be a way to fast-track the process for high-profile
bugs.  There are several bugs that fit this description (don't even get
me started on #59695), but I'm going to focus on two bugs that affect
users of intel's 4965 wireless chip:

https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27/+bug/276990
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/286285

These bugs have several common characteristics:

1.  A huge user base is affected.
This has to be one of the most common wireless chipset that is built
into laptop these days, and nearly everyone that owns such a laptop is
affected.

2.  Those bugs are extremely critical, rendering affected machines
practically useless.
There's some serious potential here for turning users away from ubuntu
or linux in general.

3.  They have trivial fixes/workarounds that have no potential to
introduce regressions.

4.  The fixes have been upstream for ages.

5.  Both bugs have been completely mishandled from the start:
After someone found out in the tracker for #276990 that the bug was
fixed in a current compat-wireless snapshot, the only possible fix for
this bug was to update to a development wireless snapshot.  Nobody even
thought about identifying and backporting the patch that was responsible
for fixing the problem, check the upstream tracker or contact upstream.
 The "solution" was to tell people to update to a random (not
particularly stable, according to the comments) compat-wireless
snapshot, packaged as linux-backports-modules that by the way still
doesn't contain the fix for the other bug.  Users were supposed to learn
of this from the release notes, but of course most people don't read
them.  In bug #286285, it took way too long until some contacted
upstream, and upstream was able point us to the fix in less than a day.

There is definitely a lesson to be learned from this, which is that if
people don't know what the deal is with a bug, upstream needs to be
involved.

In addition, the first bug has a particularly insidious property:

6.  Without kernel modesetting, it is almost impossible for users to
identify why the problem occurs.  They just notice a blinking Numlock
LED, without even a clue that this is related to their wireless driver.


In short, those bugs meet all the conditions for a swift SRU, and they
got into -proposed right a way, but nothing has happened since then.
This is causing a great deal of frustration and is a gigantic waste of
time for everyone involved:  The users whose laptops keep crashing or
whose logs are being flooded.  The developers who triage bugs and come
across duplicates.  Everyone who is subscribed to the reports and has to
deal with the constant spam by clueless users who  don't understand how
to apply the fix.

Don't get me wrong, dealing with less experienced users is actually
something I enjoy, but having a relatively small number of experienced
users means that we don't want to piss off people that can actually help
fix bugs.  I already had a bad experience a while ago with bug #152187
(where developers basically didn't trust me that the solution was going
to be implemented upstream) and now this.  It's really hard to get
motivated to spend your time on problems like these if it takes forever
until they make it into the distribution and you need to spend more time
lobbying for the fix than it takes to solve the problem.

Tom

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

SRU insanity

[Thomas Jaeger]

This is going to be a little bit of a rant.  I was originally going to
address this issue in a less confrontational tone after those issues
have been fixed, but it's almost two months since intrepid has been
released, and I just can't take this crap any longer.

It certainly makes sense that we want SRU bugfixes to be thoroughly
vetted before they make it into the distribution.  I can even understand
why you would err on the side of caution in some cases, but there
absolutely needs to be a way to fast-track the process for high-profile
bugs.  There are several bugs that fit this description (don't even get
me started on #59695), but I'm going to focus on two bugs that affect
users of intel's 4965 wireless chip:

https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27/+bug/276990
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/286285

These bugs have several common characteristics:

1.  A huge user base is affected.
This has to be one of the most common wireless chipset that is built
into laptop these days, and nearly everyone that owns such a laptop is
affected.

2.  Those bugs are extremely critical, rendering affected machines
practically useless.
There's some serious potential here for turning users away from ubuntu
or linux in general.

3.  They have trivial fixes/workarounds that have no potential to
introduce regressions.

4.  The fixes have been upstream for ages.

5.  Both bugs have been completely mishandled from the start:
After someone found out in the tracker for #276990 that the bug was
fixed in a current compat-wireless snapshot, the only possible fix for
this bug was to update to a development wireless snapshot.  Nobody even
thought about identifying and backporting the patch that was responsible
for fixing the problem, check the upstream tracker or contact upstream.
 The "solution" was to tell people to update to a random (not
particularly stable, according to the comments) compat-wireless
snapshot, packaged as linux-backports-modules that by the way still
doesn't contain the fix for the other bug.  Users were supposed to learn
of this from the release notes, but of course most people don't read
them.  In bug #286285, it took way too long until some contacted
upstream, and upstream was able point us to the fix in less than a day.

There is definitely a lesson to be learned from this, which is that if
people don't know what the deal is with a bug, upstream needs to be
involved.

In addition, the first bug has a particularly insidious property:

6.  Without kernel modesetting, it is almost impossible for users to
identify why the problem occurs.  They just notice a blinking Numlock
LED, without even a clue that this is related to their wireless driver.


In short, those bugs meet all the conditions for a swift SRU, and they
got into -proposed right a way, but nothing has happened since then.
This is causing a great deal of frustration and is a gigantic waste of
time for everyone involved:  The users whose laptops keep crashing or
whose logs are being flooded.  The developers who triage bugs and come
across duplicates.  Everyone who is subscribed to the reports and has to
deal with the constant spam by clueless users who  don't understand how
to apply the fix.

Don't get me wrong, dealing with less experienced users is actually
something I enjoy, but having a relatively small number of experienced
users means that we don't want to p*ss off people that can actually help
fix bugs.  I already had a bad experience a while ago with bug #152187
(where developers basically didn't trust me that the solution was going
to be implemented upstream) and now this.  It's really hard to get
motivated to spend your time on problems like these if it takes forever
until they make it into the distribution and you need to spend more time
lobbying for the fix than it takes to solve the problem.

Tom

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea?

[Thomas Jaeger]

habtool wrote:
> 
> More chats about it here:
> 
> http://ubuntulinuxtipstricks.blogspot.com/2009/01/since-we-all-know-x-is-nowhere-near.html

I think it's quite telling that the people that have accepted X Server
freezes as a fact of life could point to a single bug report where such
an issue was discussed.  This, of course, leaves us completely in the
dark as to what the real issues are, but in any case, C-A-B is not the
solution.  It's very simple actually: If your X Server does weird stuff
like that, that's not normal (seriously, don't tell anyone it is,
because it isn't). *File a bug report*.  People are generally very
interested in fixes those.

Let's speculate a little bit what kind of issues these people are
seeing.  If it was bugs the drivers, C-A-B probably wouldn't do
anything.  I very much doubt that these are bugs in the actual X server,
because then everybody would be affected.  So that leaves as the most
likely candidate client applications that run amok and don't release a
server/pointer/keyboard grab.  If that's the case, nothing is lost yet
and you can switch to a terminal or ssh into your machine and kill the
offending application to get your X Server back to normal.  Then file a
bug report and get the application fixed.  I seem to remember something
about a release-all-grabs key, which would make it much easier to get
things back to normal, but I can't find anything about it right now.

Tom

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea?

[Thomas Jaeger]

I can't really take these blanket statements seriously if you can't
point me to specific bug reports, sorry.

Remco wrote:
> Client applications, and even X.org itself, will always have bugs.
> They are created by humans, and we are not perfect. In that respect,
> it is normal behaviour. So C-A-B will never become obsolete.
> 
> Things that can happen:
> 
> * Client can grab keys but hang.
In that case, you get the X Server back to normal by killing the client
and you should try and fix the client.

> * System can become too slow to be usable.
This is way too vague to make a useful argument.

> * Xorg/drivers can have a bug that locks the screen.
As I said before, I doubt C-A-B will help you there. Shift+SysRq+K
might, though.

> All of these things will happen in the future, no matter what you do.
> C-A-B will fix it in many cases. Hitting C-A-B twice is preferred over
> a dialog, because you can't reasonably react to a dialog if the system
> is too slow to be usable.

The only acceptable solution to me is fixing the underlying problems.
>From what I'm gathering here, it seems like C-A-B is actually preventing
this from happening, so I'm more opposed to it than ever.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea?

[Thomas Jaeger]

John Moser wrote:
> On 2/12/09, Thomas Jaeger  wrote:
> 
>>> Things that can happen:
>>>
>>> * Client can grab keys but hang.
>> In that case, you get the X Server back to normal by killing the client
>> and you should try and fix the client.
> 
> Killing the client actually prevents X from having any input; you lose
> the input until you open a similar client (i.e. qemu) that regrabs,
> then close it normally so it releases.

This is not how grabs work.  If a client that has grabbed the
Keyboard/Pointer/Server is killed all grabs are automatically released.

>>> * Xorg/drivers can have a bug that locks the screen.
>> As I said before, I doubt C-A-B will help you there. Shift+SysRq+K
>> might, though.
> 
> Happens occasionally.  Shouldn't.  It breaks X clients' ability to
> talk to the screen, doesn't update the screen, so everything waiting
> on X hangs; but X still picks up the C-A-B somehow and dies.
Bug report?

> Computers will always do very strange thnigs, most of which don't make
> sense and shouldn't happen.
Those things can be fixed though.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea?

[Thomas Jaeger]

John Moser wrote:
>> This is not how grabs work.  If a client that has grabbed the
>> Keyboard/Pointer/Server is killed all grabs are automatically released.
>>
> 
> Try this when qemu freezes.  I've frequently had to C-A-F1, kill qemu,
> then alt-F7 back and ... wow, nothing works.  C-A-F1, DISPLAY=0:0 qemu,
> go back, hit a button, hit C-A to release grab, and close qemu. 
> Repeatably.

I don't know what qemu is nor what it does when it claims do a "grab".
But regular X grabs behave the way I described above.  If they aren't
released when the connection closes chances are something else is going
on.  I know this is getting old, but you don't happen to have a link to
a bug report where this is discussed?

>> Bug report?
>>
>>> Computers will always do very strange thnigs, most of which don't make
>>> sense and shouldn't happen.
>> Those things can be fixed though.
>>
> 
> Yes, exactly.  Just don't be surprised if someone says something happens
> that shouldn't.

No.  What surprises me is when people are fine with those bugs as long
as there is a quick way to kill the X server that is enabled by default.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? - no.

[Thomas Jaeger]

This is not a healthy discussion.  We have people claiming that they
can't live without C-A-B, yet they're unable to come up with any
*concrete* situations where they need it.  I don't doubt that these
issues exist, but my guess is that in most of those cases, C-A-B is the
wrong way to go about it.  To make any progress here, we need more data,
it's as simple as that.  Otherwise it's impossible to make any sort of
generalizations as to why these situations happen.  For example, if it
turned out that most of those lock-ups are due to grabs gone awry, it
wouldn't be top difficult to implement and advertise a Release-All-Grabs
key, that would take care of the issue without the need for killing X.

Mike Jones wrote:
> Hi Thomas,
> 
> I'm one of those users who would prefer that the C-A-B command be left
> as it is, or be modified to allow the ability through some other interface:
> such as twice successive.
> 
> I have filed several bug reports about issues related to problems with
> X, https://bugs.launchpad.net/bugs/289898 for example.
This is a kernel bug.  I would be very surprised if C-A-B worked here.

> No.  What surprises me is when people are fine with those bugs as
> long
> as there is a quick way to kill the X server that is enabled by default.
> 
> 
>  People do file bugs. Perhaps not everyone, and perhaps not every time.
Well, then it shouldn't be too difficult to come up with a few bug
reports to give others an idea of what's going on here.

> But the problem is still going to be there for that person from when they
> originally filed the bug until the problem has been tracked down, until a
> fix has been written, until its been tested to not break anything, until its
> been patched to the package, until the package as been released, and finally
> the package has been downloaded (and in the case of things like the kernal,
> and graphics support) until the computer (or X) has been restarted.
This is why we need to figure out if there's some sort of pattern behind
the problems people are seeing.

> Once I submit a bug report about this issue, Can you give me a guarentee
> that I will have an update sitting on my system within an amount of time
> that make it reasonable to not have C-A-B immediately available to me?
If you really think you need it, it's really not that hard to enable it.
 Most people won't need it, so why should it be enabled by default?

By the way, nobody will guarantee you anything unless you're willing to
pay money.


> Realistically, C-A-B is useful to the points that I personally feel it
> to be necessary to my computing on a day to day basis.
Then enable it.  Most people would probably call such a system unusable
either way.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? - no.

[Thomas Jaeger]

Remco wrote:
> Every program that hangs but doesn't release grabs is a problem. You
> could certainly implement some kind of solution to that, but only
> after that solution is implemented, C-A-B or equivalents should be
> disabled. Not before.
I know that this is possible, but the question is how common this
situation is.

> Every program that makes the system so slow that it becomes unusable
> is a problem. This can't be solved. Any buggy program can take so much
> CPU/RAM/IO that your mouse pointer moves only every 10 seconds and
> your key presses only register after that same time. Only a simple key
> press that kills the program can solve this. Or a hard reset. We
> shouldn't remove the reset button functionality either.
If an application is hogging resources, you'll want to kill that
application, not X.

> This means that C-A-B or equivalents can never be disabled.
I think should be pretty clear by now that they can :)

> Concrete examples: Windows games run in Wine. Some will leak memory or
> whatever. You can't file bug reports against those games. And even if
> you could, you would still experience the problem until it was solved.
Okay, now we're getting closer.  There's no reason you can't make wine
handle those situations more gracefully.  But really, if you're doing
highly experimental things like running windows games in wine, it's not
unreasonable to expect that you do the tiny amount of extra of work if
you want enable C-A-B.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? - no.

[Thomas Jaeger]

Martin Pitt wrote:
> Thomas Jaeger [2009-02-12 17:16 -0500]:
>> This is not a healthy discussion.  We have people claiming that they
>> can't live without C-A-B
> 
> Nobody stops them from re-enabling it (to the contrary, there's a new
> tool "dontzap" which makes this very easy). Please keep in mind that
> we aren't discussing taking this away entirely, just changing the
> default.
This misses the point, though.  What has surfaced here, and I think
needs addressing is that C-A-B is not just used as a convenient way of
restarting the X server after recompiling it, but it's actually used as
a general-purpose something's-not-working-so-let's-kill-X key (this
might have been clear to you, but it actually surprised me).  This might
work for some people, but I find this a completely unacceptable solution
and I think we need to get to the bottom of those issues.

One thing that has been mentioned is how a process that requests an
infinite amount of memory can completely trash the system.  This is
definitely something we can get out of this discussion.  I'm not
familiar enough with what the kernel does, but I'm sure we could find
some more desktop-oriented kernel options that alleviate the problem
(deny requests for new memory earlier when we're low on memory, set a
hard limit on how much memory a process can request, maybe even a key
combination that kills the application that is currently using the most
memory).  I'm sure these kinds of issues have been discussed upstream
before.

> Also, please be aware of the fact that this is a *developer* list,
> who naturally has a differnent and more expert-oriented approach to
> using a system.
Yeah, this is why I thought I could get good descriptions of what
problems people are running into, but I guess they just don't care as
long as there's a quick way to zap X.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? - no.

[Thomas Jaeger]

Matthew Paul Thomas wrote:
> Remco wrote on 12/02/09 22:33:
>> Every program that hangs but doesn't release grabs is a problem. You
>> could certainly implement some kind of solution to that, but only
>> after that solution is implemented, C-A-B or equivalents should be
>> disabled. Not before.
> 
> The fact is, many things are easier to fix afterwards.
> Particularly because that's the only time you'll find people
> motivated enough to bother about it. If you were to need to fix
> everything before-the-fact, nothing fundamental would ever get
> fixed, simply because the people who can fix one thing are not
> usually the same people who can fix another.
> 
>  -- Linus Torvalds 

So true.  This is off-topic, but we've had the problem in bug 217908 [1]
for almost a year now, simply because the cairo folks are to nice to
expose bugs in the drivers.  And no surprises here, even after sending
patches to the upstream driver projects, three of them still haven't
fixed the issue.

[1] https://bugs.launchpad.net/ubuntu/+bug/217908

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? - no.

[Thomas Jaeger]

Mike Jones wrote:
> It is unreasonable to expect even users who have programing experience to
> use the terminal for honestly much more than occasional scripts. I have
> absolutely no desire to C-A-F#, find the program that is giving me fits, and
> then kill it in the hopes it fixes my issue.
In order to fix bugs, we need people that are able and willing to track
down the issues.

> 
> 
>> I'm one of those users who would prefer that the C-A-B command be left
>> as it is, or be modified to allow the ability through some other
> interface:
>> such as twice successive.
>>
>> I have filed several bug reports about issues related to problems with
>> X, https://bugs.launchpad.net/bugs/289898 for example.
> This is a kernel bug.  I would be very surprised if C-A-B worked here.
> 
> 
> C-A-B does not work in that instance, you are correct. But since you seem to
> know so much about it, could you please provide a fix for me? I have been
> unable to figure out anything beyond what I reported already.
There's no useful information in that bug report.  What you need is a
dmesg from after the bug has happened if possible, or a backtrace if
it's a kernel panic (flashing leds).

See https://wiki.ubuntu.com/KernelTeamBugPolicies#Capturing%20OOPs and
https://help.ubuntu.com/community/DebuggingSystemCrash .  You'll
probably need to forward the bug upstream once you've gathered the
necessary information, it doesn't look like anybody's working on it.

>> But the problem is still going to be there for that person from when they
>> originally filed the bug until the problem has been tracked down, until a
>> fix has been written, until its been tested to not break anything, until
> its
>> been patched to the package, until the package as been released, and
> finally
>> the package has been downloaded (and in the case of things like the
> kernal,
>> and graphics support) until the computer (or X) has been restarted.
> This is why we need to figure out if there's some sort of pattern behind
> the problems people are seeing.
> 
> I agree with John Moser. Allow the user to go back to work, and
> automatically file a bug report using the apport interface. I assume thats
> why apport exists, to catch crashes and report them when possible.
> Otherwise... why does it pop up on my screen whenever a program crashes..?

Except that apparently most of the issues that people are solving with
C-A-B have nothing to do with the X server.

> Thomas, do you mind if I ask why you seem so adamant that C-A-B stay
> disabled? If we change it to A-S-K the accidental activation problem has a
> (in my opinion much) lower risk, but the workaround still exists for when
> people need it to. Would changing to A-S-K be acceptable to you? Or is there
> another underlying issue?

A-S-K has always been there for people that need to do kernel debugging.
Nobody else should ever have to deal with it and neither should we rely
on C-A-B.  It's just a bad way of dealing with problems.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fake login screens

[Thomas Jaeger]

Vincenzo Ciancia wrote:
> However, it seems to me that nobody is getting the point about fake 
> login screens: if I am an *user* of somebody else's network, how can I 
> protect myself from another *user* faking a login screen, used as the 
> only running X application, and stealing my password?

C-A-B offers no protection against this attack, as users can easily
remap keys.  If you don't believe me, run

xmodmap -e 'keycode 22 = '

and then try killing the X server using C-A-B.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Accessibility issues in the new theme

[Thomas Jaeger]

Hi,

I'm not sure how to get the theme developers' attention, so I'll try
this mailing list.  I feel that the new theme is a step backwards in
terms of accessibility, making ubuntu harder to use for people with
less-than-perfect eye sight, user of high-resolution screens and people
who use their laptop in adverse lighting conditions (e.g. sunlight).

There are two main issues with that I have with the current design of
the theme.  The first issue is the size of window decorations.  When
increasing the size of the title bar font (or the dpi settings), the
window decorations don't scale up accordingly [1].  This makes it
unnecessarily hard to hit the close, minimize or maximize button and
increases the chances of hitting the wrong one.  This is exacerbated by
the fact that there is no visual indication of whether the close button
is currently pushed down.  The rationale for this is supposed to be that
metacity doesn't support scaling buttons, but I found this not to be
true in my own testing (see [1]).

The second issue is contrast:  It just doesn't make any sense to me why
text should be gray-on-white instead of black-on-white.  Having less
contrast means you have to crank up display brightness while on battery,
wasting precious battery life or causing more eye strain.  It is quite
shocking to me how much clearer text on the screen becomes if I adjust
the colors so that text appears black.  This might not be much of a
concern on current monitors, which don't have to sacrifice backlight
brightness for power consumption, but it is on most laptops.

Thanks,
Tom

[1] https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/532641

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Accessibility issues in the new theme

[Thomas Jaeger]

Kenneth,

Could you please address the issues that have been raised in bug
#532641?  As far as I can tell, there are no technical reasons for
keeping the window controls at a fixed size.

Thanks,
Tom

On 04/05/2010 04:40 PM, Thomas Jaeger wrote:
> Hi,
> 
> I'm not sure how to get the theme developers' attention, so I'll try
> this mailing list.  I feel that the new theme is a step backwards in
> terms of accessibility, making ubuntu harder to use for people with
> less-than-perfect eye sight, user of high-resolution screens and people
> who use their laptop in adverse lighting conditions (e.g. sunlight).
> 
> There are two main issues with that I have with the current design of
> the theme.  The first issue is the size of window decorations.  When
> increasing the size of the title bar font (or the dpi settings), the
> window decorations don't scale up accordingly [1].  This makes it
> unnecessarily hard to hit the close, minimize or maximize button and
> increases the chances of hitting the wrong one.  This is exacerbated by
> the fact that there is no visual indication of whether the close button
> is currently pushed down.  The rationale for this is supposed to be that
> metacity doesn't support scaling buttons, but I found this not to be
> true in my own testing (see [1]).
> 
> The second issue is contrast:  It just doesn't make any sense to me why
> text should be gray-on-white instead of black-on-white.  Having less
> contrast means you have to crank up display brightness while on battery,
> wasting precious battery life or causing more eye strain.  It is quite
> shocking to me how much clearer text on the screen becomes if I adjust
> the colors so that text appears black.  This might not be much of a
> concern on current monitors, which don't have to sacrifice backlight
> brightness for power consumption, but it is on most laptops.
> 
> Thanks,
> Tom
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/532641


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss