[sip-comm-dev] [GSoC09] Java interface for Mac OS X's Growl
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,
>>> GROWL_NOTIFICATIONS_DEFAULT and GROWL_TICKET_VERSION. However,
>>> 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