Community
Participate
Working Groups
Simulation control buttons like Play, Pause and Stop are instanciated programmatically. In fact, it's their handlers that are instanciated. Handlers notify other handlers of state changes. This makes the execution GUI hard to extend. And I think, this is not the Eclipse-way to use handlers. A better way to update handlers would be using the observer pattern and listening to the runner lifecylcle. That way, enablement of handlers can be defined in the plugin.xml.
Hi Jonas, If I remember correctly, this was the only way to achieve the behavior we want. The problem is that declarative handlers cannot have their visibility and enablement state updated directly. I forget what the exact set of issues were, but there are some real limitations to the declarative approach. I just remember that I spent a lot of time getting this working well. Also, the semantics of what those buttons do is pretty deeply connected to the life-cycle stuff in IEngine and IModel -- I think this is analagous to say an Eclipse Job, where there are many advantages to having shared semantics for model control across all potential models. What sor of extension were you thinking of?
I need to reuse the agent execution perspective but with custom buttons and custom views. As long as those buttons and views are linked programmatically, they will appear automatically when I launch the EclipseRunner to execute a model. I think with the quite new ISourceProvider concept you'll be able to manage both, activation and enablement.
Committing proposed refactoring for Handlers and Commands, including tests.
OK cool! You're right, that Thanks for the fix. But.... we can't touch Ascape core directly. I'll explain why in an email.
I've reverted Ascape changes. Can we close this bug?
(In reply to comment #5) > I've reverted Ascape changes. Can we close this bug? Sounds good to me. It'll be nice to have this working in a cleaner way.
Actually why was this ever assigned to me? I'm closing and assigning back to you.
Oops. I guess it isn't working now. Must have something to do with backing the Ascape changes back out, because it is pause that is broken. What do you want to do about this? The old strategy was for the pause/resume buttons to handle their own state. Again, not necessarily the _best_ strategy. We could implement the engine control, though in this case as the pause button would only be listening for the result of what it had just done, I think it would be safe for the time being to just assume that state change has occurred. That way we also prevent someone from sending multiple pause signals.
One other issue I'm seeing. When there is a failure of some kind in the model the close button should still work..it will try to close gracefully and if that doesn't work force kill the thread. That doesn't seem to be working now.
(In reply to comment #9) > One other issue I'm seeing. When there is a failure of some kind in the model > the close button should still work..it will try to close gracefully and if that > doesn't work force kill the thread. That doesn't seem to be working now. Just committed a bug fix. I'm not quite sure if this really solves your problem. Could you affirm if it does?
(In reply to comment #8) > Oops. I guess it isn't working now. Must have something to do with backing the > Ascape changes back out, because it is pause that is broken. What do you want > to do about this? The old strategy was for the pause/resume buttons to handle > their own state. Again, not necessarily the _best_ strategy. We could implement > the engine control, though in this case as the pause button would only be > listening for the result of what it had just done, I think it would be safe for > the time being to just assume that state change has occurred. That way we also > prevent someone from sending multiple pause signals. With reverted Ascape changes, the Pause button is independent of all Ascape changes. It should get notifications anyway. Can you be more precise about the problem?
Never mind. Found it out myself, I think. I've just committed a bug fix. Tell me if this works for you. (In reply to comment #11) > (In reply to comment #8) > > Oops. I guess it isn't working now. Must have something to do with backing the > > Ascape changes back out, because it is pause that is broken. What do you want > > to do about this? The old strategy was for the pause/resume buttons to handle > > their own state. Again, not necessarily the _best_ strategy. We could implement > > the engine control, though in this case as the pause button would only be > > listening for the result of what it had just done, I think it would be safe for > > the time being to just assume that state change has occurred. That way we also > > prevent someone from sending multiple pause signals. > > With reverted Ascape changes, the Pause button is independent of all Ascape > changes. It should get notifications anyway. Can you be more precise about the > problem?
Introduced simulation end state as well. Seems like it's needed to disable for example the "step" button after simulation end.
OK, I'm having issues with restarting models. It's hanging a lot. Also, when a model crashes things are left in a bad state. On a crash the models should exit gracefully but it seems to just get locked up with the UI still activer even though there are't any jobs active.
Yes, I've notices the hanging behavior too. I'm not sure though if this is the correct bug to talk about this. We should probably open a new one. The hanging-problem is caused by a synchronized method. I think we got a deadlock there. Regarding the crash behavior you'll probably have to describe for me how to reproduce that. And also I think this should be a new bug except if you've already found out about a relation to the declarative way we're putting in the buttons in. (In reply to comment #14) > OK, I'm having issues with restarting models. It's hanging a lot. Also, when a > model crashes things are left in a bad state. On a crash the models should exit > gracefully but it seems to just get locked up with the UI still activer even > though there are't any jobs active.
(In reply to comment #15) > Yes, I've notices the hanging behavior too. I'm not sure though if this is the > correct bug to talk about this. We should probably open a new one. > > The hanging-problem is caused by a synchronized method. I think we got a > deadlock there. > > Regarding the crash behavior you'll probably have to describe for me how to > reproduce that. And also I think this should be a new bug except if you've > already found out about a relation to the declarative way we're putting in the > buttons in. I guess the reason I thought this is related (besides that it was working well recently, but we've made a number of other changes as well) is that with the declarative approach we can't really monitor a process in the same way. So when a job crashes it can't fix itself. I *think* this issues was solved before with the monitoring done in the model manager but I can't remember for sure. It does seem that we'd need some kind of monitor process to make sure that jobs had cleaned up after themselves properly.
