----- Original Message ----- > From: Ivica Ico Bukvic <i...@vt.edu> > To: 'Mathieu Bouchard' <ma...@artengine.ca> > Cc: pd-list@iem.at > Sent: Tuesday, March 27, 2012 2:32 PM > Subject: Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now > available > >> 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.
What does font-centric mean? > > 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 > > > > _______________________________________________ > 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
