[kepler-users] component gui

[Edward A. Lee]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 330 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20120608/19c94f37/attachment.vcf>