Re: [9fans] Limbo Tk FAQ?

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

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