Re: [9fans] Limbo Tk FAQ?

[rog@vitanuova.com]

> > graphics programming still
> > reminds me of assembler programming: way too much attention
> > to way too much irrelevant detail.
>
> I'm pleased to discover I am not alone in this, although I couldn't
> have phrased it as succintly or as accurately as you did.  And I
> enjoy assembly programming, but I find graphics programming far
> too tedious.

i think that's because you've got multi-dimensional inputs, often with
associated state, which are much harder to deal with than the
unidimensional, stateless input stream of a command-line program, for
example.

at least with limbo/tk, the language is decently multi-threaded, so
it's often possible to carve a program into logically independent
threads, each of which is quite simple, rather than the age old "one
big state machine" paradigm which is the only way of doing things in
many GUI programming interfaces. despite its superficial simplicity,
i'll bet that Visual Basic falls into that category too.

where GUI programming is inevitably tedious is when you're dealing with
input forms (buttons, entry widgets, sliders, tickboxes, etc, etc), as
there are so many possible states to think about and deal with in the
program. i think that this is going to be the case regardless of
language. the key is probably to minimise (eliminate?) instances of
this kind of interface.

i've found limbo/tk to be a very productive environment, compared to
others i've used (principally the NeXTStep interface (now MacOS X),
which i believe is well regarded).  the first-class strings in limbo
sit very well with the string-based nature of tk. strings nicely
represent a generic tk object.

for instance, the following code animates an arbitrary object smoothly
across a tk canvas at constant velocity. it doesn't matter what the
object is (it might be a composite of many); and there can be any
number of animations happening concurrently.

animproc(a: ref Animation)
{
	SPEED: con 1.5;			# animation speed in pixels/millisec
	dstpt := a.dst.pos.add(a.dst.delta.mul(a.index));
	srcpt := a.srcpt;
	d := dstpt.sub(srcpt);
	if (!d.eq((0, 0))) {
		mag := math->sqrt(real(d.x * d.x + d.y * d.y));
		(vx, vy) := (real d.x / mag, real d.y / mag);
		currpt := a.srcpt;		# current position of object
		t0 := sys->millisec();
		dt := int (mag / SPEED);
		t := 0;
		tk->cmd(win, ".c raise " + a.tag);
		while (t < dt) {
			s := real t * SPEED;
			p := Point(srcpt.x + int (s * vx), srcpt.y + int (s * vy));
			dp := p.sub(currpt);
			tk->cmd(win, ".c move " + a.tag + " " + string dp.x + " " + string dp.y + ";update");
			currpt = p;
			yield();
			t = sys->millisec() - t0;
		}
	}
	a.waitch <-= a;
}

i wouldn't like to do this sort of stuff in tcl.  limbo just makes it
so simple.

that said, i think there is room for some sort of expandability in
limbo/tk, not via tcl, i think but perhaps via some sort of
channel/module/device interface.

i'm sorry, i'm off topic.

  rog.