Enable close button styling with webkit.

[GoogleCodeExporter]

What feature or enhancement do you propose?
Enable close button styling with webkit.

What problem does it solve/What benefit does it provide?
The default button looks good, but it doesn't fit with all styles.
It's a look widely used on web applications but definitely doesn't feel native 
in Lion

Original issue reported on code.google.com by aristide...@gmail.com on 24 Aug 2011 at 10:01

[GoogleCodeExporter]

I disagree that it doesn't look native in lion since the dashboard in lion uses 
the same thing. Some people want to theme the close button, but what would you 
want to do? Change colors or what?

Original comment by ch...@growl.info on 28 Sep 2011 at 7:21

• Changed state: WaitingOnUser
• Added labels: Milestone-Later

[GoogleCodeExporter]

I would like to reproduce the quickview close button.

These theme (screenshots missing) is almost like it: 
https://github.com/aristidesfl/Lion.growlStyle
The only things missing are the blur and the close button

Original comment by aristide...@gmail.com on 29 Sep 2011 at 2:46

[GoogleCodeExporter]

The problem is that then the close buttons do not look uniform across multiple 
notifications. I'm really having a hard time with how this would work in my 
head. It's one thing for notifications to look different, but actual user 
interaction changes slightly here and I don't know that I'm comfortable with 
that.

Original comment by ch...@growl.info on 29 Sep 2011 at 2:51

[GoogleCodeExporter]

If you use a different style for each application I guess I agree with you, it 
can make sense the button to be the same. Nevertheless, no one makes you use 
themes with different buttons.

On the other hand, someone like me, uses only one style for everything. Even if 
you use 2/3 styles it's ok to have different buttons.

After all, you are only changing the looks of the button, just like the looks 
of the bezel. if the button is in the same place, the interaction model stays 
the same.

Original comment by aristide...@gmail.com on 29 Sep 2011 at 3:09

[GoogleCodeExporter]

we'll think about it, its not going to be decided soon.

Original comment by rarich...@gmail.com on 29 Sep 2011 at 4:31

[GoogleCodeExporter]

You only really need to add an option to make it transparent.

Thant would make me happy :)

Original comment by aristide...@gmail.com on 29 Sep 2011 at 1:07

[GoogleCodeExporter]

I really don't know if we should do that even. The UI element works and we get 
no complaints about it. We're going to have to have an in person conversation 
about this and that's going to be a while before we have one (we being the 
people who work on Growl).

Original comment by ch...@growl.info on 29 Sep 2011 at 4:26

[GoogleCodeExporter]

Original comment by ch...@growl.info on 29 Sep 2011 at 4:26

• Changed state: InDiscussion

[GoogleCodeExporter]

Providing the ability to make the close button transparent would be bad. Then 
you have (a) one portion of the window that reacts differently to clicks for no 
clear reason, and (b) no clear way to close the window with no side-effects 
(because it's hidden).

Providing the ability to suppress the close button would solve problem a but 
not problem b.

Providing the ability to style the close button risks problem b, in the form of 
camouflage. A style author who hates the close button might well style it to 
look like whatever's behind it. (How would you make it stylable without 
providing the ability to make it transparent or make it look like the 
background? It's not possible.)

The standard close button is a virtue. No matter what style the user uses, they 
always have a visible way to close the window with no side-effects, and they 
can always recognize it because it has a standard, consistent appearance.

Original comment by boredzo on 29 Sep 2011 at 9:33

[GoogleCodeExporter]

Thinking about it some more: Allowing styling *could* work, but only if the 
styles list shows the style with and without the close button, side-by-side, so 
users can know what the close button will look like. This would also provide an 
opportunity for whoever adds the style to the list to verify that it shows a 
close button and doesn't suppress, hide, or camouflage it.

Original comment by boredzo on 29 Sep 2011 at 9:40

[GoogleCodeExporter]

The point on making it transparent is not to hide the button. Just to be able 
to create a new button behind the real one without having to style it (for the 
sake of implementation easiness but that's up to you ).

I think the current button is the best for most of the message styles and there 
is no reason it should change, even if there is an option to do it.

On the other hand, I want to have a style which looks like the Lion's quick 
view bezel, but I currently cannot.

Original comment by aristide...@gmail.com on 30 Sep 2011 at 1:59

[GoogleCodeExporter]

We're not going to give people a way to go around our decisions about usability 
like you suggest. If we come to the conclusion upon discussion on this is that 
it's a usability issue, then what you suggest is a very bad idea.

I can understand your position that you would like to change the look of it. 
But you need to understand the bigger problem we're really concerned about here 
with regards to how users actually use Growl. Webkit styles are one thing, but 
we have to make sure that Growl remains cohesive, which is my *main* concern. 
Styling the close buttons, or anything else along that vein, really seems like 
it does more harm to the majority and good for the minority. But when we have a 
meeting in person, we'll discuss this before drawing any final conclusions.

Original comment by ch...@growl.info on 30 Sep 2011 at 2:43

[GoogleCodeExporter]

The intention behind wanting to have a consistent close button across themes is 
understandable, but, I really think it's behind overdone.
It's not like it is a 20 button complex interface..
Also in some cases the argument in not even valid: I use always the same style 
so I would have always the same close button anyways.

I think the benefits in aesthetics are big enough to be worth the possible 
decrease of usability (which I don't see because the interface is really 
minimalistic).

Original comment by aristide...@gmail.com on 30 Sep 2011 at 3:26

[GoogleCodeExporter]

We have to consider all use cases, not just some use cases. Aesthetics, while 
nice, are not the only component to any software application. If we make a 
change, we have to think it through and think through the ramifications to make 
sure that it's good for the majority of the user base. 

I agree, yes, in your use case that a different kind of close button may be a 
fine idea. However, what if it were just as simple as just changing the close 
button so that more people are happy with it? That's:

- simpler to do
- provides one less option than what you are currently advocating
- solves the bigger problem if it's simply aesthetics

However, I keep looking to Apple to provide us UI and UX thought wherever 
possible, since they have the larger user base. The one bit of OS X that seems 
to be the best place to look at, Dashboard, continues to use what we use. That 
doesn't mean it's the best case for Growl, but it does mean that people who use 
OS X already know what a close button looks like in other places. A customized 
close button that looks different requires a bit of thinking, or a lot of it 
depending on how radically changed the close button is.

I do not want to add another preference just for a close button. It just seems 
like a solution looking for a problem. Rather, if the close button is ugly 
let's just make it nice for *everyone* if at all possible. If that's the real 
issue, let's fix that, rather than trying to work around it in some other 
fashion.

You want to theme the close button across the board on your system, but if it's 
really good looking it may be better to just implement it across the board.

Also, a note, Snarl has custom close buttons, per one of the developers of that 
application emailing me directly. They do have this option (which I can't find 
in my install, yay) and I need to play with it in order to ascertain the 
benefit of this over other thoughts on it.

In all reality the close button for Growl has been like this since it was 
introduced, and only recently has it become something which people want to 
change. Whether that's just because it needs a fresh coat of paint, or 
something else, we need to determine before taking any action either way.

Original comment by ch...@growl.info on 30 Sep 2011 at 6:43

[GoogleCodeExporter]

Lion's Mission Control uses the same close button on spaces/desktops, so 
apparently Apple still think it has legs.

Besides aesthetics, there are two other components to consider:

- Recognizability. Consistency with Apple's design is one approach to this, but 
not the only one. One way or another, it must look like a close button; the 
user must know what it is and what it does on sight.
- Prominence. It must be visible and noticeable against the style's background, 
and it must be clear that it's clickable. Otherwise, the user may not know what 
it does (failing recognizability) or not even see or notice it at all.

Original comment by boredzo on 30 Sep 2011 at 1:02

[GoogleCodeExporter]

I think it's clear that there is nothing wrong with the current button. It's 
the best generic button it could be. 

Apple uses it in a lot of places, but not in quick view bezels, because it 
looks better and is prominent enough, and apparently people are smart enough to 
recognize it, despite everything. 

I have a quick view bezel imitation and I would like it to be cohesive with the 
real one. Currently I can't.

Perhaps you can add an option which enables customized versions of the button.. 

Original comment by aristide...@gmail.com on 30 Sep 2011 at 1:41

[GoogleCodeExporter]

We'll have to think on this. Thanks for your feedback. 

Original comment by ch...@growl.info on 30 Sep 2011 at 4:45

[GoogleCodeExporter]

Original comment by ch...@growl.info on 13 Nov 2011 at 11:56

• Added labels: Milestone-1.5, Product-Growl
• Removed labels: Milestone-Later

[GoogleCodeExporter]

See 
http://groups.google.com/group/growldiscuss/browse_thread/thread/89cd80300810b72
1 for more discussion on this. Targeting for 1.5 for now (1.4 is already full).

Original comment by ch...@growl.info on 13 Nov 2011 at 11:58

• Changed state: New

[GoogleCodeExporter]

Original comment by ch...@growl.info on 19 Jan 2012 at 10:45

• Added labels: Milestone-2.0

[GoogleCodeExporter]

We need to narrow the scope of Growl 2. Moving to the 2.1 milestone.

Original comment by ch...@growl.info on 18 Jul 2012 at 5:18

• Added labels: Milestone-2.1
• Removed labels: Milestone-2.0

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

One of the advantages of growl over OS X notifications is customization of 
styles.

Original comment by aristide...@gmail.com on 18 Jul 2012 at 6:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sure is, which is why this was simply moved to 2.1. It may even get pushed to 
another release after that. We couldn't have anticipated needing to rewrite the 
networking stack to address a CPU issue, taking resources away from new 
features like this. Thanks for your comment. :)

Original comment by ch...@growl.info on 18 Jul 2012 at 9:49

[GoogleCodeExporter]

So, Growl 2.1 has facilities for doing custom images for normal and pressed by 
an Info.plist key, and ability to set an x/y offset in the Info.plist as well.  
Flagging as fixed in source, although there are likely some kinks that will 
need to be worked out when it goes into testing.  We will likely be looking for 
designers interested in playing with this feature when we start the 2.1 beta 
(And no, I don't really know when that will be right now).  

Flagging as fixed in source, if individual issues arise with the new feature, 
they will be dealt with separately.  

Original comment by dan...@growl.info on 30 Oct 2012 at 3:27

• Changed state: FixedInSource

[GoogleCodeExporter]

So, as a heads up to anyone following this:
http://growl.posterous.com/growl-21-and-webkit-styles
Additionally, since I flagged as fixed in source, this has been further 
improved to allow webkit to fully customize the close button by disabling the 
cocoa button, and using a button in the style itself.  

Original comment by dan...@growl.info on 14 Nov 2012 at 3:28