On 2013-09-26, at 12:29, "Sean P. DeNigris" <s...@clipperadams.com> wrote:
> We have FileDialogWindow, which is a cool little class which implements all > the cool things you may want to do when selecting a file, for example: > - answer either a directory, file, file entry, etc. > - set an initial directory > - set the sorting block > > Life is good. > > <rant> > Then, we take the entire domain of opening files and cram it into UITheme's > chooseXyzFileAbcIn:j:k:l: methods. UITheme is also a nice little class... > with 570 instance methods... wait, wth! Okay, but forgetting polymorph's > design for a moment... > > Then, we take the handful of options that UITheme gives us and funnel those > through UIManager, which exposes... 3. > > So out of the entire domain of selecting files, we have three safe options > available. > > This doesn't seem to work. > </rant> > > Naively, it seems to me that much of the original power could be retained if > things were reversed a bit. For example, instead of implementing file > selection functionality in three places (FileDialogWindow, UITheme, and > UIManager), could we do: > > 1. FileDialogWindow implements the API for selecting files > 2. UITheme only returns an appropriately-themed object (wth are "services" > doing in UITheme anyway?!) > 3. UIManager subclasses return either (via e.g. "UIManager default > fileDialogWindow"): > a) The themed object > or > b) a Dummy object that no-ops #1's API > > I'd be willing to give it a try if any of that sounds promising or if > someone has a better idea. Just image that the UIManager should also work on the CommandLine, everything else I couldn't agree more ;). Returning any window on UIManager is wrong I think, we should only define the request interface there. Of corse the MorphicUIManager can have its internal helper method to return the request window to lower the load on UITHeme.
signature.asc
Description: Message signed with OpenPGP using GPGMail
