Ubuntu doesn't implement the metacity "shade" button

added other packages as, currently, the only metacity themes that implement the "shade" button are "crux" and "bright"

Whether or not this is implemented in a particular theme is really up to the designer. This should be marked "wishlist".

I don't agree. It's a feature of metacity and it's required to have a complete metacity theme. What will you think if a theme designer choose to not implement the "close" button because he uses "file > quit" in the menu ? It would be a bug in the theme !

The fact that this particular button is not in the default bar has nothing to do with our point (nobody can predict the future and it might one day be part of the default configuration).

I admit that this is low priority as few users might be impacted by this bug but it is still a bug, not a wishlist.

As a theme designer myself and speaking to other prominent designers, it's an option. If you look through GNOME-Look (best source of examples) the button is not implemented on the vast majority or themes. This is partially because the functionality can be duplicated if you set the title-bar to shade on double click. Making the button redundant.

"/apps/metacity/general/action_double_click_titlebar/toggle_shade" is the gconf key.

We obviously have a difference of opinion. I see this as a feature request. "Wishlist" Not a bug where something "needs fixed".

A decision was made not to use this specific functionality because similar, more familiar functionality already exists. I do not see this as a bug in any way, but as a wish.

C.Kontros > The double clic is not an option for everyone (some users have disabilities or hardware devices that make double clic painful). That's why I'm reporting this bug. (at first, I reported it as a bug against metacity where I was told that it was already implemented). It also makes the "shade" button feature of metacity completely useless : if no theme want to implement it, it will not work. Last but not least, double clic on the title bar is very "non discoverable" and it's a problem.

Also, I really don't understand how a theme make can impose this technical choice. The button displayed in the title bar are an user technical choice (configuration through gconf). The theme is choosen independantly because of user taste.

I'm an user interaction specialist and I'm exploring new paradigm with some test users. I noticed that this button is really well perceived by some users (elderlies, people with no previous computing experience) and is a lot easier than the minimize one (if you are interested by the details, you can contact me but it's outside of the scope of this bug I think).

I never did any theme for metacity (hopefully for your eyes ;-) ) but is it that hard to add this button ? I mean, I'm not asking for the prettiest stuff in live. I guess that just adding the same button as the minimize one with a 180° twist would be enough. But I admit that I have no idea about the amout of work required.

What I still think is that it should be regarded as a missing feature in a theme and thus as a bug. As an end user, if I configure my metacity to display the shade button (with gconf-editor but it could be with any gui tool), I want to see this button. If I don't see it, it would be a bug (just put yourself in the seat of someone who enable this button in metacity).

I am entirely capable and willing to provide a patch if the maintainers would accept one from me. (I mean, obviously they shouldn't accept my patch if they don't like it, but if they want to do the work themselves I won't do it, or if they've decided they don't want the button it would be rather pointless.)

Stick and Above aren't implemented either... should I fill another bug or we might add this buttons to this one?

It had already been decided to not implement this [comment #5]
Closing bug as wont fix.

I'm a bit sad because not answer has been made to my comment #6 and because someone even volunteered to provide a patch.

So, we have :
- A clear user request
- Someone volunteering to implement it
- No drawback at all (the change will only be noticeable in a positive way)

and, basically, someone else decided "no" without any explanation and we have to accept it. That's sad :-(

@ploum: not sure what you want explained , but it has already been mentioned that this is a design decision and that it wont be fixed.
Do you want to add a button for every option ? something similar to KDE? This seems a personal choice rather than an accessibility issue.
What is the problem for accessibility? There seems to be no basis for that 'complaint'. Accessibility issue faced by users affected by? Accessibility is a large blanket and just throwing in the word "accessibility" seems to be just for the sake of having a feature added.
Are there any real accessibility issues? why isnt this implemented in any theme ? Why is it not being requested by the accessibility team? Neither gnome nor the Ubuntu accessibility team have not brought up this issue for years? Why?

Also , Human theme is no longer the default theme. Nor is it installed by default.

Vish : yes, it is implemented in older theme (like crux). I don't know why it is not implemented anymore. The fact is that it is a feature offered by Metacity and that I don't understand why a theme might choose to not implement it "by design".

I totally understand the "send your patch" answer but, in this case, someone was willing to provide a patch and, by closing this bug, it is answered that a patch would not be accepted anyway. (and my guess that a patch from Thomas Thurman would be of very high quality).

Accessibility is, I agree, out of the scope. It was part of an experiment I was doing with users that lead me to discover that bug. I shouldn't have talked about that here. (This led me to conduct some experiments with older metacity themes like Crux, Gorilla, you know that kind of old stuffs, not really shiny)

And yes, you are right, it should be reported against the new default theme too.

Ubuntu has experimented putting the buttons on the other side of the window and I believe that implementing those buttons in new themes might maybe led to other experiments that might be useful (or not, but there's no way to know).

Don't get me wrong : this is not a major issue, I agree that is very low priority, I would not kill for it ;-)

I too would like to be able to use the full functionality of Metacity. I too don't understand why if someone was willing to make a patch, the patch would be denied.

The fact that there may be other ways to do something has rarely been a good argument against a ~particular~ way of doing something. I mean why have an indicator-session applet when I suppose I could just hit the power button on my laptop?

There are aspects about KDE that I don't like, so it would be nice to get some of KDE's functionality in Gnome. Maybe I am missing something, but wasn't the lack of configurability of Gnome relative to KDE one of the historical complaints about Gnome?

I don't know if some designers are just capricious, lazy, or what, but not fully implementing a spec sounds reminiscent of Internet Explorer 6, and downgrades masquerading as upgrades.

While it is not major, if someone is able and would be willing to patch it, your efforts would be appreciated by at least some of us who don't know how.

GNOME becomes less and less customizable over time, and still becomes more and more popular, because it never hit the line after which a missing feature renders the desktop unusable.
I think this bug should be re-targeted to Light themes now.

Just want to say the suggested "workaround" of double-click the titlebar is bogus.

Some of us prefer that action should result in MAXIMISE not SHADE.

Seriously is it so hard? Someone has already offered to do the work for you!

Seriously...

Every time I come here it's "won't fix" or "here's a workaround" or "not a bug" or some other lame excuse

Status changed to 'Confirmed' because the bug affects multiple users.

This bug may be a matter of design opinion (design may not want to ever show a shade button). So deferring the decision to design...