So if we wanted to improve the GUI we would have to drop tcl/tk all together or make it messy and heavy?


On Fri, Jan 18, 2013 at 5:26 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:
>________________________________

> From: Leandro da Mota Damasceno <lemota@gmail.com>
>To: Pierre-Olivier Boulant <po.boulant@free.fr>
>Cc: pd-list <pd-list@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@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@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@iem.at mailing list
>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>
>_______________________________________________
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>