I was interested in your comments, since I have a SplitContainer within another SplitContainer, and, with SplitContainers becoming deprecated as of 1.1, if I read correctly, we would want the replacement to work at least as well.

I did a quick look at the three pages. In FF, the performance seemed fine. In IE, it may have been a small amount slower, hard to tell, but seemed fine.

I did notice that when the mouse pointer is dragging the splitter and passes into the Editor box (in the Editing tab on the themes page), and the mouse button is released over the Editor, the behavior is very erratic/bad (the splitter doesn't realize the mouse button has been released, so continues to follow the mouse around the screen), probably due to the editor consuming the mouse events?? The prior version of Theme Tester did not have that problem.

I do hope to spend some more time on performance. I think I'm doing more size updates than necessary atm. I actually thought the performance as-is is generally better than the old code in FF, roughly the same in IE7, and, well, pretty crappy in IE6 (for "live" dragging anyway) I'm considering turning off liveDragging for IE6, but I'd be real concerned if FF or IE7 had any noticeable degradation in any mode. Do you have an example where you think the new code is worse?

For compound widgets like TabContainers inside BorderContainers, if/when I move the layout code up a level, I think there should be an additional improvement, but I'd hope that we're not much worse off.

But with performance above or even at old levels, this code would be a huge benefit because I think it'll be less buggy, smaller, and easier to maintain.

Bob,

As you say, sometimes to improve code, an API change is involved. We are very careful about the disruption to our users. This is the first such deprecation I know of since the 0.9 release, so I don't think there is any need to be alarmed by this.

If the two layout widgets are deprecated, it will be done according to our policy, which is to mark the old code as deprecated, provide a replacement, and leave the old code in place for one release cycle (a major release cycle, if I'm not mistaken -- you shouldn't be forced to change your code in any big hurry) API additions are not subject to any freeze, since additive changes tend not to break old code, but we take everything into consideration and aim for stability. We did do a major overhaul of the APIs after the 0.4 release with a one-time lapse of our deprecation policy, and we tried to lump as many changes as we could into that release cycle to minimize the pain. This particular widget didn't make it in time. In fact, those two widgets were the only two widgets from the old 0.4 release that did not get a major rewrite for dijit, and they need it.

So we do have a policy in place for API stability. I should be able to cite something written... I'll look in the book. If it's not written up, we need to make sure it gets added to the book.

The roadmap is out of date indeed. Sorry. Rest assured, nobody is planning another 0.4->0.9 transition. We're focused on 'fit and finish' of 1.0 right now.

as of tonight's build (a couple of hours from now) I changed themeTester to use liveSplitters="false", which is the behavior we had previously. liveSplitters -- having the splitters interactively resize the content as you drag -- is of course much slower, and particularly slow with themeTester and the very high number of the widgets on the page. I suspect it was very slow with the old widgets also, perhaps even slower.

the mail demo uses liveSplitters, but with a simpler page, so the performance is tolerable on most browsers.

what you suggest is additive, and perhaps not limited to BorderContainer. You may wish to suggest it in trac or perhaps better yet in the dijit dev forum.

Check out themeTester.html for an example of a loading screen.

Not sure if it's practical to build that functionality into dojo/dijit because of the obvious catch-22 that it wouldn't be able to display the loading screen until dojo had finished loading (but I guess before the widgets instantiated).

http://trac.dojotoolkit.org/ticket/5689 I like 'collapsible'. Perhaps it would be as simple as saying 'collapsible=true' on one of the 4 edge panels? I guess the tricky part is what would the UI look like and how would it impact the layout.

We're announcing the deprecation of SplitContainer and LayoutContainer and the beginning of something new. Those old widgets will continue to be around (and haunt the Dijit development team) for at least another major release cycle... that could be a year or more!

Why replace the old widgets? Because we feel they are buggy, difficult to maintain, and frankly the code quality doesn't measure up to the standards of the Dijit project, which include using CSS more and making the code more concise. Take a look at the size of the SplitContainer module, and then compare with the _Splitter class in BorderContainer and you'll see what I mean. Rather than continue to invest in that code, a rewrite was deemed the best approach by the Dijit maintainers. SplitContainer and LayoutContainer are basically the only two modules which were not rewritten or redesigned for 0.9, and they really needed to be. This migration was supposed to be part of the 0.9/1.0 rewrite for Dijit, but it couldn't be contained within that schedule. I imagine that's what you're upset about, and I'm sorry, we just didn't have the resources to do everything we wanted to do. But, unlike the extremely painful 0.9/1.0 rewrite, we're following deprecation rules with this. We're focusing on making BorderContainer a performant, rich, and light-weight container and ask for your patience as well as your input.

There are many SplitContainer bugs marked open or wont fix in trac, which like everything we do (including the source control) is fully available for your browsing and searching pleasure. The matter was debated extensively in the development community in public irc meetings and on the mailing lists. Like a lot of development matters, these topics aren't secret but they don't typically get broadcast to the announcement blog until they're fleshed out. If that's a mistake, please accept my apologies and feel free to suggest a better way (but please, this is the wrong place to post if you want to have a real discussion with the community; as you'll see, I'm pretty much the only one following up because I posted the blog entry and I get e-mail updates)

As previously stated on this thread, the old widgets will not disappear overnight. If you wish to continue using the deprecated classes, you may do so. Improvements, however, will happen in the new widget, which is designed to interact better with Dijit. Also, as previously stated on this thread, sometimes API changes are going to happen. No, we don't plan a lot of changes like this in the future, and this one is fairly limited in scope. There will not be another 0.4-0.9 type migration any time soon. We take API stability seriously, keep changes to a minimum and follow the deprecation cycle we have pledged to.

Performance concerns are being looked at. We'll do everything we can to improve performance on IE, in particular.