[kepler-dev] Kepler user interface + relation to Recito
Edward A. Lee
eal at eecs.berkeley.edu
Wed Nov 21 10:57:51 PST 2007
This idea is quite interesting.
There are a couple of mechanisms in the Ptolemy core that support
something like this. These may be worth looking at just for ideas
(or critique!).
MessageHandler is non-graphical class that handles all error messages
(like exception reports). By default, all such reports go to stdout
and stderr. Vergil overrides this by registering a GraphicalMessageHandler.
Also, the listener mechanisms (e.g. DebugListener) have this flavor...
Edward
At 03:53 PM 11/19/2007, Matthew Jones wrote:
>Hi Edward,
>
>You're absolutely right about the ptolemy core packages not depending on the UI. That is an excellent feature, and one which we have used many times to run ptolemy stand-alone (in CGI scripts, web portal environments, the nightly build, etc).
>
>It does have its limitations though, such as not being able to use components that have graphical output when running in batch mode, or not being able to detach from a running model that one started within vergil, or not being able to monitor the UI output of workflows that have been distributed across many different computing nodes. These issues are due to the dependency of the UI (vergil) on the ptolemy core.
>
>Thus, the separation that I was referring to is one in which the user interface need not depend on ptolemy core. We will be discussing how the UI events that are generated by an executing model that would normally be tightly bound to particular actors (e.g., the Display actor, or the XYPlot) would instead be emitted via a messaging API that one or more clients can subscribe to. Thus, if the Display actor outputs lines of text to be shown to the user, in batch mode, with no client subscribers, those events would simply not be sent anywhere. However, a textual client could subscribe to those events and write them to a console or log file. Or a graphical client could subscribe to the events and show the messages in a window. These client decisions as to what to do with the messages in order to display them to the user would be independent of the ptolemy core. There wouldn't necessarily even be a need to have the clients be written in the same language as the engine, although for practical reasons it may be more realistic to assume that the client has a java layer to receive the messages (e.g., so that RMI could be leveraged).
>
>You made some good points about Eclipse.
>
>Hope this clarifies my earlier message.
>
>Matt
>
>Edward A. Lee wrote:
>>A couple of points:
>>- We have always carefully architected the Java classes in the
>> Ptolemy core packages to not depend on the UI, so all of the
>> things you propose for separating execution from the UI should be doable.
>>- I use Eclipse with Ptolemy II all the time, and find the ability
>> to develop Java classes (actors, etc.) and have them automatically
>> update in the running vergil extremely useful. Setting breakpoints
>> is also extremely useful. But all of these tasks are code development
>> tasks, not model development tasks.
>>- A tighter Eclipse integration supporting model development
>> could be very attractive, but there is a potentially huge job.
>> In particular, Eclipse does not integrate well with the AWT, so
>> all the underlying graphics support in vergil, the plotters,
>> the dialog boxes, etc., would have to be redone. This is a
>> very big job. Is it worth it?
>>- One argument for using Eclipse is to get the one-window style
>> of interface, vs. the multi-window interface currently used in
>> Kepler and Vergil. However, this can be accomplished by a more
>> modest effort. There is a good starting point already available.
>> Invoke vergil -single, and you get a tabbed pane interface where
>> all the models you open end up in the same window.
>>- An Eclipse interface would not make a good interface for the model
>> _user_ (vs. model developer and code developer). Or, more precisely,
>> I would be hard pressed to figure out how to use Eclipse effectively
>> for that purpose.
>>So I would caution against deciding for an Eclipse interface just
>>because Eclipse is cool (which it is). It requires some careful thought about
>>both cost and benefits.
>>Edward
>>At 10:38 AM 11/19/2007, Matthew Jones wrote:
>>>Hi Tim,
>>>
>>>We have met the Recito developers at last year's miniconference, but we were not involved in what they did. Our plans under Kepler/CORE for a new UI are more centered around a clean messaging API separating the user interface from the execution engine. We are motivated by some use cases having to do with long-running workflows: the need for workflows to be able to be executed on various machines, the need to be able to launch the GUI to start a job, quit the UI but keep the workflows running in the background (we call it "detached execution") and then reconnect the UI later to monitor progress, and the desire to support multiple different UI clients (e.g., Vergil, eclipse-based, and web-based).
>>>
>>>As Kepler/CORE is just starting, we have not yet collected requirements nor designed the API. This would be done in conjunction with the community to try to determine what architecture would serve us best. Many people have spoken of an Eclipse UI, and so I think that would be high on the list of client environments that we would want to support, although it would be a lot of work to develop a new UI from scratch, so I'm not sure whether that would happen in the first pass -- more likely a refactoring of the current engine/vergil to make it so that they are better separated, allowing groups like the Recito team the ability to utilize the new messaging API in their eclipse client.
>>>
>>>Matt
>>>
>>>Tim Van den Bulcke wrote:
>>>>Hi,
>>>>
>>>>I have been following the evolution of Kepler for a while now and I am very enthousiastic with the projects that are currently being started such as Kepler/CORE.
>>>>
>>>>I have seen that there exists another project called "Recito" (http://www.sp-process.it/index.php?option=com_content&task=view&id=23&Itemid=55) which provides an eclipse-based user interface to Ptolemy and has some additional actor libraries.
>>>>- What is their relation to the Kepler development team?
>>>>- Are there plans to migrate the Kepler user interface to an eclipse-based environment (which would be a great enhancement in my opinion)?
>>>>
>>>>In Kepler/CORE a standalone GUI will be developed, is it the intention to base this on Recito or will this be done independently?
>>>>
>>>>Thanks a lot for your answers!
>>>>
>>>>Tim.
>>>>
>>>>
>>>>
>>>>--
>>>>_______________________________________________________
>>>>ir. Tim Van den Bulcke
>>>>PhD candidate
>>>>
>>>>ESAT-SCD
>>>>K.U. Leuven
>>>>Kasteelpark Arenberg 10
>>>>B-3001 Leuven (Heverlee)
>>>>Belgium
>>>>
>>>>room: 03.11/14
>>>>tel: +32 16 32.86.43
>>>>fax: +32 16 32.19.70
>>>>email: tim.vandenbulcke at esat.kuleuven.be
>>>>homepage: http://homes.esat.kuleuven.be/~vdbulcke/
>>>>personal homepage: http://timvandenbulcke.objectis.net
>>>>_______________________________________________________
>>>>
>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>_______________________________________________
>>>>Kepler-dev mailing list
>>>>Kepler-dev at ecoinformatics.org
>>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>--
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>Matthew B. Jones
>>>Director of Informatics Research and Development
>>>National Center for Ecological Analysis and Synthesis (NCEAS)
>>>UC Santa Barbara
>>>jones at nceas.ucsb.edu Ph: 1-907-523-1960
>>>http://www.nceas.ucsb.edu/ecoinfo
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>_______________________________________________
>>>Kepler-dev mailing list
>>>Kepler-dev at ecoinformatics.org
>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>------------ Edward A. Lee
>>Chair of EECS and Robert S. Pepper Distinguished Professor
>>231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
>>phone: 510-642-0253, fax: 510-642-2845
>>eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Matthew B. Jones
>Director of Informatics Research and Development
>National Center for Ecological Analysis and Synthesis (NCEAS)
>UC Santa Barbara
>jones at nceas.ucsb.edu Ph: 1-907-523-1960
>http://www.nceas.ucsb.edu/ecoinfo
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
------------
Edward A. Lee
Chair of EECS and Robert S. Pepper Distinguished Professor
231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
phone: 510-642-0253, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html
More information about the Kepler-dev
mailing list