Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Mathieu Bouchard' matju@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?
It means that zoom levels news to be driven by integer font sizes as tcl/tk canvas is incapable of displaying non-int font sizes. This is why the pd object drawing mechanism first queries font width and height to decide how big of a box to draw. It is simply incapable of doing out the other way around.
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
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net