Timeline for OBSOLETE - soapi-notify : Stay ahead of the pack with new question notification V1 release
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 18, 2020 at 8:33 | history | edited | CommunityBot |
Commonmark migration
|
|
| Aug 25, 2015 at 6:23 | history | edited | Brock Adams | CC BY-SA 3.0 |
Replace bad ImageShack images per http://meta.stackexchange.com/q/263771/
|
| Jun 30, 2010 at 10:05 | comment | added | Steffen Opel | @code poet - the display installation solution doesn't seem to be quite right yet, the app crashed with an exception Cannot install or update displays while growl is running. The workaround of installing the display first is obvious and did work out fine, but this user experience flaw will likely hinder mass adoption of this otherwise already pretty slick and useful proof of concept ;) | |
| Jun 24, 2010 at 12:45 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 1261 characters in body
|
| Jun 23, 2010 at 18:39 | comment | added | Sky Sanders |
@brian - thanks for that. I don't see a need for an installer, really. It is a console app. What I intend to do is embed the display binaries in the executable and when it is run with -g, simply use Detector to probe for the existence of the proper versions of the display and then, if necessary, stream them out to the proper location. This will allow me to ensure that the displays are synced with the exe. This is pretty important, especially in alpha/beta as I move relatively fast and need to maintain the user experience with the least possible amount of pain.
|
|
| Jun 23, 2010 at 16:12 | comment | added | Anonymous | if your app is going to have an installer anyway and the display is tailored specifically for use with your app, then including the display in the app's installer definitely makes the most sense. alternatively, you can set up the display to use the one-click web install (similar to other displays on the GfW website) so that end users can just click a link and the display will be installed in the right place automatically. if you want more info on that route, post in the GfW discussion groups and i can provide more detailed instructions: groups.google.com/group/growl-for-windows?hl=en | |
| Jun 23, 2010 at 10:42 | comment | added | Sky Sanders | @brian- thanks for your help. It makes perfect sense and I have a more economical update pattern in place and a much slimmer display deployement. In a case such as this where the display is specifically tooled for my app, does it make sense to simply embed the display assemblies and deploy/update from the app itself? | |
| Jun 23, 2010 at 2:04 | comment | added | Sky Sanders | @brian Ahh - i see. I had it backerds. Growl does not handle coalesce, the display does. that makes more sense from every angle. for some reason, i assumed that if i sent the connector a cid that it would find and update the appropriate box. silly me. thanks for the hint. that will allow me to remove a lot of bits from the display and make more efficient calls to the api. I will try to chronicle my foray into building a display in a blog post or two and let you know. | |
| Jun 23, 2010 at 1:37 | comment | added | Anonymous | exactly - see this file, line 65 or so: code.google.com/p/growl-for-windows/source/browse/trunk/… the ActiveWindows property will contain a list of open notifications that you can use (as long as you opened them using the Display class' Show() method). then it is just a matter of checking the CoalescingGroup (which also takes into account the sending application do you dont accidently update another app's notifications if your CoalescingIDs collide). | |
| Jun 23, 2010 at 1:14 | comment | added | Sky Sanders | @brian - hey. good work on growl. I see the meter source but no example of using it. I can understand how pushing data to an existing notification using a key would work and this would be the best strategy in that I could batch the update requests to the API instead of the current implementation that involves each instance of the display polling for itself. My question is how to track which notifications are still open. I assume that I would simply maintain a local registry of notifications as I open them and then respond to a callback in order to remove them from the update list. | |
| Jun 23, 2010 at 1:04 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 2161 characters in body
|
| Jun 22, 2010 at 20:45 | comment | added | Anonymous | i am the developer of Growl for Windows so i thought i would chime in. you actually can update an existing on-screen display with new data if you want. (few of the built-in or additional displays use this feature though so it is poorly documented). the trick is to set the CoalescingID property on the Notification object you send to GfW. in your custom display, you can use that value to associate existing notifications with the new one and update appropriate. see the 'Meter' display for an example (code.google.com/p/growl-for-windows/source/browse#svn/trunk/… Extras/MeterDisplay) | |
| Jun 22, 2010 at 11:22 | comment | added | Sky Sanders | @radius - r.e. updates on notifications: there is no mechanism in place for that sort of bi-directional communication. the feedback loop is pretty simple, as it should be. Refresh would have to be built into the display. Hey, i know someone who is building a custom display, maybe he can create them to update themselves? let me ask.... self, could you add update ability to the stack exchange display? sure, self, I could do that. Hey, he says he can do it. but not for mac. they are fairly simple to build, perhaps once i get mine built as an example we can recruit someone to write one for mac | |
| Jun 22, 2010 at 11:20 | comment | added | Sky Sanders | @radius - i see your point r.e. metrics. i think it would be unnecessary complexity to optionalize it. I am just going to put them back in. thanks for the perspective. | |
| Jun 22, 2010 at 10:22 | comment | added | radius | In my case, I configure growl to keep notification sticky when idle. In this case it would be great to be able to refresh notification data (vote/answer count) (growl for mac can't do that, I don't know for windows). I think I will work to a better console output in senotify, to be able to always diplay : Question get by last refresh + N older question with still no answer | |
| Jun 22, 2010 at 10:16 | comment | added | radius | I don't fully agree with you on "Vote, Answer count". It's useless if refresh rate is high, with a refresh rate of 5 minutes like the default in senotify value can be interesting. May be the display can be an option. | |
| Jun 22, 2010 at 9:12 | history | answered | Sky Sanders | CC BY-SA 2.5 |