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

[crippled user]

Ubuntu Precise Development Branch. 12.04

Further to Bug report #964685 - I am advised that the following behaviour is caused by Compiz.

1. Start live cd - click desktop to change background to suitable colour. Facility to maximise window using Alt F8 has is greyed out - needs to re restored to meet accessibility standards - and should be working in the beta. This accessibility feature is present in 10.04.4 through to 11.10 (verified today) - and should still be present in 12.04. It should not have been removed or deprecated under Gnome shell/3 or Unity - or for testing purposes.

Issue visible in screen print - attached.

Issue affects multiple windows from Boot of live CD and through Install process and in installed system.

Numerous people with visual and neurodiveristy disabilities need the ability to maximise these windows to allow concentration on single task with minimal image/background noise.

Window sizes may be presented inline with branding guidelines - but they should retain accessibility feature for those who need it and require it. It is acceptable for maximise option to be greyed out provided alternate Alt F8 is available. Presently basic accessibility standards compromised.

[Alan Bell (alanbell)]

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

[crippled user (saddharmap)]

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".

[Alan Bell (alanbell)]

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.

[crippled user (saddharmap)]

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^)

[Rick Spencer (rick-rickspencer3)]

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.

[Sebastien Bacher (seb128)]

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

[Sebastien Bacher (seb128)]

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)"

[crippled user (saddharmap)]

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...

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

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?