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
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.
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:
ComposablePresenter -> WindowPresenter
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.
On Mon, 11 Mar 2019 at 15:00, <[hidden email]> wrote:
Really random thought... If somehow a window is created without it knowing the application,
could it create a new application for it - it occurs to me it might be called an "anonymous application"
but I've no idea if that makes sense within the framework, and too many random applications might be unmanageable.
P.S. Thanks for these ChangeLogs. Great to see whats in the pipeline.
That’s what happens now: they are assigned to an “NullApplication”. But this means you cannot track flow, etc… so at the end this should not happen (even if for now is good to allow migration of things).
|Free forum by Nabble||Edit this page|