[PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released

Hans-Christoph Steiner hans at at.or.at
Fri Jan 18 22:31:51 CET 2013


On 01/18/2013 04:14 PM, Jonathan Wilkes wrote:
>> ________________________________
>> From: Leandro da Mota Damasceno <lemota at gmail.com>
>> To: Jonathan Wilkes <jancsika at yahoo.com> 
>> Cc: Pierre-Olivier Boulant <po.boulant at free.fr>; pd-list <pd-list at iem.at> 
>> Sent: Friday, January 18, 2013 2:40 PM
>> Subject: Re: [PD] [announce] Integra Live 1.5 released
>>
>>
>> So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?
> 
> 
> Depends on which features of the interface you want to improve.  Ivica improved the logic
> that controls when scrollbars appear in a patch in Pd-l2ork, as well as more efficient
> movement and manipulation of iemguis.  However, stuff like gradients in a patch, zooming
> on a canvas, better handling of fonts, and many other issues require "messes" of code.
> 
> -Jonathan

It also depends on what you mean by "improve".  I personally want Pd's GUI to
look and act as native as possible on any given platform, and it turns out
that Tk is one of the better GUI toolkits for doing that.  Tk is quite slow
for raw drawing, so that's a problem.

If you want to go the path of IntegraLive, Max5, Live, etc. where they aim to
make the program look and act the same no matter which platform, then other
toolkits are better for that: GTK, Flex, JUCE, etc.

On that note, it would be fully possible to start right now to write a new GUI
for Pd using the toolkit of your choosing.  The communication from pd-gui to
pd is all Pd messages, so that's easy to generate in any programming language.
 The tricky part is pd talks to pd-gui mostly using Tcl code.

I would love it if someone started this since it would greatly help with the
goal of splitting the GUI from Pd itself.  And of course I'd help where I can.

.hc


> 
> 
>>
>>
>>
>>
>> On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>>
>>> ________________________________
>>>
>>>> From: Leandro da Mota Damasceno <lemota at gmail.com>
>>>> To: Pierre-Olivier Boulant <po.boulant at free.fr>
>>>> Cc: pd-list <pd-list at iem.at>
>>>> Sent: Friday, January 18, 2013 12:33 PM
>>>
>>>> Subject: Re: [PD] [announce] Integra Live 1.5 released
>>>>
>>>>
>>>
>>>> The GUI is beautiful!!!!! That's Apache Flex? I don't think we can maket tcl/tk look like that on PD, can we?
>>>
>>>
>>> It's not that you can't do that in tk, it's just that tk will get in the way of you doing that at nearly
>>> every turn.  For example, here's the code you'd need to draw a gradient on a canvas:
>>>
>>> http://wiki.tcl.tk/6100
>>>
>>> Buttons would have to be gifs or bitmaps created in some other program (or on the fly with some
>>> hacky code similar to the gradient stuff), unless you use tcl/tk 8.6 in which case you could use
>>> pngs.  You might be able to use the half-implemented tk theming engine to get a scrollbar that
>>> looks like the one in Integra, but you'd probably end up using pngs or something for the items in
>>> the Module Library, or else pull your hair out trying to figure out how to get the theme to look
>>> like that on all platforms when all platforms do _not_ have the same building blocks for their
>>> widgets.  For Pd'ers who like the stripped down, 1990s look it is serendipitous, because that is
>>> all they can get without someone doing an inordinate amount of work to make it
>>> look any other way.  (Just find a gui made with tk that looks anything like Integra.)
>>>
>>> But I do have a question about:
>>>
>>>
>>> http://www.integralive.org/
>>>
>>> Specifically, the png accompanying "Turnkey Audio Processing"-- specifically the outputs
>>> of GranularDelay1 going to the inputs of StereoReverb1.  Look quickly then answer the
>>> question:
>>> Does out1 connect to in1 or in2?
>>>
>>> I'm not against bezier curves, but the GUI engine must handle them with care or they'll cause
>>> unnecessary problems.
>>>
>>>
>>> Bezier curves make it more difficult for the user to anticipate ambiguous overlaps with cords.
>>> The user makes connections which are obvious in his/her mind as well as obvious when they do
>>> the physical work with the mouse of connecting each outlet to each inlet.  (Btw, the user's
>>> mouse makes a trip between outlet and inlet that is a straight line, so the physical action
>>> no longer correlates with the drawn representation.)  Then the mind tricks
>>> him/her into thinking that the GUI diagram must be as clear as the mental diagram because
>>> all the steps leading up to the final result were clear.  (This is still a problem in Pd, but slightly less
>>> so because the user is more likely to guess correctly what a straight line between a and b looks
>>> like, and they can consequently anticipate ambiguous overlaps and attempt to avoid them before
>>> making them.)  Then the user goes and teaches a class, or runs an errand, and comes back to the patch
>>> but the mental picture is now gone.  So he/she recreates the mental image from the GUI image,
>>> which is ambiguous, which requires either more work to remember the "real" connection or
>>> actually manipulating the GUI cord with the mouse to see what really connects to what.  Requiring
>>> either type of work breaks with the philosophy of being able to deduce what the patch does simply
>>> by looking at it.  (Btw, I'm still not sure whether your cords overlap or not.)
>>>
>>>
>>> So cords should try to repel each other in such a situation, or at least color themselves differently
>>> when they do in fact overlap.  Otherwise you end up with the equivalent of a scheme IDE that
>>> sometimes matches a closing parenthesis with two "candidate" opening parentheses but doesn't
>>> indicate which is the actual match.  Nobody would tolerate such an ambiguity in a text-based
>>> langauge.  We shouldn't in GUIs, either.
>>>
>>> -Jonathan
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 18, 2013 at 2:44 PM, Pierre-Olivier Boulant <po.boulant at free.fr> wrote:
>>>>
>>>> No problem about the report. :)
>>>>>
>>>>> I'm here if you need further testing too. Look me up on IRC freenode #dataflow. I'm "pob" over there.
>>>>>
>>>>> For what it's worth, the only interaction I have with the GUI is when closing. I can actually click on the buttons of the "save" pop up window.
>>>>>
>>>>> Cheers
>>>>> Pierre-Olivier
>>>>>
>>>>>
>>>>>
>>>>> On 18/01/2013 17:15, Jamie Bullock wrote:
>>>>>
>>>>> On 18 Jan 2013, at 15:48, Pierre-Olivier Boulant <po.boulant at free.fr> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> It looks very nice indeed.
>>>>>>>
>>>>>>> Running the Windows version, I have a problem with the mouse.
>>>>>>> I can't interact at all with the GUI. I can click on the menu bar (File Edit View etc.), this much works but that's it. The GUI does not respond to any clicks.
>>>>>>>
>>>>>>> Windows 7, 64bit OS.
>>>>>>>
>>>>>> I'm sorry to hear that. I must admit, we haven't yet tested on 64-bit Windows, so it's possibly to do with that.
>>>>>>
>>>>>> I hope you don't mind but I've added your report to the UserVoice forum:
>>>>>>
>>>>>>         http://integralive.uservoice.com/forums/58883-general/suggestions/3565091-mouse-interaction-not-working-on-64-bit-windows
>>>>>>
>>>>>> If you "vote" for the issue, you will get an automatic notification when it is resolved.
>>>>>>
>>>>>> Jamie
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pd-list at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-list at iem.at mailing list
>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 



More information about the Pd-list mailing list