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. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.