My first deep dive into e4 application model
After some time of observing he progress of e4 application framework development and reading some fine high level documentation and fidgeting with some of its samples and creating few toy projects, I decided to dive in at the deep end so to speak and try it out with somewhat more serious and concrete project.
I am trying to implement a proof-of concept of an application that among other things needs at startup dynamically create a set of windows (one per each monitor) and go full screen with all of them.
Reading the implementation of E4Application (I must admit it is quite an interesting and educational excercise in itself) I found that I need to define a "Lifecycle handler" and intercept "processAdditions" lifecycle event to dynamically create new windows after the model has been loaded.
At first I was struck by an apparent problem where I needed an access to a Display instance. At first I simply tried and to add it as an argument to my processAdditions method but it produced quite an ugly exception as the IEclipseContext did not hold a reference to the current/context display (the exception message could probably use a bit more intelligence when pointing at the most likely cause of the issue).
I worked around it by intercepting "postContextCreate" lifecycle event and injecting a context function that returns current thread's display if it exists (by calling Display.getCurrent()).
I could safely do that because I had the internal knowledge that the life cycle events are intercepted on the same thread as the display creation and that the display is created right at the beginning of the E4Application.start() method.
It seems to me, it would probably be better, if the display is injected into the context as part of the context creation by the E4Application instead.
The actual process of adding new MWindow instances to the model using standard EMF model factory class was quite easy from this point and I could almost fully control every aspect of all the windows. I say almost, because one attribute that was out of my reach at this point was the fullScreen toggle.
All in all, I am fairly pleased with the relative ease and flexibility, e4 provides to me. The variety of ways I can intercept the start-up sequence and initialization of my application is amazing.
At first I was kind of hesitant that I would have to use someone else's implementation of IApplication. It seemed somewhat restrictive, but after looking at the internals of an E4Application I found that I had all the necessary hooks available to me and there was hardly any reason to write my own.
I am trying to implement a proof-of concept of an application that among other things needs at startup dynamically create a set of windows (one per each monitor) and go full screen with all of them.
Reading the implementation of E4Application (I must admit it is quite an interesting and educational excercise in itself) I found that I need to define a "Lifecycle handler" and intercept "processAdditions" lifecycle event to dynamically create new windows after the model has been loaded.
At first I was struck by an apparent problem where I needed an access to a Display instance. At first I simply tried and to add it as an argument to my processAdditions method but it produced quite an ugly exception as the IEclipseContext did not hold a reference to the current/context display (the exception message could probably use a bit more intelligence when pointing at the most likely cause of the issue).
I worked around it by intercepting "postContextCreate" lifecycle event and injecting a context function that returns current thread's display if it exists (by calling Display.getCurrent()).
I could safely do that because I had the internal knowledge that the life cycle events are intercepted on the same thread as the display creation and that the display is created right at the beginning of the E4Application.start() method.
It seems to me, it would probably be better, if the display is injected into the context as part of the context creation by the E4Application instead.
The actual process of adding new MWindow instances to the model using standard EMF model factory class was quite easy from this point and I could almost fully control every aspect of all the windows. I say almost, because one attribute that was out of my reach at this point was the fullScreen toggle.
All in all, I am fairly pleased with the relative ease and flexibility, e4 provides to me. The variety of ways I can intercept the start-up sequence and initialization of my application is amazing.
At first I was kind of hesitant that I would have to use someone else's implementation of IApplication. It seemed somewhat restrictive, but after looking at the internals of an E4Application I found that I had all the necessary hooks available to me and there was hardly any reason to write my own.
Comments