On 07/02/2013 06:54 AM, András Murányi
wrote:
If you start with an auto-resizable widget or iemgui label that
takes an
arbitrary string you probably don't want to combine it with a
fixed-width
geometry manager (geometry unmanager?) like a GOP canvas.
You'll have to resize the width of the GOP box manually,
which means you have to listen for changes to the string length of
the label
and _guess_ at how many pixels that translates to. If you guess
wrong (and
given that different OSes do fonts differently you will guess wrong)
it will break.
Every modern GUI toolkit (even tk) assumes that the developer
doesn't want to
worry about these problems, or at least assume they only want to
control them
at a much higher level.
For some context:
Pd's diagrams actually break all the time: whenever patch authors
set
up objects so that the wires to/from a secondary xlet are either
straight or at
45-degree angles. Those lines may not be at the same angle on
someone else's
machine, because of font rendering peculiarities on the OS or
specific font settings
that user has made. The breakage can actually introduce ambiguities
that aren't
there on the original author's machine, but most of the time these
breakages just
degrade the diagram gracefully-- you get not-quite-straight lines
that don't look
as aesthetically pleasing but the patch is fully
functional/editable.
If your iemgui label or symbol box on a GOP canvas goes over the
allotted pixel
width of the GOP rectangle you lose functionality because the object
no longer moves
with the GOP canvas. If you're making a one-off GUI for your own
purposes this
may be fine, but if you're trying to make a reusable abstraction,
don't combine
auto-resizing widgets with geometry-unmanagers. They don't degrade
gracefully,
and the pitfalls aren't trivial to see unless you stream the patch
to three different
OSes at the same time and watch the differences.
-Jonathan