Interesting about QtJambi. I think Sun blew it with AWT. Too bad they did not use Tk, which basically worked. They had John Ousterhout, father of Tcl/Tk at Sun Labs at the time. Ah well.
I believe you are right about extending CompositeEntity. The original design decisions are lost in the sands of time. I believe it is because we wanted to have multiple entities inside. Yes, you could say that the doc file and python file are "models" in this context they define relationships between data. The Effigy classes are our interface to the models, and the Tableaus are the viewers About Model View Controller (MVC) http://www.mail-archive.com/ptolemy-hackers@eecs.berkeley.edu/msg01020.html says: > Right, the Effigy/Tableau design pattern is a little complex. > Effigy is another word for Model and Tableau is another word for View > Effigy was chosen so that we could avoid confusing Ptolemy models > with GUI models. _Christopher -------- Christopher Brooks wrote: > JS writes: > >> Hi, >> >> We're currently digging into PtII GUI classes to try to build our own >> GUI for Drone (http://drone.ws). Our first objective is to be able to >> list available models and show a tree view of the currently loaded model >> in our GUI (we're not using diva/vergil but AWT and QtJambi). >> > > I'm interested as to why you would choose AWT over SWT? > I don't know anything about QtJambi . . > Using anything under the EPL license would prevent us from releasing under the GPL. We want to release under the GPL because (1) we want to be able to use GPL code and (2) since we're not a business but individuals working with very few resources, the GPL will protect us better that the EPL license. QtJambi is Qt's port to Java. Right now it's only in a pre-release state, with closed license, but it will soon become GPL as is Qt (well, probably dual-licensed acutally): http://www.trolltech.com/developer/downloads/qt/qtjambi-techpreview >> We have >> read about core ptolemy.actor.gui classes such as: >> - Effigy >> - Tableau >> - ModelDirectory >> - Configuration >> - EntityLibrary >> - UserLibrary >> >> We have documented our findings on our wiki: >> https://lethe.koumbit.net/trac/drone/wiki/DevNotes/PtolemyII-Architectur e >> >> Here are a few questions we would like to ask: >> >> 1) Why are so many classes in the package extending CompositeEntity >> (instead of NamedObj)? Is it because NamedObj does not offer iterating >> over anything else than attributes? It seems odd that, for instance, we >> were able to open the EntityLibrary in Vergil and Look inside. >> > > NamedObjs don't contain multiple composites, so that is why we use > CompositeEntity. > > The Effigy/Tableau architecture was a bit of an experiment. One > aspect is that it uses the Ptolemy classes to configure itself. > This results in a certain amount of confusion and also things > like being able to open an EntityLibrary. > We are a bit worried about this and will look into it to try to find an architectural compromise between copying functionalities from CompositeEntity and extending it as is currently done. Am I right if I say that the reason why you extended CompositeEntity in these classes is to be able to have Entity container functionalities in those classes? >> 2) How is the adding of Director handled (i.e. when I click and drag a >> Director into a graph/tableau what are the classes involved in adding it >> to the current CompositeActor)? >> > > The short answer is that a bunch of classes are used :-) > > Sorry. The details are tricky. > Have a look at ptolemy/vergil/tree/ and the PTree class. > > BTW PTree has code where we prevent the user from dragging > EntityLibraries on to the canvas: > > if (path.getLastPathComponent() instanceof EntityLibrary) { > //this prevents a user from dragging a folder. > return; > } > > Well, yes, this is not very clean indeed. But it works :) >> 3) If an Effigy is a metadata over a model, why are there such effigies >> as DocEffigy or PythonShellEffigy? Maybe we don't understand very well >> what a model is. >> > > DocEffigy and PythonShellEffigy are representatives of a doc file and > a Python shell. > > For example ptolemy/configs/extendedEffigyFactories.xml > contains > <entity name="DocViewer" class="ptolemy.vergil.actor.DocEffigy$Factory" /> > > which registers the DocEffigy$Factory as a view of Doc files. > (In this context, Doc files are the Ptolemy documentation files that > document actors.) > > Ok. So doc file and python shell are models? > The Factory inner class has a createEffigy() method that looks at the > file extension and reads part of the file looking for the appropriate > xml header. If it finds the header then a DocEffigy is created and > returned. If it does not, then createEffigy() returns null, and then > the next viewer in the list from extendedEffigyFactories.xml is tried. > > If you are confused by all of this, then don't feel bad, it is > fairly confusing at first. The bottom line is that we use Ptolemy > to configure Vergil and it works out. It is model/view/controller > with different names. > Okay, so let me guess the names: - Model -> ModelDirectory - View -> Tableau - Controller -> listeners (e.g. ChangeListener) > _Christopher > > >> Thanks, >> >> -- >> J. S. Senécal >> http://drone.ws >> >> >> >> ------------------------------------------------------------------------ ---- >> Posted to the ptolemy-hackers mailing list. Please send administrative >> mail for this list to: [EMAIL PROTECTED] >> > > > -- J. S. Senécal http://drone.ws --------------------------------------------------------------------------- - Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED] -------- ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
