Re: [9fans] Limbo Tk FAQ?

Re: [9fans] Limbo Tk FAQ?

[rog]

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

i added a loadable module for the inferno shell to give shell access to
tk; this also includes channels (as they're an inextricable part of the
inferno tk interface).

some will turn up their noses, but i've found it quite nice for
knocking up simple graphical demo scripts written in shell script. part
of the reason is that the shell is multi-process, so channels sit quite
nicely with it.

	load tk
	wid := ${tk window 'Test window'}
	while {} {
		tk winctl $wid ${recv $wid}
	} &

the first line loads the tk module; the second creates a new tk window,
and returns an identifier for it, which is also the name of a channel
on which window events can be received. the third starts a background
process looping forever receiving from the channel and processing the
event that it got.

the only part not familiar from rc is the ${...} notation which yields
the result of a loadable-module-defined command (sort of like `{...}
but without the uncertainty of the usual stdout tokenization)

once you've defined a function to execute tk commands:

	fn x {
		tk $wid $*
	}

one can execute tk commands quite simply:

	x button .b -text {Hello world} -command {send cmd hello, world}
	x pack .b
	x update
	chan cmd
	tk namechan $wid cmd
	while {} {
		echo ${recv cmd}
	}

i guess this feels somewhat like tcl; it's certainly nice for hacking
up simple graphical interfaces to shell commands.

Re: [9fans] Limbo Tk FAQ?

[Lucio De Re]

On Fri, May 25, 2001 at 01:10:55PM +0100, rog@vitanuova.com wrote:
> 
> i added a loadable module for the inferno shell to give shell access to
> tk; this also includes channels (as they're an inextricable part of the
> inferno tk interface).
> 
The inferno shell is an utter treat.

> the only part not familiar from rc is the ${...} notation which yields
> the result of a loadable-module-defined command (sort of like `{...}
> but without the uncertainty of the usual stdout tokenization)
> 
If I buy the manual set now, do I get a discount when I eventually get to
subscribe for the source licence?

> once you've defined a function to execute tk commands:
> 
> 	fn x {
> 		tk $wid $*
> 	}
> 
Is there a plumber module, too?  Or should the "fn" syntax be enhanced
as for traps?

> one can execute tk commands quite simply:
> 
> 	x button .b -text {Hello world} -command {send cmd hello, world}
> 	x pack .b
> 	x update
> 	chan cmd
> 	tk namechan $wid cmd
> 	while {} {
> 		echo ${recv cmd}
> 	}
> 
> i guess this feels somewhat like tcl; it's certainly nice for hacking
> up simple graphical interfaces to shell commands.

All you're omitting is the upvar/uplevel capability to handle call by
reference.  We can't be far from the real thing :-)

++L

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: [9fans] Limbo Tk FAQ?

[geoff]

Sorry; my last message was meant to be private mail.

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: [9fans] Limbo Tk FAQ?

[Boyd Roberts]

> I haven't tried VB or VC++, ...

i've written some amount of C with VC++ and it's throroughly
unpleasant.  there are at least three problems:

    - windows' environment
    - the documentation is unreadable
    - there are some things you can't do in C that you have
      to do in C++.  toolbars spring to mind.  you can't write
      them in C, 'cos there's not enough documentation so
      you're committed smashing the two worlds together.

toolbars are yet another demonstration of a broken design.
if it was obvious what the icons did you wouldn't need
the text to pop up when you mouse over them.

Re: [9fans] Limbo Tk FAQ?

[Lucio De Re]

On Fri, May 25, 2001 at 02:44:32PM +0200, Boyd Roberts wrote:
> 
> toolbars are yet another demonstration of a broken design.
> if it was obvious what the icons did you wouldn't need
> the text to pop up when you mouse over them.
> 
Not that I don't agree with your sentiments, but in defense of
tooltips, I will say that they are more convenient than manuals.
Once you're familiar with an icon's meaning, which you need not be
as you first encounter it (imagine not having to learn road signs,
and specially not being examined on them for licence purposes),
you can turn the tooltips off.

Not that I ever do.

(I have this image of driving along a country road and having tooltips
appear appear on the windscreen as I approach each road sign.)

Another _good_thing_ about tooltips is that they are precisely
where you would want them to be.  You can search a toolbar very
readily with tooltips.  Doing the same in a manual, or, God forbid,
a hierarchy of help pages, is highly detrimental to your mental
health.

++L

Re: [9fans] Limbo Tk FAQ?

[splite]

On Fri, May 25, 2001 at 02:44:32PM +0200, Boyd Roberts wrote:
> 
> toolbars are yet another demonstration of a broken design.
> if it was obvious what the icons did you wouldn't need
> the text to pop up when you mouse over them.

I love tooltips.  It's like having a game of Concentration built into
every app!

"Is this the "rotate 90 degress" button? (wait, wait, *pop*)  Yes!
Woohoo!  I'm da man!"

Re: [9fans] Limbo Tk FAQ?

[Boyd Roberts]

> "Is this the "rotate 90 degress" button? (wait, wait, *pop*)  Yes!
> Woohoo!  I'm da man!"

and then you can reverse guess how they got to decide on that icon.

twisted, totally twisted...

Re: [9fans] Limbo Tk FAQ?

[Douglas A. Gwyn]

Lucio De Re wrote:
> ... I find graphics programming far too tedious.
> Is it all a matter of language idioms, then?

I've been programming computer graphics since the 1960s.
There have been *numerous* attempts to streamline use of
graphics, e.g. a plotting subroutine that is given a user
function and domain limits and then auto-scales and plots
it without further user programming.  Unfortunately, such
attempts have usually imposed a particular model for how
the specific use falls into an overall framework, and the
overall frameworks change from time to time, invalidating
the model and thus obsoleting the previous generic support
("graphics libraries").

Current commercial GUIs are, first of all, raster oriented,
but more significantly, they tend to be "object oriented"
in order to provide default characteristics (framework)
which can be overridden as necessary in order to support
specific application usage.  Of course, at the lower
levels there has to be some form of support for drawing
rectangles, characters, etc. but if there is sufficient
intermediate-level support the higher-level code doesn't
have to worry about low-level operations.  The down side
is that if details really matter to you, such interfaces
usually make it hard to force the details to come out the
way you want; their assumption is that you will accept the
default framework (Motif or whatever).

Other approaches are feasible; two that I use on my home
computer are S-Plus (commercial version of S, which has a
freeware implementation called R) and Mathematica.  These
provide generic frameworks that are fairly easy to use
and allow the user to work much more in the application
"problem domain" (interactive data analysis or mathematics
research, respectively) as opposed to graphics programming
per se.  If I had more spare time, I'd port R to Plan 9.

Re: [9fans] Limbo Tk FAQ?

[Randolph Fritz]

In article <20010525065834.K21254@cackle.proxima.alt.za>, Lucio De Re wrote:
> On Thu, May 24, 2001 at 02:50:27PM -0400, geoff@collyer.net wrote:
> 
> 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?
> 

I found VC++ GUI programming more grief than COBOL using cards!  :-)

My impression is that, so far, the best--in the sense of most widely
and easily usable--GUIs (still) come from the old Macintosh
environment.  Most of the major GUI applications came out of that
environment.  Even the worst Mac software usually makes some nod to
usability and pleasing appearance.

I don't, unfortunately, know very much about Mac internals; I find the
classical OS side of the Mac pretty scary.  But in GUI development,
they seem to have something, perhaps something still worth studying.
Consider that the original Mac had a workable, albeit limited, GUI in
128k (sic) of main memory.  Ok, they did quickly upgrade it to
512k. :-) Still, it seems to me that the original Mac developers had a
good handle on the core requirements of GUI development and
implemented them successfully.

One more research project I don't want to spend the time to pursue... :-(

Randolph

Re: [9fans] Limbo Tk FAQ?

[Barry Kelly]

In article <20010525065834.K21254@cackle.proxima.alt.za>
	lucio@proxima.alt.za (Lucio De Re) wrote:

> On Thu, May 24, 2001 at 02:50:27PM -0400, geoff@collyer.net wrote:
> > 
> > I still haven't seen any reasonably pleasant way to
> > write GUIs and am becoming convinced that it's just
> > inherently painful [...] way too much attention
> > to way too much irrelevant detail.
> 
> [...] I find graphics programming far
> too tedious.
> 
> I haven't tried VB or VC++, [...]

You should try Delphi instead.

-- Barry

-- 
  One must sometimes choose between expressiveness, safety, and
  performance. But a scarcity of one isn't always excused by an
  abundance of another. - Thant Tessman
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re: [9fans] Limbo Tk FAQ?

[forsyth]

>>The Inferno manual (volume 2, the papers) has a very good document on the
>>Limbo/Tk. I do not think it is available on the web on its own, but it
>>might be included in the download distribution. I'm quite certain if you
>>asked the fine folk at Vitanuova for a Postscript copy, they would oblige.

http://www.vitanuova.com/inferno/papers/tk.html		# the overview mentioned
http://www.vitanuova.com/inferno/papers/descent.html	# some more interesting examples
http://www.vitanuova.com/inferno/man/9/INDEX.html		# the Tk reference manual pages for Inferno

Re: [9fans] Limbo Tk FAQ?

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

i looked at porting Ousterhout's Tk to Plan 9 several years ago,
but became discouraged.  i'd like to be more helpful but apart
from its size, i can't remember what ultimately discouraged me
from continuing.  there's a version for Windows so i suppose
X11 dependencies weren't the main problem, but perhaps
that was it.

the Inferno implementation was completely new,
and i think about 1/4 of the number of lines of Ousterhout's Tk at the time
(allow for Inferno's Tk being an extended subset of that Tk),
excluding Tcl.

i thought the Inferno implementation was tidier.


[-- Attachment #2: Type: message/rfc822, Size: 1595 bytes --]

To: cse.psu.edu!9fans
Cc: cd.chalmers.se!lac
Subject: Re: [9fans] Limbo Tk FAQ?
Date: Thu, 24 May 2001 14:08:24 +0200 (MET DST)
Message-ID: <200105241208.OAA13721@boris.cd.chalmers.se>

Who did the port to inferno? How hard would it be to port Tk to plan 9? 

Laura Creighton

Re: [9fans] Limbo Tk FAQ?

[Lucio De Re]

On Thu, May 24, 2001 at 01:29:54PM +0100, forsyth@vitanuova.com wrote:
> 
> i thought the Inferno implementation was tidier.
> 
I like Tcl, personally, as an unstructured programming language
and find the artifice of submitting tk commands to a specialised
inner interpreter quite at odds with its usability.  That is the
way perl and python use tk, too, isn't it?

I really find it silly to use a tcl-like environment and not have
tcl's most useful features avaiable.  But then tcl is one of my
preferences for both simple and complex programming tasks.  Brent
Welch's web server based on tcl is one of the most inspired and
inspiring tools I've had occasion to work with.  A real *tool*,
not just another application.

I find tcl far from perfect but it sure beats awk and perl hands
down.  Rc might be better as an embeddable command language, but
some of the weirder concepts in tcl, like "upvar" and "uplevel"
are quite hard to simulate in any other programming environment.
And they make all the difference in embeddable applications (like
adding posgresql _and_ LDAP to the web server).

And while on that tack, I think Dave Presotto mentioned looking at
"expect", has anyone got some idea how to implement something like
expect without PTYs?  I get the impression from Don Libes' book
that it is possible, but the results would be unsatisfactory, yet
there has to be a Plan 9 concept that can be used as a generic
"data entry" device.  I must confess I have not searched very
carefully, but nothing comes to _my_ mind...

++L

Re: [9fans] Limbo Tk FAQ?

[Berry Kercheval]

lucio@proxima.alt.za said:
>  Brent Welch's web server based on tcl is one of the most inspired and
> inspiring tools I've had occasion to work with.

Steve Uhler deserves a lot of credit for tclhttpd too.

I'll forward your praise to Brent; he and I are working at a new startup.

Re: [9fans] Limbo Tk FAQ?

[nigel]

[-- Attachment #1: Type: text/plain, Size: 118 bytes --]

It's not a port to Inferno. It's a reimplementation.
Also, it's Limbo/Tk, not Tcl/Tk, i.e. it has Limbo
binding.


[-- Attachment #2: Type: message/rfc822, Size: 1417 bytes --]

From: Laura Creighton <lac@cd.chalmers.se>
To: 9fans@cse.psu.edu
Cc: lac@cd.chalmers.se
Subject: Re: [9fans] Limbo Tk FAQ?
Date: Thu, 24 May 2001 14:08:24 +0200 (MET DST)
Message-ID: <200105241208.OAA13721@boris.cd.chalmers.se>

Who did the port to inferno? How hard would it be to port Tk to plan 9? 

Laura Creighton

Re: [9fans] Limbo Tk FAQ?

[Laura Creighton]

Who did the port to inferno? How hard would it be to port Tk to plan 9? 

Laura Creighton

[9fans] Limbo Tk FAQ?

[Richard Elberger]

Hi folks,

Is there a faq somewhere about the tcl/tk use in Limbo and how it differs
from tcl/tk in other systems?

thanks in advance --

-- rich

Re: [9fans] Limbo Tk FAQ?

[suspect]

The Inferno manual (volume 2, the papers) has a very good document on the
Limbo/Tk. I do not think it is available on the web on its own, but it
might be included in the download distribution. I'm quite certain if you
asked the fine folk at Vitanuova for a Postscript copy, they would oblige.
Also, information on Limbo/Tk will appear in the Inferno/Limbo FAQ @
inferno.stricca.org, soon.
-



On Thu, 24 May 2001, Richard Elberger wrote:

> Hi folks,
> 
> Is there a faq somewhere about the tcl/tk use in Limbo and how it differs
> from tcl/tk in other systems?
> 
> thanks in advance --
> 
> -- rich
> 
>