[PD-dev] More gui-rewrite: Re: Pd-extended EOL?

Jonathan Wilkes jancsika at yahoo.com
Mon Jan 11 20:30:47 CET 2016


Hi Kaj,In the GUI port of Pd-l2ork I have about 18 sys_vgui calls left to revise.  At that point the tcl strings will be completely removed from the core of Pd-l2ork.
In practice, it's not really a process of changing tcl calls to pd message calls.  Tcl strings are more expressive than pd messages-- they allow you to specify arbitrary strings (e.g., the string may have spaces inside it) and (nested) lists of values.  Since the current code relies on those two features to communicate with the GUI, porting everything to a less expressive message format is a really bad idea.  You'll either end up jumping through hoops to deal with all the edge cases, or coming up with your own syntax for strings containing arbitrary characters and list/array boundaries (at which they are no longer Pd messages).
I used pd_vmess as a model and just parameterized the messages to the GUI.  That means I have only a handful of functions in one place where I can choose exactly how the commands look when they get sent over the wire.  That way even if I chose the worst possible design, fixing it is just a matter of changing the guts of those few functions instead of having to refactor every single call to the gui throughout all of the core.
-Jonathan
 

    On Monday, January 11, 2016 6:08 AM, Kaj Ailomaa <zequence at mousike.me> wrote:
 

 On Sun, Jan 10, 2016, at 11:59 AM, Kaj Ailomaa wrote:
> 
> 
> On Tue, Nov 10, 2015, at 07:53 PM, Jonathan Wilkes via Pd-dev wrote:
> > > * convert this to a pd message one at a time
> > If anyone wants some advice on how to do this in practice, PM me.
> > -Jonathan
> > 
> >      On Tuesday, November 10, 2015 10:01 AM, Hans-Christoph Steiner
> >      <hans at at.or.at> wrote:
> > Its been too long for me to give much detail, I definitely wrote about
> > this
> > multiple times, so check the archives.  This is not a great setup, but it
> > is
> > necessary because pd sends drawing commands with pixel values to pd-gui. 
> > But
> > I remember it was something like this:
> > 
> > * set [tk scaling 1] on all platforms
> > * measure the boxes a lot, on various platforms and versions
> > * fix when the pixel values are different
> > 
> > The real way to fix this is to make pd know as little as possible about
> > the
> > GUI stuff, then things can be handled much better in pd-gui.  If you are
> > going
> > to put work into this, the best approach is also a more incremental
> > approach.
> >  This approach will also easily give Pd a scalable GUI.
> > 
> > * look for any sys_vgui() call in pd that sends raw Tcl
> > * convert this to a pd message one at a time
> > * push the logic to pd-gui as much as possible
> > 
> 
> Hi Jonathan, and everyone else!
> 
> I would be interested in working on the gui stuff. 
> I was just trying to do some theming and tried applying the color scheme
> part of pd-extended as a patch to vanilla. It kind of worked, but it was
> just a first attempt. Anyway, I would very much like to do more of this,
> so please give me some hints.
> 
> Scaling would be awesome.
> 
> /Kaj Ailomaa
> 

I was looking for an example (using grep) where sys_vgui() sends pd
messages instead of tcl commands to find an example, and this was pretty
much it:

./s_print.c:        sys_vgui("::pdwindow::post {%s}\n",
strnescape(upbuf, s, MAXPDSTRING));
./s_print.c:        sys_vgui("::pdwindow::logpost {%s} 1 {%s}\n",
./s_print.c:        sys_vgui("::pdwindow::logpost {%s} %d {%s}\n",

So, that looks easy enough. But, I still have very loose grasp on
everything to do with pd programming. So, there's really a lot for me to
understand. I will need to have a look at pd messages, which ones I
should use, and if I need to create new ones.
Also, how do I actually create an object in the correct patch window
using tcl.
An example of this would be nice, and would allow for me to do some work
right away - at least for testing and getting better acquainted with the
code.

/Kaj

_______________________________________________
Pd-dev mailing list
Pd-dev at lists.iem.at
http://lists.puredata.info/listinfo/pd-dev


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20160111/c4038266/attachment.html>


More information about the Pd-dev mailing list