Now isn't this just so cool
I didn't get a chance to reply the day you sent it so please excuse the delay.
Thanks a lot for both your contribution (which I like a lot) and the "happy birthday" screen shot ... so cool
I've said this to you already, but I am impressed by the fact that you did this without asking a single question. Respect!
Besides, your code is very well written and you respect our coding and architecture conventions! Very good work!
Romain KUNTZ wrote:
As you know I am working on adding the Growl notification support (http://growl.info/) as a plugin for the MacOSX version of sip-communicator.
With the enclosed files, an user can be notified via a small window on top of the screen when he receives or send a message. This is very useful when you use multiple desktops, or to follow a discussion even if the chat window is hidden (screenshot: http://www.rkuntz.org/sipco/sip-comm-growl.png ).
I enclosed several files to get the basic support of this functionnality (instead of a big patch which may not be easy to read):
yes, thanks, that's how I prefer them too.
- growl.jar: a small library that needs to be put in lib/
done. I only needed to recompile it so that it is 1.4 compatible. Please try it and let me know if it doesn't work.
- build.xml-20061207.patch: a patch to apply to build.xml. It allows to not build the bundle if it is not compiled on MacOSX, and to get a correct classpath for the "compile" target if compilation is done on macosx (Be careful, this patch considers that the previous patch I sent about sip-communicator.version has been applied)
A couple of comments here. there's no point in performing all the classpath acrobatics. You can feel free to add /System/Library/Java directly to the project classpath since this won't disturb non-mac platforms (it would simply be ignored).
I've also modified your bundling target to produce the jar in sc-bundles/os/macosx, in order to avoid having it included in non-mac distros that are copying * from sc-bundles. I've also updated the macosx target to get the growlnotification.jar file from sc-bundles/os/macosx
- a felix.client.run.properties specific for MacOSX: it includes the plugin and the growl lib. It must be put in resources/install/macosx/
I think this could be a good temporary solution. For the long term, I think users should be able to add plugins via the sipco GUI, and then sipco could take care of changing the felix.properties file.
Indeed this is a bit risky since you'll have to modify this file every time we modify the main felix properties file. I completely agree with you that we should have this handled by a GUI plugin manager ... that we don't have yet.
Just an idea, until we get the plugin manager, wouldn't it be easier for you to keep in the macosx felix properties file only the line that starts the growlnotification bundle? In your mac specific properties file you could have a single line that looks like this:
and you could attach it to the end of the main felix.client.run.properties.
This should save you the effort of keeping a duplicate felix.client.run.properties up to date with the main one.
- growlnotification.tar.gz: Implementation of the service, which includes:
The GrowlNotificationService.java is almost empty, because I do not define any new functions (I only implements interfaces). So I wonder if this one is useful.
Indeed not really. We might one day consider something like a sysnotification service that other bundles could use to pop up important messages to users but for now I am keeping the service part outside.
Now some other details:
- I understood the principles of the slick, but I have no idea how I can implement a slick for this plugin. If you have any hints...
Good question ... it would be quite delicate to add consistent unit tests, not to mention running them on cruisecontrol since it is installer on a linux machine and growl is not available on it.
About the TODOs:
- Put the SIP communicator Icon as the default icon for the notifications (later, when SIP communicator will be able to get the people's avatar, we can display it instead in the notification window)
- Implement other notifications, such as when a contact becomes online or offline, when a call is received, a file transfer finished or aborted etc.
yes but that would also require adding a growl pane in the configuration window since users should have the possibility of specifying what kind of events would they like to receive notifications for.
- Do not display notifications for the contact whose chat window is active (and also if the user is on the same desktop as the chat window).
This one should be quite easy actually. It amounts to something like
if( ! uiService.getChatWindow(srcContact).isWindowVisible() )
(Yana would correct me if I am wrong but it should be something like
Anyways, I am committing with only a few minor modifications. Apart the points that I've addressed in my previous comments I've also had to do on (uglier) change:
Calling notifier.notifyGrowlOf(...) requires cocoa in the classpath during compilation (this means that even if we don't build the bundle we still need cocoa). In order to avoid compilation errors on non mac platforms, I've added a notifyGrowlOf() method in your GrowlNotificationServiceImpl class.
The method wraps usage of growl with reflection. This resolves compilation issues but would only work until the day you decide to add images to your notifications since at that point there would be no way around and you'd have to have cocoa in your classpath.
We are planning to build a separate plugin repository on sip-communicator.dev.java.net and when this happens, the growl notifier would have its own project and won't have to compile on anything else but a mac ... until then reflection would have to do.
OK, I think that's all. Let me know if I've broken anything (which is quite likely) or if you have any comments or disagree with my modifications.
Once again, great work Romain!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org