[kepler-users] component gui

[Christopher Brooks]

Patrick,

There is an example in the ptII development tree that uses Python for 
GUI work.
Bob Weber sent me a model that I folded in as
$PTII/ptolemy/actor/lib/python/demo/RecordManipulation.xml
I've attached the model.

The Ptolemy II development tree also includes a draft system for laying 
out components
in a runtime window.  In the Ptolemy II development window, View -> 
Interface Window brings
up a run control panel that is editable.

We stopped work on this when we submitted changes to the underlying 
package and the author
said he was moving to Eclipse RCP.

To access the Ptolemy II development tree, see
http://chess.eecs.berkeley.edu/ptexternal

For information about Kepler and Python, see
https://kepler-project.org/developers/reference/python-and-kepler

There is also a thread at
http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/2011-November/002044.html
about Kepler and Python.

_Christopher

On 6/8/12 5:44 PM, Edward A. Lee wrote:
>
> As I said before:
>
> They aren't as limited as you think...
> If a parameter contains an attribute that subclasses
> ParameterEditorStyle, then that attribute controls
> how the interaction with the parameter is done.
> See the
> $PTII/ptolemy/actor/gui/style directory.
>
> In addition, you can completely customize the
> dialog that Configure Actor opens.
> See EditorFactory and its subclasses for examples.
>
> For an example, the PythonScript actor in the library
> opens a text editor when you select Configure Actor.
>
> Edward
>
> On 6/8/12 2:14 PM, Rohan Sadler wrote:
>> Hi Patrick,
>>
>> I was thinking the same thing today, and was having a look at 
>> wxPython. However, I am in the early days and so can't help you re: 
>> experience.
>>
>> At this point in time I am almost tempted to run Kepler from the 
>> command line: 
>> https://kepler-project.org/developers/reference/executing-kepler-from-the-command-line. 
>> The python/java GUI buttons would simply change default object 
>> assignments in the kepler/java script before running the project. 
>> There though should be a better way, as it would not be 
>> computationally smart to have two interpreters stacked on top of each 
>> other.
>>
>> re: other toolkits. The forthcoming book 
>> http://www.amazon.com/Programming-Graphical-Interfaces-Chapman-Series/dp/1439856826 
>> also enables learning GUIs for R.
>>
>> I agree with you. The bottom line is that there is a need for custom 
>> interfaces for endusers of the kepler workflow, as soon as the 
>> workflow gets complex. Most of my endusers are familiar with excel 
>> and that is it when it comes to software, and don't want to venture 
>> too far out. For example a technician typing in soil and plant 
>> parameters, before getting a soil water balance from Kepler. 
>> Something like RExcel means they can plug in numbers in a 
>> spreadsheet, and get their outputs. In a workflow this would mean that:
>> 1) Run the workflow in Kepler,
>> 2) An excel styled spreadsheet would pop-up, pre-populated with 
>> default parameters, and perhaps some pre-specified data [e.g. swing 
>> pulldown to source locally held weather station data].
>> 3) End user would type in their numbers, then press 'done'
>> 4) Kepler would continue to execute with the new information.
>>
>> Regards
>> Rohan
>>
>> Senior Scientist
>> Astron Environmental Services
>>
>> Adjunct Senior Lecturer
>> School of Agricultural and Resource Economics
>> The University of Western Australia
>>
>> ________________________________________
>> From: kepler-users-bounces at kepler-project.org 
>> [kepler-users-bounces at kepler-project.org] On Behalf Of Patrick 
>> Janssen [patrick at janssen.name]
>> Sent: Tuesday, 5 June 2012 8:54 AM
>> To: kepler-users at kepler-project.org
>> Subject: [kepler-users] component gui
>>
>> The GUI creation tools under the 'Configure Actor' (for creating 
>> custom interfaces for setting actor parameters) are limited (for 
>> example, no sliders, no drop down lists, no tabs, no free text, no 
>> layout constraints, etc). In particular, I find this an issue when 
>> defining complex Python actors with lost of different parameters. As 
>> a result, the interface can end up being a bit unfriendly for the end 
>> users of my actors.
>>
>> I am wondering -  what is the best way of overcoming this? Has anyone 
>> had any experience creating custom GUIs for actors using either Java 
>> or Python, for example using Swing or other toolkits?
>> _______________________________________________
>> Kepler-users mailing list
>> Kepler-users at kepler-project.org
>> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20120610/4b6f4126/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RecordManipulation.xml
Type: text/xml
Size: 22896 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20120610/4b6f4126/attachment-0001.xml>