Hello! This is my weekly ChangeLog, from 4 March 2019 to 10 March 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=4/3/2019&to=10/3/2019 ChangeLog ========= 6 March 2019: ------------- * I spent last two days trying approaches to make the introduction of +Application+ concept less intrusive. Thing is, since several applications can be alive at the same time (in general at least two: Pharo and the application the user is developing, but there can be more), when you create a window, is mandatory to know the application it belongs to. And this is a problem. Why? Well, because there are two ways to do it: It can be: ---- MyWindowClass newApplication: myApplication. ---- or: ---- myApplication new: MyWindowClass. ---- And well... both approaches require that you are in possesion of an application when you create a window. In an application of certain complexity (not to talk about Pharo complexity itself), this can be a problem (hello, singletons!). I explored the approach of having one active application at a time... but what happens when you are running application A and you need to pop a debugger? How to choose the right application? After some consideration, I came to the conclusion that is not possible, and that decision needs to be binded to the development itself. So, how to solve this? Is a matter of each application. * It is possible for some applications to pass the application between components. One can arwe UI decisions need to be taken at UI level, and is fine to have the application available at that level. * Is possible to have *for your application* a "runningApplication"... a class variable in your SpecApplication override. This is a singleton, yes, but sometimes you need it... Maybe Pharo will go this way. 4 March 2019: ------------- * Today I completed the first step on the introduction of +Application+ for Spec2. As we have told, an application is the entry point of any Spec Application. It will handle the creation and flow of windows and the resources used by it (long term goal: no more UIManager, UITheme, ThemeIcons and other singletons that pollute the system). Anyway, for now I just managed to introduce a generic application and refactored the +ComposablePresenter+, extracting the window functionality from them and moving it to a default +Application+. It sounds simple, but it was a big change. A diagram of how this has changed: ---- Before: ComposablePresenter -> WindowPresenter \ ComposablePresenter* ---- ---- Now: Application -> WindowPresenter -> ComposablePresenter -> ComposablePresenter* ---- This way of handling windows allows a tight control of what is open and in what order, and a way to handle resources other tghan a singleton in the system. cheers! Esteban