Cosmic Life

EventBox Update (703)

The Return of the Services

We’re happy to return the following services with this build:

• Digg
• Identi.ca

Digg has gained a feature and lost one - we identified that the upcoming view in Digg was of limited utility, so it’s now gone. We have added the ability to perform searches in Digg using Digg’s search engine.

Application Move

You might have noticed that some applications ask you to move themselves to the Applications folder. I have seen three variations so far:

• App runs from a bundle, asks to copy itself to Applications
• App runs from a folder, asks to move itself but doesn’t relaunch
• App runs from a folder, asks to move itself and relaunches

The first scenario doesn’t apply in our case as we ship in a zip file. The reason I think scenarios 2) and 3) are not ideal is because they break the “flow” - you’ve just started the application and you want to run it but instead you get interrupted with a relaunch or worse, the app just quits and doesn’t relaunch itself.

We’ve taken a different approach - we will ask you on startup but actually perform the move when you quit, so that you don’t get interrupted on startup and move on with using EventBox.

Bug Fixes

We have included a few bug fixes - we fixed the problem with dates in the future (Google Reader) and also a crasher bug.

I’d like to thank everyone who has been submitting bugs - your help is greatly appreciated. Special thanks to the following people who have gone the extra mile (in no particular order):

• Andy Couch
• Jeremy Pinnix
• Adam Procter
• Dirk Sierd de Vries
• Simon Iannelli
• Jon Nall
• Colin Pekruhn

Content Limitation Details

I’d like to explain a few details about how content limitation works in EventBox.

Event Ownership

Each event can have multiple “owners” (folders / containers). It’s important to distinguish between ownership and aggregation. Just because you see an event in a folder / container, it doesn’t mean it’s owned by it. I’ll give a few examples to clarify the point.

If you use Google Reader, you know that content is organized in feeds. Each feed owns the feed posts that belong to it. What about any folders? Well, they don’t actually own any of the feed posts - the only reason any events are displayed is because the folders aggregate the contents of feeds.

Let’s support you use Twitter and have created a folder to keep all your searches. Each search owns the events it contains but the folder containing your searches doesn’t own a single event.

Content Limitation

It’s crucial to understand that when you right click on any container (except a few ones, see below) and adjust the content limit, you’re only adjusting the limits for any owned events. The consequence is that if you set the limit for a Google Reader / Twitter folder to 1 day and pressed “Limit Now”, nothing will happen. Why? Because the container doesn’t own any events, so there’s nothing to remove.

Exclusion

We also have the ability to exclude some containers from being limited. If you right-click on them, you will not see any options to adjust the limitation (Twitter’s Favorites and Google Reader’s Starred are prime examples).

Behavior

We’ve changed the behavior of the content limitation actions performed when you use the interface (i.e., by right-clicking). Everything above is still valid and is how things work under the hood. We’ve made the following adjustments:

• When you set the content limitation for a folder, we will automatically assume that you also want to set the same content limit for all folders below.
• When you manually limit (“Limit Now”) a folder, we also perform content limitation for the folders below.

Main App Progress

As explained in one of my previous posts, I’m currently working on getting a build out that can be tested (“main app” vs “services”). I’ve got a long list of tasks that need to be completed before we can release some sort of build to the public. Some notable work in the past few days:

• The Heads-Up Display has now been ported and works as normal.
• I’ve introduced a more granular control mechanism to adjust exactly which folders appear in the HUD - you can now control it on a per folder basis (via right-click). See screenshot below.
• The preferences section of the application has now been ported and modified so that when you add / remove services, preference panes get added / removed.
• A time-based content limitation mechanism is being introduced (as opposed to the current limit-based). Content limitation is performed only on startup as to not disrupt any ongoing reading activity but you can trigger it manually if you wish. See screenshot below.

Screenshot.

Quick Status Improvements

There has been been a problem with the quick status view (the text area which you use to tweet, etc) - it does not make it clear what exactly you’re doing and where you are posting to. At the moment, it can cause confusion in the following case:

• Posting a tweet / FB status update in a mixed container (e.g., Unread)

Another potential issue is that when you have selected a tweet and post an update, EventBox treats this is a reply to that particular tweet. In 99% of the cases, that’s what you want but in the remaining 1%, it will not only do the wrong thing but the user will have no indication of it.

With multiple accounts, there’s even a higher chance of confusion when you tweet from a mixed container - which account is being used to send the tweet? So we have taken steps to remedy the problem and we’ve come up with the following solution (screencast, screenshot). The new area gives you additional information about:

• What type of service you’re sending the information to (using a small icon)
• The account name which is used to send the information
• Any additional information (e.g. whether you’re sending just a tweet or replying to a particular person)

Google Reader Update [2]

Google Reader has almost been ported. The features that work:

• General feed syncing (i.e., whatever is in the currently available public build)
• Friends’ shared posts (new feature)
• Starred folder (new feature)
• Shared folder (new feature)

Bonus Screenshot

It’s fast. I’ve benchmarked it against a few other Google Reader clients and we’re by far the most efficient. A delta update where you have a small number of new unread feeds takes only 40-80KB while other implementations use upwards of 1MB. The savings are going to be even bigger if you subscribe to more feeds.

There’s another issue associated with Google Reader - the Starred folder. After I asked you, how you use starred items, two patterns emerged:

• Starred used as a way to read articles at a later point and then un-starring the posts in question. The starred folder grows / shrinks.
• Starred used as a way to bookmark posts. The starred folder only ever grows.

If we want to keep the starred folder in full synchronization, the second usage scenario poses two problems:

• Memory usage will only ever increase due to the starred folder
• Huge amounts of data would have to be transferred on each refresh

That’s the reason why I’ve included a setting to control the behavior of the starred folder - you can either set it to fully sync the starred folder or not. For people who have a relatively low amount of starred items, full sync will pose no performance / network bandwidth problems. For everyone else, the default (off) should work for you well.

Testing

I’ve outlined rough timeframes at the bottom of a previous post but I’ve changed my mind on a particular aspect. The timeframes are still accurate with regards to the public release but I also plan to release a working build of the new generation EventBox as soon as I can. Here’s the catch:

• It will only feature a couple of services (Twitter, OneRiot, Reddit, Google Reader)
• Some features will be missing
• Updates will be released very often
• It will have bugs

You will be able to run the build alongside the current release without any data interference. I’d really appreciate it if some brave people would be test it out. I’ll be releasing more information regarding the details in the future.

Google Reader Update

Following up on my previous post, today was a quite a productive day. As mentioned, I’m porting Google Reader at the moment. I made a screencast to show you some of the improvements.

Speed

Here are the raw numbers:

• Full sync, improved build: 4s
• Full sync, current build: 13s

That’s a saving of 9s, a whopping 70% improvement in sync time.

Favicons

Notice how all favicons load properly (except a few ones but those feeds have no favicons) and none of the favicons are FeedBurner’s.

Friends

I also managed to get your friends’ shared feeds into EventBox.

EventBox Progress Update

It’s time for another progress update. It has been very busy over the last few weeks.

As I have explained previously, I’m currently rewriting the core of EventBox which forces an almost full rewrite of any parts affected (which is almost everything). The rewrite goes along the lines of:

• Fix the core
• Rewrite all services / plugins to use the new core
• Rewrite the interface bits to use the new core

Fixing the core is not an easy task but it’s doable with a little bit of thought. I’ve already rewritten it and from a usage point of view (i.e., how the core is used internally by the other bits of the application), it’s brilliant and a huge improvement over what we had. Do users actually care about the internals? Not directly but here’s the twist: a badly engineered core / foundation will last up to a point and when the “breaking” point is reached, it will be impossible to add new features / improvements. That’s the reason why I’m carefully doing the work now and taking all the time I need because it will pay off in the future.

One of the upsides of doing the rewrite is that it allowed me to fix some longstanding architectural problems which prevented us from implementing features / fixing bugs in some plugins. One such example is that now, our user interface architecture can have multiple representations of a single event. You might ask what does this mean in real terms? One usage would be the representation of RSS / Atom posts. For example, we could display them as a list (screencast) when you look at them in their plugin and as paper cutout when being displayed in a mixed container (e.g., Unread, Flagged, smart containers, etc). We’re currently not taking advantage of this but we will. Another example of a new capability available due to the core rewrite is the new notification center.

With the core now fixed, I’m left with rewriting the plugins and the interface bits so they all start working again. The following plugins have been fully ported to the new architecture:

• Twitter
• OneRiot
• Reddit
• Feeds

I’m currently working on porting Google Reader. The following plugins still need to be ported:

• Google Reader
• Identi.ca
• Digg
• Facebook
• Flickr

You might want to know how long it takes to port a plugin. It depends. It can take a single day (e.g., Feeds) or a week (e.g., Twitter). Bear in mind that I’m not just “porting” it straight, I’m taking the time to fix any problems and improve the plugins as I go along.

For example, here are some of the improvements that I’ve made during the rewrite (Twitter):

• Events are now logically consistent. For example, if you have the same event in a profile peek and in the main timeline, you will not have to mark both as read and they’re logically the same event.
• When you send tweets, we no longer refresh to get the new tweet but instead use a more efficient method to retrieve it. So you can send 10 tweets in a row without EventBox making any refreshes / additional requests.
• Twitter favorites are finally implemented correctly so you will see all of them and not only a subset.

I’ve also fixed the problem with feeds’ favicons - it currently displays the Feedburner favicon for some of them.

As I’m rewriting the Google Reader plugin, I’ve discovered many problems which I need to fix. Firstly, it’s going to use a more efficient way of performing synchronization. I also want to implement support for the Favorites / Shared folders.

A lot of work still needs doing. The rest of the plugins need to be rewritten / ported and it will take at least another 2 weeks (optimistically) and 5 weeks (worst case). After that’s done, the main part of the application which controls the interface needs to be adjusted to all the changes. I’ve no estimate for that but it’s at least a few weeks of work. Optimistically, we’re looking at an early October launch, realistically, maybe end of October / mid-November.

Due to some internal changes, I’m currently the only person performing all the work that I’ve described above and the estimates assume that I continue to work at the current rate - seven days a week with an unhealthy amount of working hours. I’ve been able to keep it up for a while now but it’s getting increasingly harder to do so. I just want you to know that I’m doing my best to bring you the new features as fast as possible but I might be forced to slow down in the future if my health deteriorates due to my working schedule.

EventBox's Notification Center

As part of the EventBox rewrite, we took the chance to introduce a centralized notification center. It will give you more granular control over what notifications get sent. For example, you will be able to say that you only want to be notified about mentions and DMs (for Twitter). Check out the screencast for a demo.

EventBox - Multiple Accounts Update

I’d like to say a few words about how work has been going recently.

Multiple Accounts

As you may know, I’ve been solidly working on getting multiple accounts into EventBox (it should have been there from day one but we made a mistake, retrospectively). Supporting multiple accounts in EventBox requires a lot of work due to the internal structural changes. I just got the new architecture sort-of running and here are the results as a screencast.

It’s not very apparent that almost everything else doesn’t work at the moment. Think of it like this - you’ve been building your house for a very long time but suddenly you realize that your foundations are not going to last you any more. So you take them all out and start replacing every single bit. That’s what I’m currently doing.

More Than That

The build which will contain multiple accounts isn’t just about multiple accounts. It’s actually much more than that - it’s a complete rewrite of our foundations. We will have a much faster core and it’s going to be a lot easier to extend it in the future. I’ll be documenting all the positive and negative side-effects of this in the following weeks. Regarding time frames, I can’t really say anything - it’s at the very least a few weeks off. Thanks for your patience, I’ll be doing my best to keep you up to date with what’s happening behind the scenes.

EventBox Update - OneRiot

We’re very happy to release another update to EventBox (while working on multiple accounts) and it brings a new service, OneRiot! OneRiot indexes the social web in realtime and now you will be able to use their search right within EventBox. All you have to do is setup several searches and then keep an eye on them - check out the screenshot.

We’ve also fixed some minor bugs like the conflict between automatic URL expansion and internal photo viewing (Mobypicture URLs would get expanded and not recognized as a consequence). The Facebook status limit has been increased to 255 characters (limitation imposed by the API) and we’ve also fixed a bug where liking in Facebook would return an unexpected error.

The update has been pushed to both stable and bleeding edge, so just click on “Check for Updates…” from the EventBox menu in the menubar.