Tag Archives: evolution

Things I’ve Learned This Week (April 6 – April 10, 2015)

It’s possible to synthesize native Cocoa events and dispatch them to your own app

For example, here is where we synthesize native mouse events for OS X. I think this is mostly used for testing when we want to simulate mouse activity.

Note that if you attempt to replay a queue of synthesized (or cached) native Cocoa events to trackSwipeEventWithOptions, those events might get coalesced and not behave the way you want. mstange and I ran into this while working on this bug to get some basic gesture support working with Nightly+e10s (Specifically, the history swiping gesture on OS X).

We were able to determine that OS X was coalescing the events because we grabbed the section of code that implements trackSwipeEventWithOptions, and used the Hopper Disassembler to decompile the assembly into some pseudocode. After reading it through, we found some logging messages in there referring to coalescing. We noticed that those log messages were only sent when NSDebugSwipeTrackingLogic was set to true, we executed this:

defaults write org.mozilla.nightlydebug NSDebugSwipeTrackingLogic -bool YES

In the console, and then re-ran our swiping test in a debug build of Nightly to see what messages came out. Sure enough, this is what we saw:

2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 coalescing scrollevents
2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002
2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 adjusted:-0.002
2015-04-09 15:11:55.396 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 call trackingHandler(NSEventPhaseChanged, gestureAmount:-0.002)

This coalescing means that trackSwipeEventWithOptions is only getting a subset of the events that we’re sending, which is not what we had intended. It’s still not clear what triggers the coalescing – I suspect it might have to do with how rapidly we flush our native event queue, but mstange suspects it might be more sophisticated than that. Unfortunately, the pseudocode doesn’t make it too clear.

String templates and toSource might run the risk of higher memory use?

I’m not sure I “learned” this so much, but I saw it in passing this week in this bug. Apparently, there was some section of the Marionette testing framework that was doing request / response logging with toSource and some string templates, and this caused a 20MB regression on AWSY. Doing away with those in favour of old-school string concatenation and JSON.stringify seems to have addressed the issue.

When you change the remote attribute on a <xul:browser> you need to re-add the <xul:browser> to the DOM tree

I think I knew this a while back, but I’d forgotten it. I actually re-figured it out during the last episode of The Joy of Coding. When you change the remoteness of a <xul:browser>, you can’t just flip the remote attribute and call it a day. You actually have to remove it from the DOM and re-add it in order for the change to manifest properly.

You also have to re-add any frame scripts you had specially loaded into the previous incarnation of the browser before you flipped the remoteness attribute.1

Using Mercurial, and want to re-land a patch that got backed out? hg graft is your friend!

Suppose you got backed out, and want to reland your patch(es) with some small changes. Try this:

hg update -r tip
hg graft --force BASEREV:ENDREV

This will re-land your changes on top of tip. Note that you need –force, otherwise Mercurial will skip over changes it notices have already landed in the commit ancestry.

These re-landed changes are in the draft stage, so you can update to them, and assuming you are using the evolve extension2, and commit –amend them before pushing. Voila!

Here’s the documentation for hg graft.

  1. We sidestep this with browser tabs by putting those browsers into “groups”, and having any new browsers, remote or otherwise, immediately load a particular set of framescripts. ↩

  2. And if you’re using Mercurial, you probably should be. ↩

Fiddling with an EDS Provider for Lightning (Calendar)

While I was focusing on getting EDS contacts integration working in Thunderbird, Phillip Kewisch started working on an EDS provider for Lightning.  This would allow the Lightning calendar add-on to read and manipulate EDS calendars.

One of the reasons we want to do this is because EDS calendars are nicely tied in with the indicator-datetime applet:

The indicator-datetime applet on the Ubuntu desktop, opened to show the calendar, and some events from the calendar

That’s really cool integration – at a glance, I can see what’s going on today, and I don’t need to open my full-blown desktop calendar application to do it.

In just a little over a week, Phillip had us doing basic reading of the default EDS calendar:

The Lightning add-on, displaying an event from an EDS calendar

Awesome!  But there’s still a lot of work to do.

In particular…

Indicator-datetime integration

When we click on an event in the indicator-datetime applet, we want Thunderbird to open with the Lightning tab focused, and the selected event in view.  If we click on the “Add Event” menu item, we should be brought to the dialog that allows users to add new events to their EDS calendar.  Also, when a user double-clicks on a particular day in the indicator-datetime applet, we want that day to open up in Lightning.

So there are a few challenges here.  The first one is that opening Evolution calendar is hard-coded into indicator-datetime.  That means that we’re going to have to do a bit of reorganizing so that indicator-datetime can figure out what application to open when the user starts clicking on things.

And remember that we want this to occur whether or not Thunderbird / Lightning is open.  If Thunderbird is closed, and the user starts clicking around in indicator-datetime, then Thunderbird and Lightning should open and react appropriately.  If they’re already open, they should probably focus (although Evolution calendar doesn’t seem to do this).

That means making a way for Lightning to be summoned up from a command like “thunderbird -calendar”.

Full reading and writing to EDS calendars

The provider that Phillip got working is a good start, but it’s far from complete.  For example, it will only read a single calendar from EDS.  It also seems to choke if I restart Thunderbird after loading up my EDS calendar.

Luckily, Lightning was developed with extensibility and other back-ends in mind.  No de-RDF’ing required.

So what’s the ETA on this?  Hard to say.  I’m new to Lightning development, and I’m still feeling my way around.

I’ll keep you posted!

It’s Official: Thunderbird will be the default e-mail client for Ubuntu Oneiric

Word has just come down from Canonical:  Thunderbird will be the default e-mail client in Ubuntu Oneiric!

Woo!  And there was much rejoicing!

Breakdancing Bear

Now, you might think this news is a bit late.  Thunderbird has been set as the default e-mail client on the past two Oneiric alphas.  Isn’t this old news?

Well, kinda, yeah.  But the thing is, those first alphas were just to get a sense of how Thunderbird would work as the default client, and to gather feedback.  At a moments notice, Canonical could have backed it out and switched it back to Evolution.

But they’ve given their thumbs up, and they’re fully on board.

So, at the risk of repeating myself:  come early October, Thunderbird will be shipped by default!  Woop!

UPDATE (Aug 10, 2:41PM EST)

I forgot to mention that this would not have been possible without the enormous efforts of both Chris Coulson and Andreas Nilsson!  You’re both awesome!

EDS Contacts Integration for Thunderbird – So What?

Some of you might be wondering what the advantage is of having Thunderbird share address books with Evolution.  I mean, what’s the point?  A user will most likely use Thunderbird or Evolution – but rarely both.  Why is sharing contacts between the two interesting at all?

So, the answer lies in how Evolution stores contacts.  If you’re running Evolution, you’re actually running two pieces of software – the Evolution client, and the Evolution Data Server (EDS).  The client is what most users think of as Evolution – it’s the program with the GUI that allows users to access and manipulate their mail, contacts, calendar, etc.

But the heavy lifting is really being done by the Evolution Data Server.  The EDS is the program communicating with the e-mail servers to get and store your mail.  It’s the program communicating with your various address books (local or remote, like Google Contacts).  It’s the program that’s communicating with all of your calendars and task lists.

Essentially, if your Evolution experience was a restaurant, then the Evolution Data Server is the kitchen.  The Evolution client is just your waiter.  The waiter takes your orders and passes them off to the kitchen, the kitchen does all of the cooking, and then the waiter brings you the tasty results.

The fact that GNOME has split Evolution like this is really handy.  It means that alternative clients can access Evolution’s mail, contacts and calendars.  Essentially, the user could uninstall the Evolution client, but keep EDS installed, and still have access to all of their mail, contacts and calendars.

To stretch the restaurant analogy a little bit, what I’m saying is that the GNOME developers made it possible for you to order take out from the Evolution restaurant via a third-party.

So what’s the advantage of that?

Well, for one thing, Evolution Data Server talks to some services that Thunderbird doesn’t – for example, Google Contacts (although, this extension suggests that Google Contacts integration for Thunderbird is possible without EDS).

The other big one is Ubuntu One contacts sync.  Ubuntu One contacts are stored in CouchDB address books that are accessed through EDS.  Now that Thunderbird can read your EDS address books, it means that you get your Ubuntu One contacts as well (at least, it will be able to, once Ubuntu One contacts sync starts working in Oneiric).

Not bad, eh?

Introducing EDS Contacts Integration for Thunderbird (or “Coming up for air”)

Holy smokes, what a pair of months.  Remember when I told you that I was hauling ass on getting an EDS contact integration add-on up and running for Ubuntu Oneiric?  It didn’t stop – I’ve been continuing to haul ass ever since.

And now I’ve got something to show for my efforts!

Here’s a demonstration of my add-on in action:

 

Visit the project page here.

If you’re using Thunderbird on Oneiric, I’d love for you to try the add-on.  All feedback welcome in this Google Groups thread!

Over the next few days, I’m going to write a few posts on what I did, how I did it, and what kind of difficulties I ran into along the way.

Until then, stay tuned!