Re: [9fans] Limbo Tk FAQ?

Re: [9fans] Limbo Tk FAQ?

[rog]

> > 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.

Re: [9fans] Limbo Tk FAQ?

[Lucio De Re]

On Fri, May 25, 2001 at 10:59:48AM +0100, rog@vitanuova.com wrote:
> 
> i wouldn't like to do this sort of stuff in tcl.  limbo just makes it
> so simple.
> 
Tcl with channels would do well, too :-)  (Oops, I hope I'm not
speaking through my nose here, I've only given the code a brief
glimpse, looking forward to look at it in more detail later).

> 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 sure I'm sounding like an old hag peddling Tcl, but what appeals
to me about Tcl is that one can construct composite commands, in
effect interpretive language constructs) that more naturally describe
the activities of a user or a class of users of a particular
application.  Tk is very much an example of such an extension, in
this case to Tcl itself, but also to any application that used Tcl
as its command language in the first place.

And adding "filesystems" semantics to Tcl may be an interesting
challenge, too.  It certainly could make very healthy use of the
plumber, in a multi-threaded environment.

As an example (not necessarily a good one) I knocked together a
very small shell to handle a particular aspect of a postgresql
database, using "expect" so that the user could get the benefits
of the Tcl interpreter right at the command line level and still
clean up when they terminated (there may well have been a better
way, but Tcl has grown far beyond its documentation and reading
source is not my idea of keeping up with creeping featurism).

What I was aiming at, though, was the ability to build a few, simple
to use underlying constructs and teach the users how to construct
more complex ones for their purposes, often on the fly.  More
permanent, or often used commands could be included in the prologue,
euither globally or by being included in a particular instance.
In that respect, Tcl is a command line shell, and a very powerful
one, at that.  With default parameters and a sensible prologue and
epilogue, I could provide a secure environment for less savvy, but
trustworthy users.

> i'm sorry, i'm off topic.
> 
We often are, on this mailing list, but the nature of Plan 9 is to
encourage this, not treat it as if it was an unsightly wart.

++L

Re[2]: [9fans] Limbo Tk FAQ?

[Matt H]

Hello rog,

>> > 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.

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

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

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

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

rvc> i'm sorry, i'm off topic.
well, while you're there

any idea when signed applets for IE limbo will grace our lives?



-- 
 Matt                          mailto:matt@proweb.co.uk

I'm floating on a lilo in the Sea of Alright

Re: [9fans] Limbo Tk FAQ?

[geoff]

The philw put tk into Inferno.  He botched it (of course).
I still haven't seen any reasonably pleasant way to
write GUIs and am becoming convinced that it's just
inherently painful.  limbo/tk is probably less painful
than some other ways, but graphics programming still
reminds me of assembler programming: way too much attention
to way too much irrelevant detail.

Re: [9fans] Limbo Tk FAQ?

[Lucio De Re]

On Thu, May 24, 2001 at 02:50:27PM -0400, geoff@collyer.net wrote:
> 
> The philw put tk into Inferno.  He botched it (of course).
> I still haven't seen any reasonably pleasant way to
> write GUIs and am becoming convinced that it's just
> inherently painful.  limbo/tk is probably less painful
> than some other ways, but 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 haven't tried VB or VC++, I must confess, perhaps I fear to
discover that there are shortcuts out there, as long as you kneel
to the right religion.  Oh, yes, there's vtcl out there too, but
my prejudice against generated high level code gets in the way of
me using it :-(

Is it all a matter of language idioms, then?

++L - a C News fan :-)

Re[2]: [9fans] Limbo Tk FAQ?

[Matt H]

Hello Lucio,

L> I haven't tried VB or VC++, I must confess, perhaps I fear to
L> discover that there are shortcuts out there, as long as you kneel
L> to the right religion.

VB is very easy. Drag & drop controls then double click to get the
wrapper to call it you end up with

Sub Button1.Click()
       Button1.Caption = "I've been clicked"
End Sub

VC++ works in a similar way but is a bit more hairy.

The best way (I think) to work that environment is to make ActiveX
Controls (just a glorified class that has it's own display window)
in VC and then arrange them and make them interact with VB.

Then it's time for battle with MFC. The Microsoft Foundation Classes.
A whole bunch of C++ Classes which prevent portability (even between
types of windows apps) and add plenty of complexity. Chuck in the
many macros for doing window handling and message passing and suddenly
you really don't know what's going on.

-- 
 Matt                          mailto:matt@proweb.co.uk

I'm floating on a lilo in the Sea of Alright

Re: [9fans] Limbo Tk FAQ?

[Lucio De Re]

On Fri, May 25, 2001 at 08:44:15AM +0100, Matt H wrote:
> 
> VB is very easy. Drag & drop controls then double click to get the
> wrapper to call it you end up with
> 
> Sub Button1.Click()
>        Button1.Caption = "I've been clicked"
> End Sub
> 
The question is: "Is this the answer to Geoff's prayers?"

In a sense (at least as far as John Ousterhout goes, see his paper
on scripting languages which you may still be able to find at
www.scriptics.com) it is, in that it removes the drudgery of
nitty-gritty design, but at the price of flexibility.

There's something to be said for adopting the Microsoft idiom,
because most users are familiar with, but there's also the risk
that a lot will go uninvented because no further exploration is
taking place, and we can't find out what we're missing.

Developers, of course, are another, totally different, kettle of
fish.

I fear I repeat myself, but to me the idea of an embeddable language
like tcl looks more and more appetising.  Unlike the original Tk,
I believe Limbo/Tk is not expandable, at least not to the extent
of being able to define new widgets and operations upon them.  I
haven't read that part of the (2Ed) Inferno manual properly, though.

My dream might well be Charles Forsyth's nightmare: tcl embedded
in limbo applications.  We could certainly revise tcl in the process,
but the fundamental principles are sound (in my uneducated opinion).

++L

Re[2]: [9fans] Limbo Tk FAQ?

[Matt H]

Hello Lucio,
>The question is: "Is this the answer to Geoff's prayers?"
 It depends if Geoff's prayer is "please can I have a simple
 application framework please"

 It's the IDE that makes the difference.
 VB writes all the form layout files for you. You can write them by
 hand which is probably what tk feels like (which is a guess on my
 part as I've never programmed in it just read various papers)

 
 I found VB's main weaknesses (aside from it's platform dependence) to be it's
 lack of in-built support for things like TCP connections and
 regular expressions and that's what lead to my rediscovery
 of unix like systems.

 that paper is at
  http://www.scriptics.com/people/john.ousterhout/scripting.html

-- 
 Matt                          mailto:matt@proweb.co.uk

I'm floating on a lilo in the Sea of Alright