GUI For Insckape Script Extensions
I noticed the attached slide on Ted's presentation on Inkscape extensions. In the python example available online I see how to use the automatic GUI for scripts to collect text or String data. Can someone point out some examples or documentation that explains how to set up an automatic GUI for a script that uses enumerations or radio buttons?
Would it be possible to use PyGTK from within an Inkscape extension script?
Thanks for the help.
Scott Huey
I forgot to attach the screenshot of Ted's slide to my previous e-mail about automatic GUI creation for extensions scripts. I do apologize.
The screenshot is attached to this e-mail.
Thanks again for any help.
Scott Huey
On 10/4/07, Redefined Horizons <redefined.horizons@...400...> wrote:
I noticed the attached slide on Ted's presentation on Inkscape extensions. In the python example available online I see how to use the automatic GUI for scripts to collect text or String data. Can someone point out some examples or documentation that explains how to set up an automatic GUI for a script that uses enumerations or radio buttons?
Would it be possible to use PyGTK from within an Inkscape extension script?
Thanks for the help.
Scott Huey
On Thu, 2007-10-04 at 16:23 -0700, Redefined Horizons wrote:
I forgot to attach the screenshot of Ted's slide to my previous e-mail about automatic GUI creation for extensions scripts. I do apologize.
The screenshot is attached to this e-mail.
That screenshot is from the attached INX file. I use it for testing parameter changes. There are many more that use enums and other though. You should look through the INX files in Inkscape:
/usr/share/inkscape/extensions/
Would it be possible to use PyGTK from within an Inkscape extension script?
Not yet, but it is planned.
--Ted
Would it be possible to use PyGTK from within an Inkscape extension script?
Not yet, but it is planned.
Funny you should mention this kind of technology, my dohickey project (python/gtk) employs automatic field branching all data is stored as xml too, which is quite unique and it may be something you can use the ideas from.
The premise is simple: Not all fields are available to fill in.
Instead some fields only become available when either boolian (checkboxes) or lists (dropdowns) have specific values, causing the appearance of more values. each further set of child fields has the same functionality as the parents and all data derived from the structure is passed along as a flat hash/dictionary.
Do I make sense?
Best Regards, Martin Owens
On Oct 4, 2007, at 6:10 PM, Martin Owens wrote:
Funny you should mention this kind of technology, my dohickey project (python/gtk) employs automatic field branching all data is stored as xml too, which is quite unique and it may be something you can use the ideas from.
The premise is simple: Not all fields are available to fill in.
Instead some fields only become available when either boolian (checkboxes) or lists (dropdowns) have specific values, causing the appearance of more values. each further set of child fields has the same functionality as the parents and all data derived from the structure is passed along as a flat hash/dictionary.
Do I make sense?
Have you look at XForms at all?
There's a good O'Reilly book on it free online at http:// xformsinstitute.com/essentials/.
The "relevant" property and "xforms-enabled" and "xforms-disabled" events relate to hidden/visible enabled/disabled values and widgets.
participants (4)
-
Jon A. Cruz -
Martin Owens -
Redefined Horizons -
Ted Gould