Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Dec 1996 04:05:06 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Michael Smith <msmith@atrad.adelaide.edu.au>
Cc:        hackers@freebsd.org
Subject:   Re: text, menu/dialog/windowing, library, ideas? 
Message-ID:  <27053.849528306@time.cdrom.com>
In-Reply-To: Your message of "Mon, 02 Dec 1996 13:25:05 %2B1030." <199612020255.NAA02673@genesis.atrad.adelaide.edu.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> ctk would be OK except for the fact that it appears to be an orphan, and
> the user is likely to try to program it like it was Tk.  By virtue of
> being designed for Tcl, it integrates well.

Yeah, though Ctk is also a good example of what happens if you try and
take the Tk paradigm and extend it in a direction it was never meant
to go.  "Klunky" doesn't even come close to programming in Ctk.

> Then please start talking at me about it 8)  I have the "wrap system
> libraries for Tcl" stuff prettyuch solved with SWIG, and I want to
> prototype that modular monster we were talking about before with a
> small module to frontend for libdisk.  

Well, I'm talking to you. ;-) Wrapping system libraries is
comparatively easy, though SWIG appears to make it even easier and is
a good thing.  That still doesn't help you when you've no reasonable
library for providing CUI interfaces to wrap. ;-)

> This sniffs a lot like a widget heirachy to me 8)  You're just saying
> that the widget types are a little less concrete than the current 
> norm "list of things to select from" rather than "listbox with scrollbar
> and returning item clicked on".  The decoupling is a nice idea, but 
> short of lots of smart code to perform layout work, you end up with
> a result that looks a lot like most automatically-created UI's - junk.

Well, I have played with Galaxy, C++/Views and zApp and have to say
that "junk" is probably too strong a word.  You won't get an
award-winning interface out of every single one of their supported
platforms, but "looks good enough" also works for me. :-)

I also failed to make one thing clear in my first suggested interface
technique, which was that if you come up with a generic Widget
mechanism that *ignores* layout considerations and only really tries
to handle the tie-up between front-end and back-end code as well as
identifying and maniplating individual "Widgets" by name, you can take
all the liberties you want in making a given layout look as nice as
you want.

Let's say that my chosen development environment for the moment is
Motif (stop gagging, everyone, this is a hypothetical example).  I can
write my Motif front end code to directly take every liberty in the
book with Motif to get a really snazzy (for Motif) interface with
every feature used to the hilt.  Then I write some glue to interface
those Motif objects which the back end wants to know about into my
abstract Widget layer - the abstract Widget type just encapsulates the
Motif object (whatever it might be) and provides a way for the back
end to say "Hey, whatever the hell you are, can I have the text you've
got currently selected?"

However, I think all of this misses a something important fact here
(and we get to this stage *every time* the subject comes up :-) which
is that the Universal GUI Paradigm already sort of exists, and it's
called HTML.  Dave, fetch a bucket please, they're gagging again and
it's breaking my concentration.

Don't you think, really, that ultimately a HTML-driven interface is
the only one which is going to give you the best of all possible
worlds?  With some care taken in the composition, even lynx can
display a fairly decent rendition of a complex form, like the one at
http://www.freebsd.org/send-pr.html, and under an X based browser they
look very nice indeed.  You can embed your fancy graphics and
backgrounds and lynx will ignore it all while letting your Netscape/IE
version jump up and do cartwheels if that's what floats your boat.

I suppose that if you were *really* heavily into abstraction, you
could do both and the encapsulation of an HTML generator/driver would
just become another interface type. :-)

I dunno, what do you think of all this?

					Jordan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27053.849528306>