it should be possible to maximize any window using (using F8)

this one isn't compiz, it is gnome-control-center

Correction to Alan above - I am advised that it affects all system specific and brand related windows from Live-cd start through to a completed installation and it's a compiz matter.

I'm no expert - just taking what the experts say and reporting it as advised against the packages identified - not the content of the window affected. !

The Bug has multiple impacts at multiple locations across the OS - and not just one window "control center".

It isn't compiz. Compiz is the compositing window manager that puts all the windows on the screen. Each gnome application will create one or more GTK windows and by default the resizeable property is set to true, gnome-control-center sets it's resizeable property to false because it sizes itself according to it's content rather than allowing the user to resize it.
http://developer.gnome.org/pygtk/2.22/class-gtkwindow.html#method-gtkwindow--set-resizable
Gnome-control-centre has many panes, the appearance pane is just one of them, you will see the window resize itself as you move between them. Ubiquity the installer also probably demands to set it's own dimensions, which is particularly annoying on the map page, but that is two separate issues, one in gnome-control-centre and one in ubiquity. Neither are a compiz issue, it is just doing what the applications ask it to do.

Ah - so as I thought it is now a single default setting or a system wide setting that needs to be changed - it's multiple windows- apps. It goes right back to design and branding!

A Better reason for a Standard System Wide Accessibility Policy I have never seen confirmed so quickly.

That policy need to inform all action from design and branding through to coding - so that if there are multiple critical windows - they can be identified, logged, checked and made to comply with accessibility standards.

That of course would be the function of the Accessibility Guardian - watch - catch and if necessary bite hard!

"Ubiquity the installer also probably demands to set it's own dimensions, which is particularly annoying on the map page, but that is two separate issues, one in gnome-control-centre and one in ubiquity."

It's not two separate issues - It is two bugs - with one common cause!

If accessibility was being taken seriously there would be no cause for the bugs! P^)

I believe that the bug report is about compiz. The problem being that the window manager should permit *any* window to be maximized via a key combination regardless of wether the window has maximize/restore buttons. This is, therefore, a system wide facet of compiz.

The fact that gnome-control-center uses a fixed geometry and that the content doesn't layout correctly on label increase are known

see bug #936257 "the system settings grid shouldn't use a fixed geometry "
bug #819994 "String length of items seems limited (system settings label get truncated)"

So it would seem that it could be Compiz - or Single application windows or Both - and maybe "Yet More"!

I suspect the "Yet More" is the reality.

As I said Above "A Better reason for a Standard System Wide Accessibility Policy I have never seen confirmed so quickly.

That policy need to inform all action from design and branding through to coding - so that if there are multiple critical windows - they can be identified, logged, checked and made to comply with accessibility standards."

NOTE - what I have written in the second paragraph places the focus upon the "Window" and on the desktop - which is where the user experiences the "Impairment" of inaccessibility - The Virtual Staircase. Code below that, and design issues are of lesser relevance and importance - and the steps to resolve them should ensure that all elements of the Virtual Staircase are removed. A single stair tread left hanging in mid air is a hazard to all concerned and not just the user who suffers Impairment.

So, if one part of the issue is in Compiz it may get resolved - but individuals with responsibility else where may not know about it and then refix what they see as a change they don't know about !

The change in basic accessibility standards has the air of a Root Cause about it - and until that root cause is located, addressed and fixed, it may well recur. I suspect that the Root Cause comes from Design Philosophy and branding and is only them made manifest in code which leaves basic accessibility features inaccessible and people impaired.

Is this a design bug - workflow bug, Not just a Coding Bug? A Design Policy Bug?

Some may say that the Bug Tracker is not the place to raise that issue - But I do believe it is. There is no other rational place to have the matter on the record - and even as a learning venue.

For some bug tracking is about Burrowing Down into code - but it also has to allow Burrowing UP to bigger issues too - else the Bug Tracker simply functions to fix poor practices, decisions and outcomes (so often not intended and unforseen) and embedding the negative across the platform and further a field long term. It also prevents people from using the reports to learn in the widest sense about users and outcomes.

If some wish to call it ranting or improper use of the bug tracker - they can have their opinion. Here in the bug tracker it does allow for the complexity of issues across multiple packages - teams - groups to be highlighted and possibly linked.

Discuss it else where is a cry - go blog else where - and discussion which uses the actual bugs is better, as it does allow those who need worked examples and not just abstract philosophy to utilise real world examples as their learning tool. Some may only be interested in patches - but some do have the capacity to elevate above basic patches to see wider code issues - wider practice issues - so why should they be denied the opportunity to do that?

If there are issues which are not simply code related but have a wider implication across multiple work flows ( some where coding is not even a factor ) It may be best for a suitable Tag to be developed for Bug Tracker. "Multi-Discipline" or "Phi...

I'm confused. Standard practice for maximizing windows has been shifted to <super>+up. As stated in the bug description, a replacement is adequate. Does this not replace the previous combination?