Redesign the framework

[GoogleCodeExporter]

What feature or enhancement do you propose?
The Growl SDK is old, and has many challenges for improving it, and expanding 
how it can function.  Our "singleton" is actually just a bunch of statics, and 
thats really poor design.  We have no good way to add functionality without 
adding new functions as expanding old ones is dangerous for developers and 
users who are occasionally encouraged to try upgrading a framework.  These 
functions keep adding up, and can't overcome certain shortcomings in the 
design.  

What problem does it solve/What benefit does it provide?
A new framework, based around a proper singleton would allow us to fix many of 
the issues that developers have reported about our framework, allow us to 
remove cruft, and allow us to architect it to allow the easier addition of 
features.  

Features such as, no need for a full delegate.  Our delegate requirement to 
even register is very ugly for certain developers.  Being able to initialize 
the singleton and give it a registration dictionary once should be sufficient.
Ability to have a block that gets evaluated on result from a notification 
(error, clicked, closed, timed out, etc), allowing any part of an application 
to notify, and have the result evaluated in that part's context rather than 
having to go through the central growl delegate (This would make part of 
HWGrowler easier, so that it didn't have to flag what part of the app to return 
the context to)

This is no small undertaking, and we need to consider whether we should be 
doing this at all, and if so are we starting fresh, or if we are going to try 
and maintain API backwards compatibility (but flag all the old stuff as 
deprecated)

This ticket can serve as a discussion point, and a meta ticket for any 
subsequent tickets that need to be created to cover this should we decide to do 
this.  

Original issue reported on code.google.com by dan...@growl.info on 28 Apr 2013 at 9:10

• Blocked on: #473

[GoogleCodeExporter]

While I am flagging this as started in the Growl.framework-3.0 branch, it is 
still very much a WIP.

Some notes about what I have done so far.
The 'singleton' has been turned into a real singleton instead of a bunch of 
statics nightmare mess.
The API so far has been untouched.
A new class, GrowlNote is what actually holds onto it's attempts, and is where 
all new API should be placed, new delegate methods, new init methods.
One new API has been added to the main API, -notifyWithNote: which takes a 
GrowlNote

GrowlNote can have it's own delegate or callback blocks set.
Life cycle of a GrowlNote is unfinished, for now when we get back from GNTP 
that we are finished with the note, it removes our reference to the note.  This 
does not however cover the case of a sticky NSUserNotification, and possibly 
other cases.
It generates a UUID on init, and GAB holds on to them by that, so removing by 
UUID will be easy enough

Registration is a bit of a mess.  The old methods (and there were a lot of 
them) have had to be rewritten to allow for a lack of delegate and manually set 
registration dict, and I am unsure if this has been completed properly yet.
We no longer retain our delegate, but this might cause issues in some apps.
API wise we shouldn't crash, but there might be some edge cases that have crept 
in for a rare implementation.

Original comment by dan...@growl.info on 16 May 2013 at 3:49

• Changed state: Started

[GoogleCodeExporter]

This is continuing to progress, GrowlNote is getting fleshed out, and now 
supports a number of things that Growl could have been reporting on, but 
wasn't, such as note closed (by the close button), and note not displayed.  
These are sent back both via GNTP and via NSDNC.

NSDNC is going to hopefully fix the click after socket close issue, by sending 
a note UUID and clicked/closed/timedout/notdisplayed/etc back over NSDNC (but 
not using any payload)

Adding blocked on 473

Original comment by dan...@growl.info on 25 May 2013 at 10:55

• Now blocked on: #473

[GoogleCodeExporter]

The roots of this are done now, for better or for worse, additional work can be 
created as new tickets on the new framework.  I am flagging this particular 
issue as FixedInSource

Original comment by dan...@growl.info on 18 Jun 2013 at 9:40

• Changed state: FixedInSource