[PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available

[Ivica Ico Bukvic]

> Curiously, I would have said exactly that about your fontsize thing. I
> would say that true zooming is the only way to go, and anything else
> distracts by creating bigger complications.

Well, code-wise it is not. I simply change font size and automate stretch values and don't worry about GOP objects because GOP design is in part conceived around specific pixel size. Resizing them could potentially wreak complete havoc on the organization of visual data inside them.

To complicate matters further, tcl/tk treats canvas text differently than canvas objects (vectors), so a true zoom can be never achieved completely accurately. Imagine for instance having an iemgui object that has a label with a font size of 16 and the rest of the patch using font size 10. When you resize things one step up (since you are limited by what font sizes are feasible, meaning zoom factor is restricted to workable font sizes) from 10 to 12, you are still severely limited by tcl/tk--while the increase in 120% can easily translate to vectors using canvas scale call, it does not account for images, or outlier font sizes (120% of a font size 16 is 19.2 and unless I am missing something there is no such font size possible inside tcl/tk). So, I do think this is the most sensible way of dealing with this until pd-l2ork shifts to a different toolkit altogether that is not so font-centric.

BTW, Pd-l2ork currently has a way to resize everything that is disabled because resizing of the aforesaid issue, as well as the fact that everything on tcl/tk's side of things does not account for all the changes necessary on C side of things that would require updating each object's location and size and updating its C-based structs that contain that info. This is why in part client-server separation (for the editor) makes little sense when so much of the client is already contained inside the server...

> 
> > we really need 2 instances. One that is based essentially off of libpd
> > and another that is a robust editor with none of the convoluted client
> > server model between the editor and the engine itself that has made
> > improving on the code so cumbersome

> 
> You want to replace the current client-server model by what exactly ?
> Most
> likely another kind of client-server model ?

Yes, but one that does not use sockets to communicate critical data and as such is severely limited in its performance, nor is it severely limited by the toolkit.

Best wishes,

Ico