growl should not display initial status

[Chascon]

One annoying this about growl is that it first displays that a contact logs in, then a change in status. In practise this should only end in two alerts, but it usually works out to at least 4 per contact.

I think growl should only display the status after lag giving that the initial status is going to change.
This should not take away from the alert functionality of growl given that a bell sound alerts log-in entrances anyway.

Chascon

[Mats (matsben)]

I have now added a test that actually checks that any of type, show, or status elements/attribute have actually changed before displaying any Growl presence event. This is not exactly what you asked for but it is a start. Let's test this first. Setting a kind of pending event can be done and is simple. To be continued...

[Chascon (chascone)]

Sounds like that'll do. The pending event functionality could be added later if still necessary.

Is this change to show up in the nightlies/dailies?

[sander (s-devrieze)]

Yes, it should be in the current build: http://coccinella.cvs.sourceforge.net/coccinella/coccinella/components/Growl.tcl?view=log ...ready for you to test! ;-)

[Chascon (chascone)]

K, thanks. I was running an old version (0.96.4.1). The update version check code should be reviewed as it didn't work (bug #1), else I would have updated. It says that my version is up to date.

I´ll see if 0.96.6 has the same problem, although the update check reports the wrong version (bug #2). It reports that I am running the latest 0.96.5, despite that the disk image and the About Coccinella says 0.96.6.

These bugs are reported simultaneously as,
https://bugs.launchpad.net/coccinella/+bug/202694
https://bugs.launchpad.net/coccinella/+bug/202700

I'll report these as bugs.

[Chascon (chascone)]

Ah, I assume that by current you mean CVS or bereakfast service as in,
http://coccinella.im/breakfast/

[Chascon (chascone)]

I've tried a daily for a few days now and it's still a problem. The "pending event functionality" code is probably needed.

[Mats (matsben)]

It would help if you could detect exactly what the XML looks like that
you receive. It shouldn't invoke Growl normally. Just look for any
<presence typ='available' from='JID-that-rises-Growl' .../> in either
Debug window (Info/Debug (not linux)) or Shift-Control-D.

[Chascon (chascone)]

Logging onto various servers with MSN transports while running the Debug terminal causes Coccinella to stop responding, by the way. Sometimes it doesn't even manage to log on. GTalk seems to do fine though.

I'll turn the debug term on post-login and I'll see what I can report back.

[Chascon (chascone)]

K, it just happened where one contact gets displayed via Growl an unnecessary 3 times.

My skills got to be near zero since I haven programmed in half a decade but here goes ...

I gather that growl is simply mirroring every status update that it receives from transports. Let's look at the code referred to the event above.

RECV: <presence <email address hidden>" from="someone\<email address hidden>"><status>q wen krrete ayer!!!!</status></presence>

RECV: <presence <email address hidden>" from="someone\<email address hidden>"/><presence <email address hidden>" from="someone\<email address hidden>"><status>q wen krrete ayer!!!!</status></presence>

RECV: <presence <email address hidden>" from="someone\<email address hidden>"><status>q wen krrete ayer!!!!</status><x xmlns="vcard-temp:x:update"><photo><![CDATA

As far as I can see, there is no change in this contact's status, therefore there is no need for Growl to display the same contact's status three times, yet it does.

So what's needed is something you proposed before, a filter to catch unnecessary duplicate status reports, with a cache to refer to only the last received status. I don't think your code is working, if it's in the 0.96.8 release.

I did recheck my reading a few times and it seems to make sense with other occurrences in the debug console, although there was one other time where Growl reported a presence more than once but debug console didn't report each and every time; I gather there are various issues contributing to the same problem but we should probably work on one problem at a time, especially considering that I don't understand the later one. Lastly, I think there is a third contributing factor, and that is that sometimes transports seem to log in and out, but we have no control over this.

[Chascon (chascone)]

By the way, I never found <presence typ='available' from='JID-that-rises-Growl' .../> in the debug window.

[Chascon (chascone)]

I've noticed that in the below, despite that <status>q wen krrete ayer!!!!</status></presence> is shown three times, Growl reports it differently each time.
Once initially to report a log-on, another reports an initial status, and the last report looks like a customized status (the CDATA? or vcard?).

It looks as if this occurs in groups of three, and if this is so ... why not just filter the first two reports out and only display the last custom status?

If each proprietary protocol does this differently (the below "workings in groups of three" is MSN), a different filter for each proprietary service would need to be assigned.

RECV: <presence <email address hidden>" from="someone\<email address hidden>"><status>q wen krrete ayer!!!!</status></presence>
RECV: <presence <email address hidden>" from="someone\<email address hidden>"/><presence <email address hidden>" from="someone\<email address hidden>"><status>q wen krrete ayer!!!!</status></presence>
SEND:

RECV: <presence <email address hidden>" from="someone\<email address hidden>"><status>q wen krrete ayer!!!!</status><x xmlns="vcard-temp:x:update"><photo><![CDATA[78f009e11c0d0740fc237b5c9b081b53b2c945a9]]></photo><hash><![CDATA[78f009e11c0d0740fc237b5c9b081b53b2c945a9]]></hash></x></presence>
SEND:

[Chascon (chascone)]

As for what happens when I get a flood of status reports of people that are already logged on as per my roster ...

RECV: <presence <email address hidden>" from="someone\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone2\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone3\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone4\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone5\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone6\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone7\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone8\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone9\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone10\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone11\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone12\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone13\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone14\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone15\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone16\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone17\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone18\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></presence><presence <email address hidden>" from="someone19\<email address hidden>" type="unavailable"><x xmlns="vcard-temp:x:update"/></pre

It's nothing odd other. Perhaps Coccinella should look at one's roster before reporting status to Growl, and playing an alert sound --which can be annoying too.

[Chascon (chascone)]

oops, those are logs of people loggin off. My mistake.

[Chascon (chascone)]

Even so, "It's nothing odd other. Perhaps Coccinella should look at one's roster before reporting status to Growl, and playing an alert sound --which can be annoying too." might be a good idea.

[Mats (matsben)]

The debug window has problems for large text outputs on Mac.
On Mac it is better to launch Coccinella from the Terminal application:

1) ./Coccinella.app/Contents/MacOS/Coccinella if you don't have a
Tcl/Tk installation.
2) wish8.5 Coccinella.tcl if you have a wish installation and the
Coccinella sources.

On Tue, May 27, 2008 at 6:05 AM, Chascon <email address hidden> wrote:
> Logging onto various servers with MSN transports while running the Debug
> terminal causes Coccinella to stop responding, by the way. Sometimes it
> doesn't even manage to log on. GTalk seems to do fine though.
>

[Mats (matsben)]

I'm investigating this and if I send the same presence element I don't see that Growl gets activated. Note that coccinella needs to be in the packground for Growl to display anything. If I use another coccinella instance on another machine and select the same presence:

<presence from='d\<email address hidden>/Coccinella@hp' <email address hidden>/Coccinella@Macintosh' xml:lang='en'>
  <status>Vikigt möte</status><show>chat</show> (Swedish)
  ...
 First time it Growl gets activated, next time with identical presence it doesn't. Note also that there is no explicit type='available' attribute since this is by default, and xmpp says to exclude it in that case (bandwidth).

The code that sends the "signal" looks like:
    # Hook to run only for new presence/show/status.
    # This is helpful because of some x-elements can be broadcasted.
    array set oldPres [$jlib roster getoldpresence $jid3]
    set same [arraysequalnames attrArr oldPres {-type -show -status}]
    if {!$same} {
 eval {::hooks::run presenceNewHook $jid $type} $opts
    }

and the Growl posting has been changed to:
 set title $djid
 set msg $showMsg
 if {$status ne ""} {
     append msg "\n$status"
 }
 growl post [mc Status] $title $msg $cociFile

which makes better sense.

Note really sure what goes wrong in your case. I also tested using escaped ("\") JID and that works too.