[sip-comm-dev] [GSoC09] Java interface for Mac OS X's Growl

Romain KUNTZ kuntz at lsiit.u-strasbg.fr
Fri Jul 10 15:41:54 CEST 2009


On 2009/07/10, at 15:00, Egidijus Jankauskas wrote:
>> On 2009/07/09, at 17:10, Egidijus Jankauskas wrote:
>>> 1) Growl uses a registration dictionary to register an application  
>>> with it. Documentation says that you must provide three keys in  
>>> the registration dictionary: GROWL_NOTIFICATIONS_ALL,  
>>> when registration happens from dylib, Growl also requires a  
>>> GROWL_APP_ID to be provided. Since GROWL_APP_ID is a bundle  
>>> identifier of your app, I guess that Growl checks this ID itself,  
>>> but in our case the dylib does not have an associated bundle and  
>>> Growl cannot find one. I provide an empty string instead, which  
>>> works fine, but I don't know what side effects this could have.
>> Could this be an issue if several applications on the same computer  
>> use this library?
>> In that case, maybe we should consider adding one more interface  
>> that should be implemented by the user of the library, in order to  
>> set the GROWL_APP_ID? WDYT?
> I tried running different test apps simultaneously and they all  
> worked as expected. However, I have just tried to run different test  
> apps having the same name and the problem surfaced. Growl daemon  
> sees them both as one. So the GROWL_APP_ID must be set, thus I will  
> simple add appID parameter to Growl class constructor.

Ok, sounds like a good and simple way to handle it.

>>> 2) If Growl API is used in a Java application that uses AWT and is  
>>> run in headless mode, it works, but Growl Daemon complains in the  
>>> console with the following message "in copyCurrentProcessURL in  
>>> CFGrowlAdditions: Could not get application location, because  
>>> GetProcessBundleLocation returned -606".
>> I don't think people would use growl in headless mode (any scenario  
>> in mind?), so this is not really a problem. You may simply document  
>> it, that should be enough.
> I found out this when I tried a console application that reads an  
> icon from a jpeg using AWT classes. If a console app uses AWT, then  
> it appears in the Dock as well. If you don't want it to be visible  
> in the Dock, you need to run it in headless mode and as a result of  
> that start getting these error messages from Growl. But yes, I think  
> it is not very realistic for someone to use Growl in a console  
> application. I made a comment about this in the source code.

Ok, this sounds reasonable for the moment. Note that another GSoC  
project is about running SC in console mode, but I don't know whether  
it uses headless mode or not.


To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net

More information about the dev mailing list