Aug 16

GSoC 2016: Wrapping Up

It’s hard to believe it is already late August and this year’s Google Summer of Code is all wrapped up.  The past couple of months have really flown by.  In the previous post I summarized the feedback we received on the new UI design and discussed the work I’ve been doing to port the current UI (for editing events and tasks) to a tab.  In this post I’ll describe how to try out this new feature in a development version of Thunderbird, and give an update on the HTML implementation of the new UI design. In my next post I’ll share some thoughts on using React for the HTML UI.

To try out editing events and tasks in a tab instead of in a dialog window you’ll need a development version of Thunderbird (aka: “Daily”).  Since it is a development version you will want to use a separate profile and/or make sure your data is backed up.  Once you have that all set up, you can turn on the “event in a tab” feature with a hidden preference.  To access hidden preferences, go to Preferences > Advanced > Config Editor, and then search for “calendar.item.editInTab” and toggle it to true by double-clicking on it.

Or if that’s too much trouble you can just wait until it arrives in the next stable release of Thunderbird/Lightning.  In the meantime, here’s what it looks like (click to enlarge):


The screenshot above shows the current XUL-based UI ported to a tab.  I ended up not having much time to work on the new HTML-based UI (actually only a week or so) and did not get as far on it as I’d hoped — only as far as a basic and preliminary implementation, a starting point for further development rather than something that can be used today.  For example, it does not yet support saving changes and not all of the data is loaded into the UI for a given event or task.

Some aspects do already work, like the responsive design where the UI changes to adapt to the width of the window, taking more advantage of the greater space available in a tab.  Here are two screen shots that show the wide and narrow views (click to enlarge).



Even though the HTML UI is not ready for use yet, we decided to go ahead and land it in the code base as a work-in-progress for further development.  So if you are curious to see where it stands, it can also be turned on with a hidden preference (“calendar.item.useNewItemUI”) in a current development version of Thunderbird, as described above.  Again, be sure to use a separate profile and/or make sure your data is backed up.

For more technical details about the project, including some high-level documentation I wrote for this part of the code, see the meta bug, especially my comment #2 which summarizes the state of things as of the end of the Summer of Code period.

It was a great summer working on this project.  I learned a lot and enjoyed contributing.  As my time permits, I hope to continue to contribute and finish the implementation of the new UI.  Many thanks to Google, Mozilla, and especially to my mentors Philipp Kewisch (Fallen) and MakeMyDay for their guidance and tireless willingness to answer my questions and review code.  Also thanks to Richard Marti (Paenglab) for his help and feedback on the UI design work.

I wish there was another month of the official coding period to get the HTML implementation further along, but alas, so far we’ve only been able to help people manage their time, not actually generate more of it.

— Paul Morris

Aug 16

GSoC 2016: Where Things Stand

The clock has run out on Google Summer of Code 2016.  In this post I’ll summarize the feedback we received on the new UI design and the work I’ve been doing since my last post.

Feedback on the New UI Design

A number of people shared their feedback on the new UI design by posting comments on the previous blog post.  The response was generally positive.  Here’s a brief summary:

  • One commenter advocated for keeping the current date/time picker design, while another just wanted to be sure to keep quick and easy text entry.
  • A question about how attendees availability would be shown (same as it is currently).
  • A request to consider following Google Calendar’s reminders UI.
  • A question about preserving the vertical scroll position across different tabs (this should not be a problem).
  • A concern about how the design would scale for very large numbers (say hundreds) of attendees, categories, reminders, etc.  (See my reply.)

Thanks to everyone who took the time to share their thoughts.  It is helpful to hear different views and get user input.  If you have not weighed in yet, feel free to do so, as more feedback is always welcome.  See the previous blog post for more details.

Coding the Summer Away

A lot has happened over the last couple months.  The big news is that I finished porting the current UI from the window dialog to a tab.  Here’s a screenshot of this XUL-based implementation of the UI in a tab (click to enlarge):


Getting this working in a really polished way took more time than I anticipated, largely because the code had to be refactored so that the majority of the UI lives inside an iframe.  This entailed using asynchronous message passing for communication between the iframe’s contents and its outer parent context (e.g. toolbars, menus, statusbar, etc.), whether that context is a tab or a dialog window.  While this is not a visible change, it was necessary to prepare the way for the new HTML-based design, where an HTML file will be loaded in the iframe instead of a XUL file.

Along with the iframe refactoring, there are also just a lot of details that go into providing an ideal user experience, all the little things we tend to take for granted when using software.  Here’s a list of some of these things that I worked on over the last months for the XUL implementation:

  • when switching tabs, update the toolbar and statusbar to reflect the current tab
  • persist open tabs across application restarts (which requires serializing the tab state)
  • ask the user about saving changes before closing a tab, before closing the application window, and before quitting the application
  • allow customizing toolbars with the new iframe setup
  • provide a default window dialog height and width with the new iframe setup
  • display icons for tabs and related CSS/style work
  • get the relevant ‘Events and Tasks’ menu items to work for a task in a tab
  • allow hiding and showing the toolbar from the view > toolbars menu
  • if the user has customized their toolbar for the window dialog, migrate those settings to the tab toolbar on upgrade
  • fix existing mozmill tests so they work with the new iframe setup
  • test for regressions in SeaMonkey

In the next two posts I’ll describe how to try out this new feature in a development version of Thunderbird, discuss the HTML implementation of the new UI design, and share some thoughts on using React for the HTML implementation.

— Paul Morris