[kepler-dev] Kepler user interface + relation to Recito
Tim Van den Bulcke
tvandenbulcke at gmail.com
Tue Nov 20 08:10:32 PST 2007
Thank you all for the background information. I better understand the
issues involved now in such migration.
Tim.
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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20071120/af9b2601/attachment.html>
More information about the Kepler-dev
mailing list