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@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.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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev