new ui for rendered items
Posted by Will Kahn-Greene
I checked in the latest ui in r8671. I’ve been told that a number of tweak requests are on their way, but it’s looking pretty good and there weren’t any major bugs.
The new ui took me a week and a half to implement. There were a bunch of complexities that made it difficult. I thought I’d talk about some of those here so people who aren’t as intimate with the code can get an idea of how much work and what kind of work is involved.
First off, Miro 2.0 uses native widgets instead of HTML/CSS/Javascript for everything. The one place this isn’t quite true is in the item lists where we’re rendering our own widgets using a layout/cellpacking API that abstracts over a platform-dependent implementation layer. The platform-dependent implementation layer consists of two implementations: OSX (cocoa, pyobjc, …) and GTK (pygtk, pango, …). The abstraction layer is very similar in style to the GTK side of things. Ben wrote most of this as we needed it a few months ago.
The first problem I had was that I wasn’t familiar with the platform-independent layout/cellpacking API we had.
The second is that there are a bunch of variations on the theme. Depending on what the context is, the item gets rendered differently. In playlists, items have a “Remove from playlist” button, but in channels, the item has a “delete” button.
Additionally, items have two display modes: with details and without details. The without details mode is the easiest to render since it’s just a bunch of packed things and the resizing handling is easy to deal with. The with details mode is really difficult because we want to show the entire title and description for the item but the cells these bits are in expand as the window is resized. We get into this chicken-and-egg problem where we need to lay things out, but in order to lay things out we need to know the size of the space we’re laying things out in, but in order to know the size we need to lay things out….
On top of that, items are either selected or not selected–both of which look different.
The other set of problems I ran into were theming issues. The rendering code tries to “look” like the platform it’s running on: the OSX buttons look different than the GTK buttons; OSX uses Finder but Windows uses Explorer and the text needs to reflect that; …
All of this makes for very complex implementation code. Structuring that as I figured things out was difficult to do well and the result isn’t great structure-wise. Ben’s already done a pass at fixing the resizing issues which resulted in some structure fixes. It’s likely that other things will get fixed and massaged over the next week or so.
The end result of all this work is that we went from this:
to this:
WordPress. Theme based on Simplism, but without bits I found irritating. I'm still toying with it.
December 12th, 2008 at 9:16 pm
It’s nice to see the focus on usability as well as to hear about the attention that performance is getting.
Esspecially in the rendering of the item lists is where most of my having-to-wait-a-couple-of-seconds-and-see-miro-allocate-100-meg moments are.
Although most vodcasts don’t have that many items, aggregate groups usually do. And the rendering part has a strong lag on my quad-core, 2gb setup.
I can only assume, that with the new interface-work these penalties are gone?
December 12th, 2008 at 11:34 pm
I’m not sure I would say the penalties are gone with the ui work we’ve been doing in the Miro 2.0 cycle since this is clearly a scaling problem with no upper bound for number of items and thus there will always be a number of elements beyond which it renders too slow.
Having said that, it’s much faster than it was on Linux and much faster on Windows, too. I don’t know offhand if it’s faster or much faster on OSX–I don’t use Miro on that platform much.
There’s still a lot of performance work that can and should be done in other parts of Miro and we’re tackling those items one by one in future versions.
December 16th, 2008 at 4:12 pm
Kudos for the overhaul, definitely a major improvement.
As for performance on OS X, not quite there yet. Very jerky item list scrolling and quite noticeable consistent ui lagging overall. Resizing resembles stopmotion movies, but hope it’ll improve before release.
If it were up to me the above should certainly be treated as blockers for v2, as it’s quite a few steps back from the old releases -which had it’s own fair share of issues- in so many aspects performance-wise.
January 12th, 2009 at 2:33 pm
Earlier you said “after working and playing with what will become Miro 2.0, it’s really hard to go back and develop on and play with the Miro 1.2″. Knowing that the rest of us are stuck with 1.2 :-), is there an ETA for 2.0?
Is it on a deadline, or is the list of “target milestone 2.0, P1-P3″ bug reports the set of things to complete before release regardless of time? (I’ve been on both kinds of projects.)
P.S., stop reading blog comments and get back to making Miro 2.0.
January 12th, 2009 at 3:43 pm
Ken: We’re too small a team for deadline-based scheduling to be effective in any meaningful way. We are trying to get it out as soon as possible and we’ve been pushing hard on Miro 2.0 development for 6 months and really hard for the last couple.
A couple of weeks ago, we did a triage pass at focusing on “mission-critical” issues and pushing everything else off to a future version. Even so, we still have a decent number of P1 and P2 bugs that are blocking a Miro 2.0 release.
I’m not really sure when we’ll get it out, but I feel confident that it’ll be in the first quarter of 2009.
It’s getting there. We had a really good bug-fixing week last week. A few more of those and Miro will be release-worthy.