It might be a good idea to list the problems with tcl/tk so we can weigh them
against the difficulty of using a different GUI toolkit. The problems I see
are:
* difficult to implement a decent zoom function for a canvas
* can't display png without the Img library (included in 8.6)
* can't do alpha transparency
Of the three I listed, I'm mostly interested in the first as it means that
(without prior planning) it's hard to take a patch you've been working on at
font size 10 and display it adequately over a projector, for example. (If
there's a work around I'd like to know it.)
I'd like to hear others, but I'm mostly interested in problems with tcl/tk >=
8.5 as the GUI.
>________________________________
>From: András Murányi <[email protected]>
>To: pd-list <[email protected]>
>Sent: Thursday, August 25, 2011 8:19 PM
>Subject: Re: [PD] [PD-dev] tkwidgets
>
>
>Yeah and afaiu this is exactly the job that HC just started (see his
>announcement below).
>Yvan: in my simple understanding it goes like this: 1. getting rid of
>tcl-specific code in pd c core 2. minimizing the communication between the
>core and the gui (3. defining the api/protocol?) 4. anyone can go make all
>sorts of guis for pd... at this point or later on vanilla may or may not
>switch from tcl - imho it's to be decided when we're there
>
>Andras
>
>
>On Fri, Aug 26, 2011 at 01:39, Jonathan Wilkes <[email protected]> wrote:
>
>The pd/pd-gui divide is a little misleading-- there are lots of places in the
>c code where there are sys_gui and sys_vgui calls with tcl in them, plus c
>code that probably assumes tcl is being used on the gui side.
>>You'll either need to write a wrapper for those calls, or modify a lot of c
>>code and basically make a fork (iemguis, canvas stuff, etc.)
>>
>>But even if you write a wrapper, there are still issues that will need to be
>>dealt with on the c side to minimize the number of messages passing back and
>>forth between pd and gui. For example, there is one call per xlet to the gui
>>when an object gets instantiated/vis'd, plus drawing the border and text,
>>rather than one call per object (and letting the gui deal with where to draw
>>xlets, box width, font,
etc.).
>>
>>-Jonathan
>>
>>
>>>________________________________
>>>From: yvan volochine <[email protected]>
>>>
>>>To: Hans-Christoph Steiner <[email protected]>
>>>Cc: Jonathan Wilkes <[email protected]>; pd-dev List <[email protected]>
>>>Sent: Thursday, August 25, 2011 6:18 PM
>>>Subject: Re: [PD-dev] tkwidgets
>>>
>>>
>>>On 08/17/2011 08:54 PM, Hans-Christoph Steiner wrote:
>>>> I've started a private git branch of
>>>> tkwidgets
that I intent to push once I get somewhere with it. The idea
>>>> is to try out a new idea for how GUI objects can work. Basically, I
>>>> think I can make it so that Tcl handles more of the interaction with the
>>>> user, minimizing on pd-gui <--> pd communications, and making it easier
>>>> to write GUI objects. Its not trivial to do, but should be doable.
>>>
>>>hiho
>>>
>>>sorry for bumping in but what about giving up tcl-tk and go on with
>>>something more "modern" (à la Qt), with a decent OO interface ?
>>>
>>>I might miss the obvious as I'm new here but what about rewriting pd GUI in
>>>Qt ?
>>>wouldn't it make more sense than spending time hacking on and on tcl-tk code
>>>?
>>>
>>>my 0.001$
>>>_y
>>>
>>>
>>>
>>
>
>_______________________________________________
>[email protected] mailing list
>UNSUBSCRIBE and account-management ->
>http://lists.puredata.info/listinfo/pd-list
>
>
>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
