dijit.Dialog: To fork or not to fork!

I've been redesigning the Memorati™ user interface to be based on pages and dialogs. Formerly it consisted of a collection of mutually exclusive pages (meaning no dialogs):

• Browse Cards
• Add Card
• View Card
• Quiz
• Settings

These pages were all accessible at any time from a menu on the left sidebar.

In the new UI, what was formerly "Browse Cards" will become the "Dashboard" with links/buttons for all other functionality. All the rest except for "Quiz" will become dialogs (although, maybe "Quiz" should be a dialog too? Eh?).

While this does complicate navigation a little by removing random access (ie: You can't jump directly from "Add Card" to "Quiz". You must first close "Add Card"), I think its an overall win. I have the following goals in mind:

• Eliminating the left sidebar: This makes the display much more attractive on mobile devices with limited screen width.
• Reducing the number of clicks to get started: In the current Memorati, you must (1) go to the home page, (2) click "Login" for the login page, (3) login, and finally, (4) click "Browse Cards". With the Drupal make-over I'll be putting a login form directly on the front page and forward you directly to the "Dashboard" on succesful login.
• Closing the metaphor: While the previous UI used "pages", you really never left the same page. The URL is adjusted (beyond the pound "#" symbol, to avoid browser refresh), the contents of the former page is hidden and contents of the next one is exposed. This brings the UI metaphore slightly closer to what is actually going on and makes it really feel more like an application.

So redesigning we go!

My first reaction (as a dojo and dijit user) is to use the dijit.Dialog. However, it does 2 things that I don't want:

1. Its freely movable. Not only, do we not need this at all but it doesn't work right.  I'm assuming this is because of the complex JavaScript layout stuff going on inside our card editor widget contained in the dialog.
2. It positions itself to the center of the screen. This simply doesn't look right. What we want is for it to position itself centered to the size of the content area of the page its on.

In the current Memorati development branch, I forked my own copy of dijit.Dialog that does what I want. Looks great! However, not understanding the code, I gutted all the complex accessibility stuff. Uh-oh.

Now, I could learn this code and port it into my fork. Or I could patch dijit.Dialog to behave the way I want. Or I could make a sub-class of dijit.Dialog with modified behavior. The last is really the most tempting, except this would depend on private implementation details that I only know because I read the code. Updates could easily break it.

Creating a patch against dijit which adds these features would be fantastic.  But what if they don't want to integrate it upstream? Certainly my functionality isn't universally desirable. I'd have to make it easily configurable/extendable. I could, of course, maintain my own private patch, but thats basically the same as my sub-class option: easily broken by a newer version of dijit.

The only sure fire not-breaking-with-new-dijit solution is to fork. But then I lose all the well tested accessibility and any benefit from future dijit improvements.

Probably what you're thinking is, "Why are you getting so philosophical about a stupid dialog?  Just do something already!" Well, I seem to find myself repeatedly in this situation with dijit. I had to override large parts of the grid to get it to work the way I want.  This will likely break with the next major version of the grid.

I'm trying to balance the following:

• Taking advantage of the hard work that other people (the dijit team) have done, but
• Customizing everything to work the way I want, while
• Minimizing the long-term maintenance I have to perform on my customizations.

It may be dijit.Dialog today but it'll be the next widget tommorrow! So what should I do? I don't want to maintain my whole own widget-set.  And I don't want huge porting pain at every major new release.  But I can't just use the default behavior because the usability of my application matters!

I'll let you know what I decide.  Input is welcome!