on the strange weakness of Graphical User Interface Languages
Mark Tarver
languages are. Before anybody jumps on TCL/tk, or starts advertising
their solution I don't think that it is *that* language that is
specifically to blame. I'm seeing the same thing in Visual Basic and
in CLIM and indeed in every GUIL I've looked at.
I was explaining to my friend Willi what I was experiencing - a
profound sense of intellectual dissatisfaction. The problem is that
there is a real contrast here between the economy and elegance of
functional programming and what I am experiencing here. In
functional programming there is an important idea - Turing equivalence
- which is well defined and can be captured in a remarkably small set
of primitives. FP allows to combine these primitives into complex
functions by means of a small but powerful set of combinations. So
the elements in the 'right thing' are:
FPLs
1. A well defined theory of Turing equivalence
2. A small number of primitives and
3. A powerful means of combination
When you come to GUILs the position is reversed. You have this vaguer
idea of computational adequacy which means that the GUIL can do the
things you want. But the primitives are nowhere in sight
and what you are given is a grab-bag of tools for making buttons and
various widgets. Since the user's wish list is indefinitely large,
GUILs become bloated and you end with 1000 page manuals of commands,
hacks and hooks of every descripton. Reminiscent of PL/1 actually.
So what you have is 'the wrong thing'.
GUILs
1. A vague idea of computational adequacy.
2. A huge number of primitives.
3. A weak means of combining together.
Now I sat down and wondered why that was. Was the field inherently
just a big intellectual hack, or have human beings made a mess of it.
I decided that was probably more that human beings made a mess of it
and that there was a much more elegant approach. We had to begin with
a formal theory of widgets and by asking dumb-sounding but actually
deeply serious questions like 'What is a window'?
Now without weighing you down with my projected solution, when I began
to think about it, I realised that my ideas required command of the
low level substrate of my computer and that a lot of work was involved
here because the low level primitives I envisaged would have to
execute very quickly. I also realised I probably would not have the
time to do this work. And I think that this is not only a shame but
indicative of a problem with FP in general. Its not so much that the
FP paradigm is weak and incapable of doing the task, it is that as
functional programmers we're very much boxed in by the decisions of
the people who designed the environment within which our work is
embedded. It's very very difficult to do the right thing when
everything around you is doing the wrong thing.
Mark
Ulf Wiger
>
> FPLs
>
> 1. A well defined theory of Turing equivalence
> 2. A small number of primitives and
> 3. A powerful means of combination
>
> When you come to GUILs the position is reversed. You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
> I decided that was probably more that human beings made a mess of it
> and that there was a much more elegant approach. We had to begin with
> a formal theory of widgets and by asking dumb-sounding but actually
> deeply serious questions like 'What is a window'?
Joe Armstrong wrote a paper a few years ago, describing a
mapping to the X protocol. The approach is perhaps fairly
specialized towards Erlang, but he made an interesting
observation:
- the X protocol is simple (154 mostly simple messages)
- XLib is more complex (800+ routines)
- Motif et al are hideously complex
The Erlang/Joe take on this is that the underlying semantics
is a naturally concurrent message passing system, but the
widget sets go to great lengths to hide the inherent
concurrency.
http://www.erlang.se/workshop/2004/ex11.pdf
Perhaps the current mess is a result of this sort of
evolution. While Joe's approach felt pretty natural in
Erlang, the approach you suggest might be equally successful.(*)
BR,
Ulf W
(*) Joe's approach was only conceptually successful. His
GUI toolkit didn't get any followers - too much work to make
it into a competitive framework.
Joachim Durchholz
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of it.
The end users have contributed a large part of this.
I.e. it's ergonomics. Worse, it's ergonomics not for a small set of
people who share a lot of ideas and ideals (as would be the case for
programming language ergonomics), it's for the far larger set of
"anybody who is ever going to use the computer". And doing ergonomics
for a large, varied group of individuals is a messy process.
The other party who has been contributing to the mess is programmers.
Far too many programmers know about ergonomics. They *think* they know
ergonomics because they themselves are users, but eating your own dog
food only tells you something about how well it is for you and people
like you - if you're programming for end users, you need to do
laboratory studies with dummies from the street. And that's beyond what
most programmers do, or have been taught to do.
(I just recently came across reports from such a testing lab. One test
was when programmers watched users through a one-way mirror. The more
emotional scenes were those *behind* the mirror, when the programmer
shouted "press that button, you i***t!" ...)
Of course, GUILs are often far more complicated than necessary.
On the other hand, you can't simply just set up a widget hierarchy; this
interferes badly with stuff like tab order. Things get worse if the
programmer's hierarchy deviates from the perceived hierarchy (i.e. if
you have invisible containers).
> And I think that this is not only a shame but
> indicative of a problem with FP in general. Its not so much that the
> FP paradigm is weak and incapable of doing the task, it is that as
> functional programmers we're very much boxed in by the decisions of
> the people who designed the environment within which our work is
> embedded. It's very very difficult to do the right thing when
> everything around you is doing the wrong thing.
GUI libraries are just as messy as GUI languages.
I think the problem lies more with GUI interfaces in general rather than
with any specific technology trying to wrap it.
I have spent three years working on and co-developing a GUI library. I
know how the Windows API looks like, and what comes of it if you try to
wrap the stuff in an object-oriented framework. I have looked at
alternatives to what we were doing, and they were either not flexible
enough or too complicated.
Regards,
Jo
Jon Harrop
> I've been working with TCL/tk and I'm struck at how messy graphical
> languages are. Before anybody jumps on TCL/tk, or starts advertising
> their solution I don't think that it is *that* language that is
> specifically to blame. I'm seeing the same thing in Visual Basic and
I've not done much work on GUIs but I found OCaml's LablGTK interface to be
good and F#'s interface (with Intellisense) to Windows Forms to be
excellent.
I'm sure there is plenty of scope for improvement though. As you say, GUI
APIs tend to be very complex and this is where functionality like
Intellisense really pays off.
YMMV.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Ken Tilton
<sigh>: http://www.tilton-technology.com/cello-shot-05.jpg
> FPLs
>
> 1. A well defined theory of Turing equivalence
I'll leave that to you smart people. All my theorys are about meeting
girls. Or does this count: declarative and functional. As in Cells.
> 2. A small number of primitives and
Two classes, Image and Control. Combine with Family and... can you say
"Lego"? Sher ya can.
> 3. A powerful means of combination
Dataflow? As in... oh, what's the use?
You have nothing to fear but cellsophobia itself.
kenny
--
http://www.theoryyalgebra.com/
"Mother always told me, if you tell a lie,
always rehearse it. If it don't sound good
to you, it won't sound good to no one else."
- Satchel Paige
Dan Doel
toolkits are clumsy to work with in general? Or that making good, usable
interfaces isn't as easy as it could be.
If it's the former, have you looked at all at functional reactive
programming? A lot of work has been done in Haskell on it, but there are
other areas it's been looked at (I think there was a Scheme FRP library,
and the Flapjax JavaScript library incorporates ideas from FRP).
Conal Elliott is also doing work that looks interesting on "tangible values"
in GUI programming. The idea, from what I can see, is that you have values
that, at the same time, correspond to GUI elements, but can be operated on
applicatively by functions.
Of course, no FRP toolkit has made it very far out of research phases, to my
knowledge (Flapjax might be the closest, but even it's probably stuck at MS
research), and Conal's stuff isn't finished yet. So as of today, you're
probably stuck with more traditional GUI frameworks if you want to build a
working Haskell GUI application.
If the latter problem above is the real issue, I'm not sure a solution is
even possible. (Some) Big GUI projects spend lots of time/money doing
studies and tweaking their interface designs in various ways that make them
more usable. I don't foresee anything in the near future coming along and
automatically generating an optimally usable interface for some underlying
model. But, I suspect that's not the end you're worried about currently.
-- Dan
Ken Tilton
Mark Tarver wrote:
> I've been working with TCL/tk and I'm struck at how messy graphical
> languages are. Before anybody jumps on TCL/tk...
Actually, I was going to defend it. Nowhere in your treatise do you
define and/or justify the charge of messy. Tk has a dozen or so widgets,
the same attributes for all of them where appropriate, the same
semantics for those, and even automatic dataflow to support the
dependencies one finds between GUI components (this thing should reflect
the position of the slider, eg).
But it is fine if you want to define "messy" and then apply to Tk or my
living space, but until you do the discussion will be meaningless with a
600lb undefined term sitting in the middle of it. Of course why bother?
Here you ban any challenge to your premise...
>..., or starts advertising
> their solution I don't think that it is *that* language that is
> specifically to blame. I'm seeing the same thing in Visual Basic and
> in CLIM and indeed in every GUIL I've looked at.
Fine, you have now declared that all GUILs are messy and that in
principle no GUIL can be non-messy, this a priori determination being
the only justification you might have for not wanting to hear about any
you might have missed.
Meanwhile users of Cello and Cells-Gtk and Adobe Adam/Eve and some
FrTime thingy are having a ball with GUIs while you will be moderating
this closed-minded thread. Just peachy.
So when are you announcing.... QUIL?
:)
kt
--
CDon
reflect the endless search for the "Do what I meant command."
Raffael Cavallaro
> But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets.
This is the central problem imho. The fact that the toolkits are not
functional is of lesser significance.
The designers of GUI toolkits have, in general, striven to make them
"easy to use." This seems to mean "relatively high level." As a result,
the primitives are hidden or unavailable.
The problem for me comes from the broken, hard wired assumptions the
toolkit designers often make about how the primitives should be tied
together. Without access to the primitives it becomes extremely
difficult or impossible to get the behavior one wants without going
outside the toolkit.
Ken Tilton
CDon wrote:
> In a one-sentence Nutshell, I think the problems with most GUIs
> reflect the endless search for the "Do what I meant command."
>
The Unbearable DWIMness of Dataflow-enabled GUI authoring (thx to
whoever mentioned Flapjax, the latest/closest thing I have seen to the
package no longer dares to speak its name) is precisely what has its
practitioners turning backflips while building GUI circles around the
rest of you yobbos with one hand tied behind their back, which is why
this thread has been deprecated as hopelessy uninformed and out of date.
Maybe the moral of the story should be the same problem No Silver Bullet
has, and the same problem anyone has who says COBOL or C++ or Java or
Python has won: who says we're through? Stop whining (or celebrating)
and get back to work.
kt
Mark Tarver
Messy for the reasons I gave. In Lisp, I used to introduce students
by showing them CAR, CDR, CONS and a few other functions and showing
how Turing equivalence could be gained in an instruction set of about
half-a-dozen functions - everything else that was thrown in, I told
them, was often about convenience and speed.
In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
detail without any guiding idea of what would correspond to the vital
primitive instruction set. Because of this, and because I have no
idea what the primitives are in that system that constitute a
computationally adequate set, there are certain questions I cannot
answer with confidence.
For example, could I produce a window with bevelled edges in TCL/tk -
or a triangular window or .... fill in your outlandish request. Well
maybe, but I'd have to check it out. In contrast if I'm asked to
write a prime number program in Lisp I don't have to think 'Does Lisp
have a prime number recognisor?'. I know I can do it because prime
recognition is effectively computable and Lisp incorporates a Turing-
equivalent set of functions. I can't say the same in TCL/tk because
the theory is not there.
Have a good set of primitives in a well-defined theory not only allows
you to approach programming tasks with confidence, it also allows
system programmer to develop tight, reliable and efficient
implementations because they can focus on hard-coding these primitives
to run efficiently. Applications people can then develop libraries
for standard apps.
> < http://www.tilton-technology.com/cello-shot-05.jpg
People show me stuff. GUIL designers like to show off with 'Look Ma,
no hands examples' - examples that pander to the preprogrammed
functionality thats incorporated into the system. It doesn't do much
for me. Nice picture of your hand though.
> Fine, you have now declared that all GUILs are messy and that in
> principle no GUIL can be non-messy,
No, I asserted the contrary w.r.t. the last part. I think that GUILs
can be made elegant but stuff needs refiguring. Its not trivial.
> Meanwhile users of Cello and Cells-Gtk and Adobe Adam/Eve and some
> FrTime thingy are having a ball with GUIs while you will be moderating
> this closed-minded thread. Just peachy.
>So when are you announcing.... QUIL?
Well Qi/tk first ran in *2002* and I used it to produce a moving
histogram to plot traffic for a multi-agent model of a transport
system. You can read about the model here and it was all type secure
back then.
http://www.lambdassociates.org/webbook/chap17.htm
http://www.lambdassociates.org/webbook/chap1.htm
section 1.8 mentions this work.
When I got over the thrill of being able to write 'Hello World' in 3
inch high yellow letters in type secure code, I put it away. I had
more important things to figure on - for example, correctness proofs
for Qi (no point having a system that produces wrong answers). I
resurrected Qi/tk recently and cleaned it up and its coming out in
installments on qilang (I'm nearly there). Its slow because I fell
ill in 2005 and have many things to do (my book 'Functional
Programming in Qi' comes out next year), but also because I find the
whole field of GUILs intellectually depressing. The fun is not there.
To put it in perspective you can divide things in life according to
two criteria (a) elegant and (b) useful; that gives 4 categories.
1. Elegant and useful - functional programming, types, sequent
calculus, logic programming and a whole lot of other stuff.
2. Elegant and not useful - I'd probably classify program synthesis
using Martin-Lof type theory in this category. very elegant but not
much practical use. However, maybe one day it'll get to category 1.
3. Inelegant and useful - lots of things here - GUILs, brushing your
teeth etc.
4. Inelegant and useless - the worst, voting for any major party in
the UK ;(, filling out assessment forms, and a mass of meaningless
stuff.
I've spoilt myself disgustingly in category 1, dabbled happily in
wasted hours in 2. with resolution theorem-provers and synthesising
programs that add 2 and 2 together in 3 seconds ;). But what I find
is that when I go into category 3. the fun does go. And 4. is
unspeakably awful although many people seem to live in that country.
so I guess I'm hooked on beauty and GUILs ain't it.
Mark
Ken Tilton
Mark Tarver wrote:
>>Nowhere in your treatise do you define and/or justify the charge of messy.
>
>
> Messy for the reasons I gave.
Ah, I see it now, sorry, I am too much of an applications guy, I look at
a big GUI manual and worry about whether it offers enough hookns that I
can make things even bigger and hairier. You are looking for that seven
functions thing to make a Lisp or whatever the angels on the head of a
pin crowd likes to go on about.
Fine, your definition of messy is locked in. We proceed.
> In Lisp, I used to introduce students
> by showing them CAR, CDR, CONS and a few other functions and showing
> how Turing equivalence could be gained in an instruction set of about
> half-a-dozen functions - everything else that was thrown in, I told
> them, was often about convenience and speed.
>
> In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
> detail without any guiding idea of what would correspond to the vital
> primitive instruction set. Because of this, and because I have no
> idea what the primitives are in that system that constitute a
> computationally adequate set, there are certain questions I cannot
> answer with confidence.
You wouldn't happen to be working on a type-inferencing static thingy
would you? <g> It's the root of all evil! I digress. We proceed.
>
> For example, could I produce a window with bevelled edges in TCL/tk -
> or a triangular window or .... fill in your outlandish request. Well
> maybe, but I'd have to check it out. In contrast if I'm asked to
> write a prime number program in Lisp I don't have to think 'Does Lisp
> have a prime number recognisor?'. I know I can do it because prime
> recognition is effectively computable and Lisp incorporates a Turing-
> equivalent set of functions. I can't say the same in TCL/tk because
> the theory is not there.
>
> Have a good set of primitives in a well-defined theory not only allows
> you to approach programming tasks with confidence, it also allows
> system programmer to develop tight, reliable and efficient
> implementations because they can focus on hard-coding these primitives
> to run efficiently. Applications people can then develop libraries
> for standard apps.
>
>
>>< http://www.tilton-technology.com/cello-shot-05.jpg
>
>
> People show me stuff. GUIL designers like to show off with 'Look Ma,
> no hands examples' - examples that pander to the preprogrammed
> functionality thats incorporated into the system. It doesn't do much
> for me.
Then I am so fucking happy that that is not what I just showed you. Of
course you could not know I was not showing you that because you already
knew what I was showing you so you had to see that. Sure, I /told/ you
there were only two classes Image and Control, but when has the human
mind ever had a problem blocking out information inconsistent with what
it knows?
Cello makes all its own widgets out of Image and Control. Where those
are (OK, I confess) subclassed it is just syntactic sugar. Anyone who
does not like my Slider widget will look at the code and say, that
sucks, and build their own slider out of the same GUI control and image
primitives.
A good example (Why am I bothering?) of the sugar thing is my stack and
row gui container classes. They let you control spacing, frame,
surrounding margin, and alignment (say, for rows) of left right or
center. Individual children are free to specify their own relative
horizontal position, but not their vertical. Preprogrammed! you are
bellowing already, and again you guess wrong, but I understand how that
saves you from actually having to learn something new. In fact it turns
out the whole thing is just more sugar, leveraging the kid-slotting
capabilities of the Cells Family class, which is allowed to supply rules
for kids's slots (with an option to force the rule in or add it only if
the child has left the slot unbound). Uh, in this case it is supplying
rules for the x and y coordinates.
I guess the big problem then is what Qi will think of slots whose type
is "anything any rule any programmer wants to supply for any slot", and
I guess t is an unsatisfactory answer.
> Nice picture of your hand though.
You have a penchant for mistaken assumptions. No wonder you need static
typing. :)
>
>
>>Fine, you have now declared that all GUILs are messy and that in
>>principle no GUIL can be non-messy,
>
>
> No, I asserted the contrary w.r.t. the last part. I think that GUILs
> can be made elegant but stuff needs refiguring. Its not trivial.
Do what I did, start with OpenGL and the Glut. The former will let you
play with a rectangle of values, RGBA, ignore all the other stuff (what
is it, gluOrtho2D to duck the third dimension and perspective?) unless
you find the OpenGL model elegant. Small, no, but you might find it
elegant. Me, I am just a simple application programmer, I cannot
understand a word of it. But I sees lotsa math in there, that's elegant,
right?
The Glut will give you your GUI primitives: mouse buttons up and down,
key up and down, over to you. Freeglut or Openglut, pick yer poisson.
If you want to do text, cheat a little and use FreeType, or cheat a lot
and use FTGL, it will handle the xlate to OpenGL.
>
>
>>Meanwhile users of Cello and Cells-Gtk and Adobe Adam/Eve and some
>>FrTime thingy are having a ball with GUIs while you will be moderating
>>this closed-minded thread. Just peachy.
>
>
>>So when are you announcing.... QUIL?
>
>
> Well Qi/tk first ran in *2002* and I used it to produce a moving
> histogram to plot traffic for a multi-agent model of a transport
> system. You can read about the model here and it was all type secure
> back then.
>
> http://www.lambdassociates.org/webbook/chap17.htm
>
> http://www.lambdassociates.org/webbook/chap1.htm
> section 1.8 mentions this work.
>
> When I got over the thrill of being able to write 'Hello World' in 3
> inch high yellow letters in type secure code, I put it away. I had
> more important things to figure on - for example, correctness proofs
> for Qi (no point having a system that produces wrong answers). I
> resurrected Qi/tk recently and cleaned it up and its coming out in
> installments on qilang (I'm nearly there).
Cool, good luck with that,
> Its slow because I fell
> ill in 2005 and have many things to do (my book 'Functional
> Programming in Qi' comes out next year), but also because I find the
> whole field of GUILs intellectually depressing. The fun is not there.
Get the Togl widget. OpenGL made me young again, and OpenAL has its
moments. Yeah, this means sticking with Tk, but make the whole window
one Togl widget and have Glut on steroids.
>
> To put it in perspective you can divide things in life according to
> two criteria (a) elegant and (b) useful; that gives 4 categories.
>
> 1. Elegant and useful - functional programming, types, sequent
> calculus, logic programming and a whole lot of other stuff.
>
> 2. Elegant and not useful - I'd probably classify program synthesis
> using Martin-Lof type theory in this category. very elegant but not
> much practical use. However, maybe one day it'll get to category 1.
>
> 3. Inelegant and useful - lots of things here - GUILs, brushing your
> teeth etc.
>
> 4. Inelegant and useless - the worst, voting for any major party in
> the UK ;(, filling out assessment forms, and a mass of meaningless
> stuff.
>
> I've spoilt myself disgustingly in category 1, dabbled happily in
> wasted hours in 2. with resolution theorem-provers and synthesising
> programs that add 2 and 2 together in 3 seconds ;). But what I find
> is that when I go into category 3. the fun does go. And 4. is
> unspeakably awful although many people seem to live in that country.
>
> so I guess I'm hooked on beauty and GUILs ain't it.
Guess again: http://www.tilton-technology.com/cello-shot-06.jpg
kt (greatly looking forward to being complimented on my girlfriend)
Mark Tarver
> can make things even bigger and hairier.
That is indeed the opposite of what I look for. If that has driven
your development of Cello, then we're not in the same ball park at
all.
> Then I am so fucking happy that that is not what I just showed you. Of
> course you could not know I was not showing you that because you already
> knew what I was showing you so you had to see that. Sure, I /told/ you
> there were only two classes Image and Control, but when has the human
> mind ever had a problem blocking out information inconsistent with what
> it knows?
Well actually I saw the picture of a hand - which doesn't really tell
me much! The image and control sounds interesting, but is too
programmatic for anyone to respond to other than by saying 'sounds
interesting' without references.
> I guess the big problem then is what Qi will think of slots whose type
> is "anything any rule any programmer wants to supply for any slot", and
> I guess t is an unsatisfactory answer.
Well such a slot can be given the type A for some A which just means
that the type checker will know that something well-typed is in
there. The problem will be that in such a situation the type
constraints will be so weak that you won't be able to do much with
that rule in a type secure manner. I think in the individual case it
would be possible to be more forthcoming than that. Cells might
benefit from an injection of type theory in its constraint propagation
system. (Probably should not have said that ;))
> kt (greatly looking forward to being complimented on my girlfriend)
Now that is a screen shot ;). My compliments.
Mark
Brian Adkins
> ...
> Cello makes all its own widgets out of Image and Control. Where those
> are (OK, I confess) subclassed it is just syntactic sugar. Anyone who
> does not like my Slider widget will look at the code and say, that
> sucks, and build their own slider out of the same GUI control and image
> primitives.
Has anyone created Cello widgets with a native look & feel for XP/
Vista and/or Mac OSX ? Have you experienced much demand for that?
I've been developing web apps for years, so I'm out of touch with
current GUI demand, but when I developed Java GUI apps, the customers
didn't seem to be as excited as we were that the app ran on Windows,
Mac & *nix - they just wanted it too look good on their particular
platform.
Ken Tilton
Mark Tarver wrote:
>>Ah, I see it now, sorry, I am too much of an applications guy, I look at
>>a big GUI manual and worry about whether it offers enough hooks that I
>>can make things even bigger and hairier.
>
>
> That is indeed the opposite of what I look for. If that has driven
> your development of Cello,...
Lessee, you read what I look for in off-the-shelf GUIs which I cannot
change and thus might find myself unable to use in some way I need to
use and worry I would have the same attitude towards something I am
writing from scratch. Hmmm....
> then we're not in the same ball park at
> all.
Well I described my ballpark in enough detail for you to understand that
what I have instead is the legendary Seven Pillars of Primitiveness...
could someone tell me why I even bother trying? This makes my Freecell
obsession look reasonable.
>
>
>>Then I am so fucking happy that that is not what I just showed you. Of
>>course you could not know I was not showing you that because you already
>>knew what I was showing you so you had to see that. Sure, I /told/ you
>>there were only two classes Image and Control, but when has the human
>>mind ever had a problem blocking out information inconsistent with what
>>it knows?
>
>
> Well actually I saw the picture of a hand - which doesn't really tell
> me much!
Actually, I was wondering how you (mis)concluded from the screenshot
that you were looking at a classic preprogrammed widget set that did
exactly what it wanted and nothing more, now we learn it did not tell
you much. I detect progress!
> The image and control sounds interesting, but is too
> programmatic for anyone to respond to other than by saying 'sounds
> interesting' without references.
Here is a tip-off: I no longer have to write paint methods for custom
widgets, I build anything I like up out of (wait for it) graphical
primitives and a bit of a DSL to orchestrate them all, with scripts
appearing in the "layers" slot.
the neat thing is that this all evolved on its own. I started with
layers for just the background color and frame, boom!, out burst a DSL
that just took over the painting and pushed custom paint methods into
the sea.
And really there are no methods specialize on Image and Control, they
are authored with cells and then functions can handle any widget cuz...
well, it's like building CL out of seven functions or one or however
many angels are on the head of the pin.
>
>
>>I guess the big problem then is what Qi will think of slots whose type
>>is "anything any rule any programmer wants to supply for any slot", and
>>I guess t is an unsatisfactory answer.
>
>
> Well such a slot can be given the type A for some A which just means
> that the type checker will know that something well-typed is in
> there. The problem will be that in such a situation the type
> constraints will be so weak that you won't be able to do much with
> that rule in a type secure manner. I think in the individual case it
> would be possible to be more forthcoming than that. Cells might
> benefit from an injection of type theory in its constraint propagation
> system. (Probably should not have said that ;))
But different instances can have different rules for the same slot, and
in fact this is precisely why a big hairy GUI can be built from two
classes, Image and Control, so I think you are still stuck trying to
prove anything more than (typep everything t).
>
>
>>kt (greatly looking forward to being complimented on my girlfriend)
>
>
> Now that is a screen shot ;). My compliments.
Thx, I'll tell her you said that.
kt
Mark Tarver
>
> "Mother always told me, if you tell a lie,
> always rehearse it. If it don't sound good
> to you, it won't sound good to no one else."
> - Satchel Paige
Sound and bombast aside I'm not sure much of what you've said has
addressed anything in my original post. Perhaps under the self-
advertising there is a reference but I've yet to receive it. So why
should I or anybody roll over and be impressed? What has a picture of
a hand or your girlfriend going to do for me?
You mock the idea of a proper theoretical study and a canonical
set of GUI primitives and means of combination as a search for the 7
Pillars. That makes me think 'He hasn't done this work'; but from that
to infer that it cannot or should not be done is a leap of what? Logic
it is not.
Elsewhere you hint that in some fashion you have that very theory
yourself. But where is it - have you written it down and if so
where is it? Is there an existence proof and don't point me to 30,000
lines of your code lashed on to another 30,000 lines of somebody
else's code as a substitute. What we are needing is a profound
theory of space, state and time. I don't see evidence of that in
your posts (and papers, not posts are where such a theory belongs).
Things that are built on a firm foundation of theory do last. Lisp
lasted because under the later accretions of gunge there ws something
profound and perennial. Prolog and ML too. Software built on the
foundations of eternity does last. Stuff that is cooked up or lashed
together on the whim of the inventor may survive for a time as useful,
but its existence is numbered.
At a mundane level, I'm pragmatic enough to realise that what I have
in Qi/tk is probably enough for most people to do the things they want
and probably more than many people get. Buttons, sliders etc. etc -
yeah I can do that. And I'm not going to be the guy who does this
work on the theory of SST because in the remainder of my life I want
to do other things. But that mountain is there for somebody to climb
- one day.
Mark
John Thingstad
You seem to miss the point that flow controled IO is a established
approach to UI design.
It is based on the old flow charts you may remember from 'software through
pictures' (or not).
User IO is never going to be beautiful. It never was and it never will be.
My solution is to use designers and to focus on the program domain code.
For some people the way it looks is far more important than how it got
there...
Mark Tarver
>
> - Show quoted text -
Yes, end users sans CS experience don't care about how things are done
but just how it looks at the end. But I didn't start this thread from
their angle. You may be right that this field is never going to be
beautiful - that means its inherently category 3 in my list. Still
thats a shame if true.
Right now I am focussing on something on category 1 - useful and
elegant - its not in GUILs though, but in automated reasoning.
Mark
verec
>> At a mundane level, I'm pragmatic enough to realise that what I have
>> in Qi/tk is probably enough for most people to do the things they want
>> and probably more than many people get. Buttons, sliders etc. etc -
>> yeah I can do that. And I'm not going to be the guy who does this
>> work on the theory of SST because in the remainder of my life I want
>> to do other things. But that mountain is there for somebody to climb
>> - one day.
>>
>> Mark
>>
>
> You seem to miss the point that flow controled IO is a established
> approach to UI design.
> It is based on the old flow charts you may remember from 'software
> through pictures' (or not).
> User IO is never going to be beautiful. It never was and it never will
> be. My solution is to use designers and to focus on the program domain
> code. For some people the way it looks is far more important than how
> it got there...
What Mr Tarver seems to be after is a theory. How well does
an "approach" qualify? It would perhaps help if "User IO" and
the older MVC "approach" were disqualified on the ground of the
"7 missing primitives". While I do have a feel of what Mr Tarver
is after, I'm not sure I really understand it.
For example, all GUIs have graphics primitives of some sort.
This doesn't qualify as a whole nor complete set of fundation;
most notably, user input and event handling are not addressed.
But nowhere in the (quote atom eq car cdr cons cond) set was
the idea of DSL (let alone macros) or currying or whatnot
explicitely present either. Not even the REPL! (But we're
back in GUI^H^H^HCLI land again, I suppose :-)
Or are we all stuck in "the state of the art", without any
clear insight of what generative principles could be unearthed?
--
JFB
Ben Rudiak-Gould
> For example, could I produce a window with bevelled edges in TCL/tk -
> or a triangular window or .... fill in your outlandish request. Well
> maybe, but I'd have to check it out. In contrast if I'm asked to
> write a prime number program in Lisp I don't have to think 'Does Lisp
> have a prime number recognisor?'. I know I can do it because prime
> recognition is effectively computable and Lisp incorporates a Turing-
> equivalent set of functions. I can't say the same in TCL/tk because
> the theory is not there.
I can't make any sense of your analogy. Turing completeness is easy. All
general purpose programming languages are Turing complete, but you wouldn't
say that any one is as good as any other. If you just want a general set of
GUI primitives, that's easy too: setting screen pixels and getting keyboard
and mouse state change events. But that can't be what you want.
Ken Tilton wrote:
> http://www.tilton-technology.com/cello-shot-05.jpg
It actually wasn't until I read further in the thread that I realized that
this was supposed to be a positive example. I originally took it to be an
illustration of what's gone wrong with GUI design -- the same basic widgets
we had on the 128K Mac, but now in garish colors with pointless 3D.
I know this is just a demo app, but I still feel justified in complaining
that it doesn't do anything interesting. A user interface, to me, is a way
of visualizing and possibly modifying some form of structured data. This
example is a degenerate case of that: a single object whose properties are
all real-valued or enumerated, and few enough that they can all be put on
screen at once. It doesn't begin to touch on what makes UI design
interesting or difficult. You seem to be saying that there's a very general
framework under the hood; okay, but do you have any examples where it serves
some purpose? I'd be interested in seeing an interface to a relational
database or a function of one complex variable that had some advantage over
existing software, by being more flexible or, failing that, at least being
easier to implement.
-- Ben
Mark Tarver
> Mark Tarver wrote:
> > For example, could I produce a window with bevelled edges in TCL/tk -
> > or a triangular window or .... fill in your outlandish request. Well
> > maybe, but I'd have to check it out. In contrast if I'm asked to
> > write a prime number program in Lisp I don't have to think 'Does Lisp
> > have a prime number recognisor?'. I know I can do it because prime
> > recognition is effectively computable and Lisp incorporates a Turing-
> > equivalent set of functions. I can't say the same in TCL/tk because
> > the theory is not there.
>
> I can't make any sense of your analogy. Turing completeness is easy. All
> general purpose programming languages are Turing complete, but you wouldn't
> say that any one is as good as any other. If you just want a general set of
> GUI primitives, that's easy too: setting screen pixels and getting keyboard
> and mouse state change events. But that can't be what you want.
>
Actually setting screen pixels and keyboard events is not absurd.
I would not reject, out of hand, somebody who began there. But there
is more to the story.
If you look at the COND CAR CDR CONS ... primitives of Lisp they are
pretty low level. *The power comes from the ability to set barriers
of abstraction through the powerful means of combination.*
So if you have even a very low level set of primitives then provided
(a) your encoding of these primitives is fast and (b) your means of
combination is very powerful, you can get somewhere fairly quickly.
The problem with weak Turing-equivalent languages like Turing machines
is that their abstraction building powers are very limited and they
never gravitate far from their origins. Its not enough to throw a set
of primitives - you have to set up the primitives so that you can
marshal them effectively into larger wholes.
This philosophy, somewhere, is in SICP.
Mark
Mark Tarver
As I remarked in the post to Mr Gould - selecting the right primitives
(whilst important) is half the story - probably less.
> But nowhere in the (quote atom eq car cdr cons cond) set was
> the idea of DSL (let alone macros) or currying or whatnot
> explicitely present either. Not even the REPL! (But we're
> back in GUI^H^H^HCLI land again, I suppose :-)
Um, well you know that McCarthy said somewhere that he really didn't
understand Church's work that well when he built Lisp.
Actually skimming McCarthy's paper on the History of Lisp, I find
no mention of Church at all. This does not detract from his
achievement though.
Also Lisp picked up a lot of destructive stuff partly because
at the time it was designed, people didn't know much about how
to compile FPLs and the computers were about 10^5 times slower than
now (at a guess).
>
> Or are we all stuck in "the state of the art", without any
> clear insight of what generative principles could be unearthed?
> --
Thats what I think.
Mark
Jon Harrop
> On 13 Oct, 12:12, Ben Rudiak-Gould <br276delet...@cam.ac.uk> wrote:
>> I can't make any sense of your analogy. Turing completeness is easy. All
>> general purpose programming languages are Turing complete, but you
>> wouldn't say that any one is as good as any other. If you just want a
>> general set of GUI primitives, that's easy too: setting screen pixels and
>> getting keyboard and mouse state change events. But that can't be what
>> you want.
>
> Actually setting screen pixels and keyboard events is not absurd.
Actually, I think it is absurd to set pixels. If you want to write a GUI
library from the ground up then at least start with something like OpenGL
so you can exploit hardware acceleration where it is available.
I would actually recommend building on top of a general purpose vector
graphics library like Smoke:
http://www.ffconsultancy.com/products/smoke_vector_graphics/?clf
Mark Tarver
'P is not absurd' is in my terms a very weak assertion (just as 'P is
absurd' is a very strong one). Saying something is absurd means for
me it is so obviously wrong as not to countenance any consideration.
'P is not absurd but P is wrong' is not inconsistent. So don't take
my weak assertion to be an endorsement - it is not.
Mark
Ken Tilton
I think for the native thang you want Celtk and the Tile package of Tk,
which tries harder on native look and feel. Gets good press, anyway.
Cello is for them's that have not much need for standard widgets and so
they really just get in the way -- I toyed with mixing Tk widgets with a
Togl OpenGL subpane or two and realized right away that it was not just
widgets I was mixing, I was now dealing with two frameworks
simultaneously. Ewww, as the kids say.
What one could do is use Celtk and then have a Togl pane for a killer
view-only purpose.
kt
Brian Adkins
> Ken Tilton wrote:
> >http://www.tilton-technology.com/cello-shot-05.jpg
>
> It actually wasn't until I read further in the thread that I realized that
> this was supposed to be a positive example. I originally took it to be an
> illustration of what's gone wrong with GUI design -- the same basic widgets
> we had on the 128K Mac, but now in garish colors with pointless 3D.
I think you're confusing the user's perspective with the programmer's
perspective. This thread is all about the latter, and you're asking
for trouble by bringing the former into it.
dkf
> The problem for me comes from the broken, hard wired assumptions the
> toolkit designers often make about how the primitives should be tied
> together. Without access to the primitives it becomes extremely
> difficult or impossible to get the behavior one wants without going
> outside the toolkit.
Out of curiosity, what are those "broken, hard wired assumptions"? I
suppose it's nice enough to make such an assertion, but if the
specifics are not brought out into the open air and examined, it's
just going to frustrate those of us who might possibly do something
about it. :-)
(BTW, please also Cc: me your reply; I don't usually read this group
and I'm on the road for the next week anyway so might forget to check
for followups. Thanks in advance!)
Donal Fellows.
Ken Tilton
Ben Rudiak-Gould wrote:
> Mark Tarver wrote:
>
>> For example, could I produce a window with bevelled edges in TCL/tk -
>> or a triangular window or .... fill in your outlandish request. Well
>> maybe, but I'd have to check it out. In contrast if I'm asked to
>> write a prime number program in Lisp I don't have to think 'Does Lisp
>> have a prime number recognisor?'. I know I can do it because prime
>> recognition is effectively computable and Lisp incorporates a Turing-
>> equivalent set of functions. I can't say the same in TCL/tk because
>> the theory is not there.
>
>
> I can't make any sense of your analogy. Turing completeness is easy. All
> general purpose programming languages are Turing complete, but you
> wouldn't say that any one is as good as any other. If you just want a
> general set of GUI primitives, that's easy too: setting screen pixels
> and getting keyboard and mouse state change events. But that can't be
> what you want.
>
> Ken Tilton wrote:
>
>> http://www.tilton-technology.com/cello-shot-05.jpg
>
>
> It actually wasn't until I read further in the thread that I realized
> that this was supposed to be a positive example.
No, it was supposed to be a funny way of bringing up a library that is
counterexample to the OPs conviction that all GUIs are limited to that
which has been preprogrammed.
I realize it looks like a Users Guide and complete specification
justifying you and the OP delivering variously long lectures on how evil
they are... hang on, no, it is just a screenshot. Confused.
> I originally took it to
> be an illustration of what's gone wrong with GUI design -- the same
> basic widgets we had on the 128K Mac, but now in garish colors with
> pointless 3D.
You don't like orange? Meanwhile, some of us think it is pretty cool
that the 3D effect EVERY FUCKING GUI USES comes from 3D things lit at an
angle. Fine, you do not like 3d effects, make a black and white 2D
interface or go for the gold and do a 24x80 ascii interface if that is
your preference, but don't run around saying standard GUI decorations
are "pointless".
>
> I know this is just a demo app, but I still feel justified in
> complaining that it doesn't do anything interesting.
We call those self-ignoring acknowledgments. Try changing the comma to a
period and deleting the rest.
> A user interface,
> to me, is a way of visualizing and possibly modifying some form of
> structured data. This example is a degenerate case of that: a single
> object whose properties are all real-valued or enumerated, and few
> enough that they can all be put on screen at once. It doesn't begin to
> touch on what makes UI design interesting or difficult.
See, this is where you needed that insight about it being "just a demo".
> You seem to be
> saying that there's a very general framework under the hood; okay, but
> do you have any examples where it serves some purpose? I'd be interested
> in seeing an interface to a relational database or a function of one
> complex variable that had some advantage over existing software, by
> being more flexible or, failing that, at least being easier to implement.
What an obnoxious way to lead up to a question. Nowhere do you manifest
any awareness of the rest of the thread, which elucidated the lego-like
nature of the underlying system, which is about being able to do
anything you like with 3D graphics, 3D sound, QuickTime, antialiased
text, GraphicksMagick, and lowlevel access to the mouse and keyboard
allowing you to design any interface you like. The above makes it sound
like you want me to conceive your relational DB interface for you. No,
that is still your job. Cello just says there is nothing you can
conceive that you cannot also implement. Easily.
kenny
Raffael Cavallaro
> Out of curiosity, what are those "broken, hard wired assumptions"? I
> suppose it's nice enough to make such an assertion, but if the
> specifics are not brought out into the open air and examined, it's
> just going to frustrate those of us who might possibly do something
> about it. :-)
Well, since this is comp.lang.lisp, let's look at LispWorks CAPI as an
example. It's broken on the Mac OS in part because it has a unifying
concept of an "interface" which unnecessarily joins windows and menus
at the hip. On some platforms these things are necessarily connected
(or normally connected - windows having menus in their title bars). On
Mac OS they are independent GUI elements and shouldn't be tied together
by the toolkit.
That's a concrete example. The take-away lesson is that a cross
platform GUI toolkit designer shouldn't try to anticipate possible uses
to which various elements might be put in what combinations. Everything
that can possibly be kept independent and orthogonal should be. It's
straightforward enough given the primitives to build simple connections
of the usual suspects in the ususal platform standard way and to
provide these as libraries - "windows xp standard window," e.g. But
going the other way - undoing a hard wired connection between or among
UI elements pretty much necessitates going behind the GUI tookit's back
or subverting it altogether.
regards,
Ralph
regards,
Ralph
Rainer Joswig
<2007101317344911272-raffaelcavallaro@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2007-10-13 16:53:19 -0400, dkf <donal.k...@man.ac.uk> said:
>
> > Out of curiosity, what are those "broken, hard wired assumptions"? I
> > suppose it's nice enough to make such an assertion, but if the
> > specifics are not brought out into the open air and examined, it's
> > just going to frustrate those of us who might possibly do something
> > about it. :-)
>
> Well, since this is comp.lang.lisp, let's look at LispWorks CAPI as an
> example. It's broken on the Mac OS in part because it has a unifying
> concept of an "interface" which unnecessarily joins windows and menus
> at the hip. On some platforms these things are necessarily connected
> (or normally connected - windows having menus in their title bars). On
> Mac OS they are independent GUI elements and shouldn't be tied together
> by the toolkit.
>
> That's a concrete example. The take-away lesson is that a cross
> platform GUI toolkit designer
To be fair, the LispWorks toolkit was not designed for general
cross-platform usage, I'd say.
The LispWorks toolkit used Motif (IIRC) since it appeared
on workstations many years ago. Motif uses mostly an old Windows model.
LispWorks for Windows appeared later and there
were probably not that many conceptual differences.
The Mac port was late. What they did mostly was to
adapt their toolkit CAPI to a Cocoa-based UI.
They have not redesigned the Toolkit so you can really
adapt to the different styles of User Interfaces.
To give an example:
On Windows the dialog asks something like 'Save file blabla?'
and the buttons are "Yes" and "No". (trying to remember,
hope I got that right, somehow)
On the Mac the dialog says 'Save as: blabla' and the buttons
are "Save" and "Cancel".
There is no way to anticipate what some future platform
might do. BeOS? No idea. Apple's touch UI? No idea.
But there is also no automatic way to derive the
dialog texts from a single set of strings.
Probably you have to give the texts for each and
every different platform. That means the toolkit
is only really cross-platform for those platforms
it was designed for.
Consequently LispWorks uses sometimes wrong button texts on
the Mac, because it was not designed for that and
the design later has not been extended to do so.
Common Lisp has the problem with yes-or-no-p.
On Windows you would call (yes-or-no-p "make darjeeling tea?")
and get the right question with yes and no buttons.
But on the Mac the buttons should be called "make" and
"cancel".
So. I'd say CAPI was not really designed as a cross-platform toolkit
with non-windows (or non-Motif) user interfaces in mind.
verec
>> I originally took it to be an illustration of what's gone wrong with
>> GUI design -- the same basic widgets we had on the 128K Mac, but now in
>> garish colors with pointless 3D.
>
> You don't like orange? Meanwhile, some of us think it is pretty cool
> that the 3D effect EVERY FUCKING GUI USES comes from 3D things lit at
> an angle. Fine, you do not like 3d effects, make a black and white 2D
> interface or go for the gold and do a 24x80 ascii interface if that is
> your preference, but don't run around saying standard GUI decorations
> are "pointless".
Pointless as in "not adding value to the task at hand".
You see, Sir K, either you have something called taste,
or you don't. And when you don't, not only can you NOT
see that you don't, but this allows you to push the
ridicule in making yourself the fool to the eye of those
who can see. Buy glasses, some wine, talk to your girl
friend-the-beautiful and give us a break.
Whether "cell" is, or not, an interesting development
has nothing to do with th hideuous color scheme that
you have used to show-case its strength. No wonder there
is such a large following behind it! :-)
--
JFB
Joachim Durchholz
> Out of curiosity, what are those "broken, hard wired assumptions"?
Stuff like:
* Grid cells, treeview labels, and menu entries can have only text.
Oh, wait, you can have an icon, too. (That's what you have to deal
with on Windows. There are workarounds, but they are... ewwww.)
* You don't get back all the parameters of a control.
* You don't get all the relevant dimensions of a control.
(E.g. for a text input control, you need outer borders, inner borders,
the position of the actual text area, and the text baseline.)
(The "broken assumption" in the "you don't get" items is that the
programmer will never need these values. Try to line up a label's
base line with the base line of a text input field and you know what
I mean.)
Sometimes, however, doing things orthogonally is hard, really hard, or
even really d***ed hard:
* Fill a grid column with a tree view.
* Make a dialog automatically adapt to size changes.
(Doing this well means you need a constraint solver.
OTOH having a constraint solver in the standard library seems a good
idea for other purposes, so...)
* Tab order. (It doesn't compose: defining a tab order for a group of
controls will often not work well when moving it to a different
context.)
* Hotkey management. No way to do that in a modular fashion, sticking
together groups of controls with pre-assigned hotkeys will often
produce a conflict.
Things usually get far worse when the software gets localized to a
different language, because in most cases, the translator doesn't get
to see the dialog in its entirety, just individual texts.
Oh, and the hotkeys must not conflict with menu hot keys either.
So, change the hotkey on a menu item and watch the hotkeys of all
your dialogs collide (but only those where that menu item is enabled,
and since determining the enabled state of a menu item is usually
equivalent to the Halting Problem, it's even difficult to do proper
tool support for such a situation).
These are just the things off the top of my head. I'm quite sure that
this list is very, very non-exhaustive.
Regards,
Jo
Neelakantan Krishnaswami
Mark Tarver <dr.mt...@ukonline.co.uk> wrote:
>
> Now I sat down and wondered why that was. Was the field inherently
> just a big intellectual hack, or have human beings made a mess of
> it. I decided that was probably more that human beings made a mess
> of it and that there was a much more elegant approach. We had to
> begin with a formal theory of widgets and by asking dumb-sounding
> but actually deeply serious questions like 'What is a window'?
Take a look at Antony Courtney's PhD thesis, "Modelling User
Interfaces in a Functional Language". You can find it online at
<http://http://www.apocalypse.org/~antony/work/pubs/ac-thesis.pdf>
In this thesis, he does ask questions like "What is a window?", and
answers them with a denotational semantics of graphical user
interfaces in terms of synchronous dataflow. He then uses this to
guide the design and implementation of a small GUI toolkit for
Haskell.
There are certainly places where you can question his design choices,
but the cool thing is you can *really* question them, because
everything is careful and precise enough that a rigorous argument
is possible.
--
Neel R. Krishnaswami
ne...@cs.cmu.edu
Jon Harrop
> dkf schrieb:
>> Out of curiosity, what are those "broken, hard wired assumptions"?
>
> Stuff like:
> * Grid cells, treeview labels, and menu entries can have only text.
> Oh, wait, you can have an icon, too. (That's what you have to deal
> with on Windows. There are workarounds, but they are... ewwww.)
Is that true of Windows Presentation Foundation?
> * You don't get back all the parameters of a control.
> * You don't get all the relevant dimensions of a control.
> (E.g. for a text input control, you need outer borders, inner borders,
> the position of the actual text area, and the text baseline.)
And that's just for Latin derivatives....
> (The "broken assumption" in the "you don't get" items is that the
> programmer will never need these values. Try to line up a label's
> base line with the base line of a text input field and you know what
> I mean.)
That problem plagues HTML even more, IMHO.
> Sometimes, however, doing things orthogonally is hard, really hard, or
> even really d***ed hard:
> * Fill a grid column with a tree view.
> * Make a dialog automatically adapt to size changes.
> (Doing this well means you need a constraint solver.
> OTOH having a constraint solver in the standard library seems a good
> idea for other purposes, so...)
Interesting...
> * Tab order. (It doesn't compose: defining a tab order for a group of
> controls will often not work well when moving it to a different
> context.)
> * Hotkey management. No way to do that in a modular fashion, sticking
> together groups of controls with pre-assigned hotkeys will often
> produce a conflict.
> Things usually get far worse when the software gets localized to a
> different language, because in most cases, the translator doesn't get
> to see the dialog in its entirety, just individual texts.
> Oh, and the hotkeys must not conflict with menu hot keys either.
> So, change the hotkey on a menu item and watch the hotkeys of all
> your dialogs collide (but only those where that menu item is enabled,
> and since determining the enabled state of a menu item is usually
> equivalent to the Halting Problem, it's even difficult to do proper
> tool support for such a situation).
>
> These are just the things off the top of my head. I'm quite sure that
> this list is very, very non-exhaustive.
A fascinating enumeration. :-)
Mark Tarver
> In article <<1192193369.982602.157...@t8g2000prg.googlegroups.com>>,
Very good; at first glance something like this was what I had in
mind.
Mark
Joachim Durchholz
> Joachim Durchholz wrote:
>> dkf schrieb:
>>> Out of curiosity, what are those "broken, hard wired assumptions"?
>> Stuff like:
>> * Grid cells, treeview labels, and menu entries can have only text.
>> Oh, wait, you can have an icon, too. (That's what you have to deal
>> with on Windows. There are workarounds, but they are... ewwww.)
>
> Is that true of Windows Presentation Foundation?
Dunno.
My practical experience is limited to the classic GDI functions.
As far as I can tell from a few cursory looks through the docs, GDI+
(the .net equivalent of GDI) is a lot better but is still limited.
I know even less about WPF, so I'll leave that to others to comment upon.
>> * You don't get back all the parameters of a control.
>> * You don't get all the relevant dimensions of a control.
>> (E.g. for a text input control, you need outer borders, inner borders,
>> the position of the actual text area, and the text baseline.)
>
> And that's just for Latin derivatives....
Oh, right. It would be interesting to see what the requirements for a
vertical script are. And whether it would be culturally acceptable to
use horizontal lines anyway. (How would a Japanese quote an Englisch
name when writing vertically? I don't have the faintest idea...)
>> (The "broken assumption" in the "you don't get" items is that the
>> programmer will never need these values. Try to line up a label's
>> base line with the base line of a text input field and you know what
>> I mean.)
>
> That problem plagues HTML even more, IMHO.
I'd say that's a deficit of the rendering engines.
Which in turn seem to have given up on the issue because the native
toolkits don't support baseline positioning. (Well, GDI doesn't. I don't
know how it would be on X or whatever.)
>> Sometimes, however, doing things orthogonally is hard, really hard, or
>> even really d***ed hard:
>> * Fill a grid column with a tree view.
>> * Make a dialog automatically adapt to size changes.
>> (Doing this well means you need a constraint solver.
>> OTOH having a constraint solver in the standard library seems a good
>> idea for other purposes, so...)
>
> Interesting...
The GUI framework I have worked on had some size adaptation techniques,
and it turned out that the thing became immensely complicated after
acquiring too many ways to let the constraint information flow. We had
all kinds of problems propagating the constraints across the container
hierarchy: endless cycles, surprising effects, overcomplicated and
moderately difficult-to-maintain code that worsened little by little,
and the rare case where a desired behaviour couldn't be easily
expressed. A constraint solver would have been just as complicated as
what we had, but it wouldn't have had that complication creep.
(I even explored possibilities to retrofit a constraint solver, but the
project was dropped. Part of this was that it would have pushed our time
budget, but more important was that it would have been difficult to
display and handle the constraints in the designer application. I.e.
you'd want to attach the constraints to the containers and controls that
the user sees on the screen, but trying to draw numerous constraints in
the same screen space gets you into placement conflicts. Getting this
all polished would have been definitely too much work for the workforce
at hand.)
That constraint solvers are interesting beyond that areas is a van
Roy/Haridi influence:
Peter van Roy, Seif Haridi: Concepts, Techniques, and Models of Computer
Programming. The MIT Press, April 2004.
Regards,
Jo
Ken Tilton
verec wrote:
> On 2007-10-13 22:07:33 +0100, Ken Tilton <kenny...@optonline.net> said:
>
>>> I originally took it to be an illustration of what's gone wrong with
>>> GUI design -- the same basic widgets we had on the 128K Mac, but now
>>> in garish colors with pointless 3D.
>>
>>
>> You don't like orange? Meanwhile, some of us think it is pretty cool
>> that the 3D effect EVERY FUCKING GUI USES comes from 3D things lit at
>> an angle. Fine, you do not like 3d effects, make a black and white 2D
>> interface or go for the gold and do a 24x80 ascii interface if that is
>> your preference, but don't run around saying standard GUI decorations
>> are "pointless".
>
>
> Pointless as in "not adding value to the task at hand".
You don't like 3d buttons? Who does not like 3d buttons? Or is it that
you think they do not offer any useability value, such as cueing the
user that "you can mess with this if you like"? Or "this control is
enabled now"? Or a stronger cue than a plain 1-pixel frame that "these
things go together? In brief, nonsense.
> You see, Sir K, either you have something called taste,
> or you don't. And when you don't, not only can you NOT
> see that you don't, but this allows you to push the
> ridicule in making yourself the fool to the eye of those
> who can see. Buy glasses, some wine, talk to your girl
> friend-the-beautiful and give us a break.
Believe me, if that was my girlfriend I would not be talking with you guys.
>
> Whether "cell" is, or not, an interesting development
> has nothing to do with th hideuous color scheme that
> you have used to show-case its strength. No wonder there
> is such a large following behind it! :-)
OK, you are completely confused and reading too fast, upthread I have
already excoriated the yobbos for looking at screenshots and reacting
only to my choice of skins, now you come along to complain about my
choice of skin. Juuust peachy.
kt
Ken Tilton
Yeah, maybe in another ten years you clowns will realize why I like Cells.
>
>
>>* Tab order. (It doesn't compose: defining a tab order for a group of
>> controls will often not work well when moving it to a different
>> context.)
>>* Hotkey management. No way to do that in a modular fashion, sticking
>> together groups of controls with pre-assigned hotkeys will often
>> produce a conflict.
>> Things usually get far worse when the software gets localized to a
>> different language, because in most cases, the translator doesn't get
>> to see the dialog in its entirety, just individual texts.
>> Oh, and the hotkeys must not conflict with menu hot keys either.
>> So, change the hotkey on a menu item and watch the hotkeys of all
>> your dialogs collide (but only those where that menu item is enabled,
>> and since determining the enabled state of a menu item is usually
>> equivalent to the Halting Problem, it's even difficult to do proper
>> tool support for such a situation).
>>
>>These are just the things off the top of my head. I'm quite sure that
>>this list is very, very non-exhaustive.
>
>
> A fascinating enumeration. :-)
>
Not to anyone using Eve, Flapjax, or Cello, except as a reminder of how
much pain we are no longer enduring.
Mark Tarver
>
> "Mother always told me, if you tell a lie,
> always rehearse it. If it don't sound good
> to you, it won't sound good to no one else."
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Cells or Cello might be the solution. But getting mad at people won't
help. When I brought out Qi, I got quite a rough reception on
comp.lang.functional because some of my statements, though quite
accurate, were not believed. I set about correcting that
misunderstanding by writing a study series and people eventually found
their way to my book.
Getting people to understand your position requires time, especially
if you have something substantially new to offer. What you need to do
is to do a proper presentation - a science paper that you can refer to
- that succinctly and clearly states the basis of Cello and why it is
free from the faults of other GUILs. It should be reasonably brief
and clear. Then you can cite this in posts.
If you really have the elements of what is needed - a computationally
adequate and not unmanageably large set of GUI primitives and a
powerful means of combination then you're in a strong position. If
you can give some flesh to this idea of computational adequacy and in
doing, give support to the thesis that Cello is computationally
adequate in a way that other GUILs are not then it would be great.
*I'm not attached to Qi/tk myself* - its not really the focus of my
research and I will most probably be out of CS in a year anyway. Its
just a type secure way of talking to TCL/tk and almost certainly not
the best GUIL in the world being pretty hard-wired but it works fairly
well at providing in a type secure way the basic functionality needed
to do the obvious stuff.
Mark
Ken Tilton
Thanks for your concern!
Not to worry, I abuse these yobbos for fun, not out of anger. And I am
not sure c.l.l would know what to do with KGK (Kindler Gentler Kenny),
but...
In all seriousness, I understand completely how folks can be blind to
something staring them in the face, because I did it in spades. My RtL
details a mad search for Something Better during which I quickly flipped
past the /full page/ ad for MCL in every APDA catalog every time I read
them, even tho the project I wanted SB for was prototyped in Logo!! A
whack of the Zen stick from Jeffrey Kane on macdev had me ordering a
$500 copy 5 minutes later, almost exactly twelve years ago -- Columbus
Day, 1995.
And I cannot even complain about my market penetration. Cells-Gtk is
alive and well under the capable shepherdry of Peter Denno:
http://common-lisp.net/project/cells-gtk/
... and I get a nice mention here:
http://peak.telecommunity.com/DevCenter/Trellis#the-implementation
Other things like Adobe's Adam (C++) and Flapjax (Scheme?) reassure me
that the idea is getting through, and like Lisp it has been a long road,
going back to SketchPad (Sutherland, '63).
The good news for me is that I have absolutely no need to sell Cells or
Cello, I am doing what everyone should be doing with Lisp if not Cells
-- stop worrying about getting other people to use it, use it to make
money. See sig for a link to my Cello-based upcoming release (in beta --
nah, alpha, I know it does not work -- now if anyone is interested in
helping out).
kenny
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
Didier Verna
> Messy for the reasons I gave. In Lisp, I used to introduce students by
> showing them CAR, CDR, CONS and a few other functions and showing how
> Turing equivalence could be gained in an instruction set of about
> half-a-dozen functions - everything else that was thrown in, I told
> them, was often about convenience and speed.
>
> In contrast my 802 page *partial* spec of TCL/tk includes a wealth of
> detail without any guiding idea of what would correspond to the vital
> primitive instruction set. Because of this, and because I have no
> idea what the primitives are in that system that constitute a
> computationally adequate set, there are certain questions I cannot
> answer with confidence.
Well, that's not a problem with the GUIs, that's a problem with your
documentation (who wants to learn GUI programming by reading a *spec*
anyway?).
The X11 Intrinsics for instance have a small set of primitive widgets,
and you can do all you want on top of them. Even this old and
oh-so-crappy toolkit named Motif (yes, it's based on Xt, but...) have 3
fundamental bulding blocks: the Primitive, Gadget and Manager widgets.
Everything else is based on it, and as you know, 3 is less than 7 ;-)
So to paraphrase your own argument: Motif is really 3 fundamental
widgets. Everything else is pretty much here for convenience.
But what's convenience? Well, I don't want to recode a push-button each
time I write a new application. But I'd also like built-in push-buttons
to have borders, and hell, wouldn't it be neat if I could have not only
text, but a big blinking Mickey Mouse in it?
So the problem with GUIs is that people don't want to reinvent the
wheel, and/but people also want different wheels, and expect a GUIL to
provide just the wheel they had in mind. Or at least ways to customize
the provided wheels (hence the complexity). The success of such or such
GUI[L] doesn't lie in its conception, but in whether it has a "neat"
look'n feel.
In a way, it's no different from the complexity of Common Lisp. Of
course, I might be glad to know that the core of Lisp is small, clean
and simple, but oh boy, am I glad to have a 1000 pages standard on top
of it with plenty of built-in functions, and a bunch of third-party
packages that I can use.
If there's a real problem with GUILs being a mess, it's not in the
building blocks they provide. It's rather in the inadequacy of the
chosen implementation language. The two perfect examples of this are
Motif and Gtk (admitedly, the X11's Intrinsics themselves) trying to
express OO concepts in C...
--
New @-quartet featured CD Review !!
http://www.indie-music.com/modules.php?name=News&file=article&sid=6457
Didier Verna, did...@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicętre, France Fax.+33 (1) 53 14 59 22 did...@xemacs.org
Mark Tarver
CL is overblown; but thats not the point. The point I am making goes
back to the lack of substantial theory under GUILs. The lack of a
definition of computational
adequacy and the resulting uncertainty about the exact powers of the
system and what the exact primitives are or should be. Add to that
the weak means of combining and you have a recipe for bloat.
CL is different, the bloat is partly historical. Its old and its been
around a long time and its picked up many influences along the way.
But these observations are not true of CL for anything like the same
extent.
Mark
Ulf Wiger
>
> Not to worry, I abuse these yobbos for fun, not out of anger.
Well, nice to hear that you're enjoying yourself.
Personally, I'm thoroughly unimpressed by the act of
abusing others for one's own entertainment.
(Perhaps I'm overly sensitive because I don't frequent
comp.lang.lisp, but only get a whiff of this kind of
attitude when it crosses over to comp.lang.functional.)
I contributed one post to this thread, referring to
Joe Armstrong's GUI toolkit in Erlang. I mentioned that
it has failed to gain support. It was not because the
programming model wasn't excellent - it was. It was because
most prospective users would not be interested until it
could compete aesthetically with mainstream GUIs. No-one
doubted that it could be done elegantly, but no-one
volunteered to put in the enormous amount of work required.
Amazingly, the whole discussion played out without insults.
BR,
Ulf W
Ken Tilton
Ulf Wiger wrote:
> Ken Tilton wrote:
>
>>
>> Not to worry, I abuse these yobbos for fun, not out of anger.
>
>
> Well, nice to hear that you're enjoying yourself.
> Personally, I'm thoroughly unimpressed by the act of
> abusing others for one's own entertainment.
Well the yobbos like it. It's a kinky little S&M/bondage/domination
thing they're into.
>
> (Perhaps I'm overly sensitive because I don't frequent
> comp.lang.lisp, but only get a whiff of this kind of
> attitude when it crosses over to comp.lang.functional.)
>
> I contributed one post to this thread, referring to
> Joe Armstrong's GUI toolkit in Erlang. I mentioned that
> it has failed to gain support. It was not because the
> programming model wasn't excellent - it was. It was because
> most prospective users would not be interested until it
> could compete aesthetically with mainstream GUIs. No-one
> doubted that it could be done elegantly, but no-one
> volunteered to put in the enormous amount of work required.
We call that the "waiting for the open source fairy" phenomenon. I just
abuse the hell out of people who expect me to not only produce
astonishing open source toolkits but then /document/ them, too. Me and
Joe are out here breaking our nuts for you ungratefful, whining... oh,
what's the use?
>
> Amazingly, the whole discussion played out without insults.
Oh, c.l.l is much more fun than that. We have a kennel full of hounds to
run down unsatisfactory posters, a glue factory for melting down the
ones that don't get away from the hounds, black helicopters for those
that do -- hey, make yourself useful, tell us the secret: how did you
get rid of Harrop?
Thx, kenny
Joe English
>
> The GUI framework I have worked on had some size adaptation techniques,
> and it turned out that the thing became immensely complicated after
> acquiring too many ways to let the constraint information flow. We had
> all kinds of problems propagating the constraints across the container
> hierarchy: endless cycles, surprising effects, overcomplicated and
> moderately difficult-to-maintain code that worsened little by little,
> and the rare case where a desired behaviour couldn't be easily
> expressed. A constraint solver would have been just as complicated as
> what we had, but it wouldn't have had that complication creep.
Motif, Xaw, and most other toolkits I've used have had
similar problems, with the notable exception of Tk.
In Tk, geometry propagation is strictly a two-pass process: an upward
pass to compute the required size of all windows, and a downward
pass to do the placement. Nodes in the layout tree only need to
know about their immediate children, and complicated constraint
propagation is unnecessary.
This is one of the things that Tk gets right. Tk's layout
mechanisms have a flexibility-to-ease-of-use ratio that's
unmatched by any GUI toolkit I've seen.
--Joe English
Jon Harrop
> I contributed one post to this thread, referring to
> Joe Armstrong's GUI toolkit in Erlang. I mentioned that
> it has failed to gain support. It was not because the
> programming model wasn't excellent - it was. It was because
> most prospective users would not be interested until it
> could compete aesthetically with mainstream GUIs. No-one
> doubted that it could be done elegantly, but no-one
> volunteered to put in the enormous amount of work required.
That's very interesting. Could you explain exactly what it is about Joe's
toolkit that makes it attractive from a programmer's point of view? Does it
separate design from logic so that non-coders can work on the GUI alongside
coders?
Also, would it take much work to write a back end in OCaml that targets
something like Smoke's declarative vector graphics:
http://www.ffconsultancy.com/products/smoke_vector_graphics/
I think it would be great to bridge the current gap between GUI libraries
for Linux and freeform rendering using OpenGL etc...
Joachim Durchholz
> This is one of the things that Tk gets right. Tk's layout
> mechanisms have a flexibility-to-ease-of-use ratio that's
> unmatched by any GUI toolkit I've seen.
I once dabbled with Tk, and I agree.
However, I dimly remember that its layout model covers roughly 90% of
cases, and that there was no good way to cover the remaining 10%. (IIRC
the issue was that it cannot divide up a size increase over several
controls.)
So while Tk is a good application of the KISS principle, it's not a
complete solution.
Regards,
Jo
Andrew Smallshaw
>
> So to paraphrase your own argument: Motif is really 3 fundamental
> widgets. Everything else is pretty much here for convenience.
>
> But what's convenience? Well, I don't want to recode a push-button each
> time I write a new application. But I'd also like built-in push-buttons
> to have borders, and hell, wouldn't it be neat if I could have not only
> text, but a big blinking Mickey Mouse in it?
>
> So the problem with GUIs is that people don't want to reinvent the
> wheel, and/but people also want different wheels, and expect a GUIL to
> provide just the wheel they had in mind. Or at least ways to customize
> the provided wheels (hence the complexity). The success of such or such
> GUI[L] doesn't lie in its conception, but in whether it has a "neat"
> look'n feel.
These are all "design" considerations - in the cosmetic, aesthetic
sense of the term rather than a technical or engineering sense.
Like the OP, I've looked at various GUI programming packages and
always thought "what a mess" for some reason or other. As others
have noted, the problem is usually the level of abstraction - it
is either too high limiting flexibility or too low meaning I have
consider too many details that I don't care about.
Speaking personally, I don't want _any_ of this crap polluting my
code. I'd rather separate out the aesthetic elements from the code
entirely, and be able to say in my code "this setting is alterable
by the user" and have a UI that was created seperately, preferably
by someone who both knows and cares about the subjects of visual
design and human-computer interaction.
For example, if a setting is a number I just want to open that
number up for setting by the UI. My code shouldn't need to know
or care whether it is obtained by numeric entry, scroll bar, spin
box or whatever, nor on what dialog it appears and its precise
on-screen co-ordinates. That can be delegated to a visual designer
using a seperate interface design tool. I would just say "This
setting controls that", or "Execute this function to perform that
function". As far as possible, the structure of the code and the
UI would independent of each other, unlike many of the existing
interface design tools that implement each dialog as a class and
direct the programmer to structure the code in a particular manner.
Visual design is a complex area with its own conventions and
methodologies - IMHO this is complexity code can do without and is
best seperated out as far as pratical. As a side effect, creating
a new 'skin' for a different language or the latest new "improved"
user interface from Microsoft would result in minimal code changes.
--
Andrew Smallshaw
and...@sdf.lonestar.org
Paul Rubin
> I once dabbled with Tk, and I agree.
> However, I dimly remember that its layout model covers roughly 90% of
> cases, and that there was no good way to cover the remaining
> 10%. (IIRC the issue was that it cannot divide up a size increase over
> several controls.)
If you mean what I think you do, the solution is put a frame around them.
Alex
>
> I once dabbled with Tk, and I agree.
> However, I dimly remember that its layout model covers roughly 90% of
> cases, and that there was no good way to cover the remaining 10%. (IIRC
> the issue was that it cannot divide up a size increase over several
> controls.)
That used to be true years ago, when the only "geometry managers"
available were [place] and [pack].
But around version 8.x (don't remember the x), the new [grid] geometry
manager was added, which fills this gap.
You can even mix (I mean nest) the three of them, so that the coverage
today is fairly good.
> So while Tk is a good application of the KISS principle, it's not a
> complete solution.
None really is, but it made impressive progress towards the goal.
-Alex
Sacha
> On 2007-10-15, Didier Verna <did...@lrde.epita.fr> wrote:
> These are all "design" considerations - in the cosmetic, aesthetic
> sense of the term rather than a technical or engineering sense.
> code. I'd rather separate out the aesthetic elements from the code
> entirely, and be able to say in my code "this setting is alterable
> by the user" and have a UI that was created seperately, preferably
> by someone who both knows and cares about the subjects of visual
> design and human-computer interaction.
Many real life programs are not much more than a user interface. The
usual CRUD application. Or even big heavy applications like word or
excel or ... a web browser. In these programs, the "object model" is
mainly there to support the UI. Printing a document is a matter of UI,
wysiwyg is a matter of UI, then you have the UI to configure all this.
Also, more often than not, the deciding factor for the customer will be
the UI.
So yes, of course, it's good to have a separation between your code and
the UI. But the UI deserves all your attention. It is my opinion that
every programmer should research those matters. And instead of
relegating these to an UI "artist", he should work tightly with him to
achieve the best possible result.
Sacha
Ulf Wiger
>
> We call that the "waiting for the open source fairy" phenomenon. I
> just abuse the hell out of people who expect me to not only produce
> astonishing open source toolkits but then /document/ them, too.
I know all about it. I've spent lots of time contributing
to Open Source, with varying degrees of success. Some of
my contributions perhaps didn't get the following I thought
they deserved - others got more than they deserved IMO. In
neither case am I prepared to say anything derogatory about
those who did or did not decide to go along with my ideas.
In fact, I've been both astonished and grateful on the
occasions where people have taken my half-baked contributions
and made them into something much more than they originally
were. This is something that you can never demand that people
do for free.
> Me and Joe are out here breaking our nuts for you ungratefful,
> whining... oh, what's the use?
Indeed, and assuming that by "you", you are including me, I'd
suggest that you are jumping to conclusions. You most likely
haven't spent any time finding out about my track record in
industry and Open Source, and you probably know nothing of
my relationship to Joe. But by all means - bash away. I wrote
that I was unimpressed, but I'm not quite that easily
insulted.
>> Amazingly, the whole discussion played out without insults.
>
> Oh, c.l.l is much more fun than that. We have a kennel full of hounds
> to run down unsatisfactory posters, a glue factory for melting down
> the ones that don't get away from the hounds, black helicopters for
> those that do -- hey, make yourself useful, tell us the secret: how
> did you get rid of Harrop?
Why would we want to get rid of him? He's a productive and
knowledgeable member of the FPL community.
Now, if you don't mind, I'll spend some time trying ot answer
Jon's question, as it was both polite and well formulated.
BR,
Ulf W
Ulf Wiger
>
> That's very interesting. Could you explain exactly what it is about
> Joe's toolkit that makes it attractive from a programmer's point of
> view?
That's a good question, although you didn't mention if you
had looked at his paper. I will assume that you have. (:
The thing that is so nice is how it fits into the Erlang
programming model. Erlang is first and foremost a message-
passing language, and X is fundamentally all about message
passing. Joe described a nice way to use lightweight
processes in Erlang to map onto the basic X protocol.
As with many nice ideas in the Erlang community, Torbjörn
Törnqvist wrote the first ex11 prototype. Others helped
map all the X11 messages to nice-looking Erlang messages,
and Joe came up with a nice framework around, illustrating
how to write complex widgets on top of it.
All widgets must support a set of generic messages, but are
free to add their own. Each top-level widget has its own
context (its own process), which means that there is no
strange interleaving of events. If your own custom widget
needs to access the lowest-level X protocol, doing so is
unproblematic.
> Does it separate design from logic so that non-coders can work on
> the GUI alongside coders?
I think it follows, but Joe stopped short of clearly
demonstrating this.
Using "middle-man processes" is a common technique in
Erlang. Middle-man processes act as protocol translators,
and can filter out lots of unwanted noise, presenting
the user with just the messages needed for the task.
There were competing initiatives on the GUI front at
the time when ex11 was presented. Mats Cronqvist made
gtkNode (http://www.erlang.se/euc/05/1620cronqvist.pdf),
which uses code generation to generate an Erlang API
to GTK widgets. His approach achieved many of the
niceties of Joe's ex11, but at the same time made pretty
much all of GTK (and e.g. Glade) available to the user,
and as far as I can tell, the support needed since then
has been minimal for Mats.
Not surprisingly, this approach attracted more users. (:
> Also, would it take much work to write a back end in OCaml that targets
> something like Smoke's declarative vector graphics:
>
> http://www.ffconsultancy.com/products/smoke_vector_graphics/
>
> I think it would be great to bridge the current gap between GUI libraries
> for Linux and freeform rendering using OpenGL etc...
I have no answer to this, but perhaps the designers of
Wings3d (http://www.wings3d.com) would.
BR,
Ulf W
Raffael Cavallaro
> Ken Tilton wrote:
[snip]
>> tell us the secret: how
>> did you get rid of Harrop?
>
> Why would we want to get rid of him? He's a productive and
> knowledgeable member of the FPL community.
Because he is an obvious spammer - banned from Wikipedia for spamming
for example, and constantly spamming an irrelevant newsgroup, c.l.l
with adds for his services relating to languages which are *not lisp*.
Ulf Wiger
The fact that some people on c.l.l. have issues with Jon
has hardly escaped anyone reading c.l.f., but that's your
fight. I've been following c.l.f. for several years now,
and have recently started tracking the caml-list. Jon is
a visible member of both forums, but doesn't seem to have
any problem living up to the standards of either.
I have no quarrel with Jon, and people for whom I have the
highest regard have praised some of his work. That goes
a fair way in my book, and I cannot claim to understand
the cultures of c.l.l. and Wikipedia.
Besides, I have personally experienced being branded, both
unfairly (IMHO) and sometimes outright maliciously. At times
like that, I've been grateful for those who have trusted their
own experience of my work and character. Also for this reason,
I'm very much against maligning others in public.
BR,
Ulf W
Pascal Costanza
> You have this vaguer
> idea of computational adequacy which means that the GUIL can do the
> things you want. But the primitives are nowhere in sight
> and what you are given is a grab-bag of tools for making buttons and
> various widgets. Since the user's wish list is indefinitely large,
> GUILs become bloated and you end with 1000 page manuals of commands,
> hacks and hooks of every descripton. Reminiscent of PL/1 actually.
> So what you have is 'the wrong thing'.
>
> GUILs
> 1. A vague idea of computational adequacy.
> 2. A huge number of primitives.
> 3. A weak means of combining together.
>
> Now I sat down and wondered why that was.
I don't think the problem is that GUILs are inadequate, but rather that
GUIs are inadequate.
The situation we currently have is that computers and their UIs simulate
paper (cf. Alan Kay's "The Computer Revolution hasn't happened yet"). Or
even worse: They simulate things we know from everyday life (buttons,
sliders, etc.) without even remotely giving the same amount of
tangibility as the real stuff.
This is done by appealing to the ways of using things that we already
know from everyday life, but the resulting effect is that using a
computer is far too complicated, while there is no obvious way to get
real efficiency out of computers, from a user's perspective. We are
simply not taking advantage of what computers could do, and instead
focus too much on what computers are essentially bad at.
Before improving the languages to express GUIs, it's probably better to
first investigate how to improve UIs. Not that I have particularly good
ideas myself, of course... ;-)
And yes, I agree with Kenny that data-driven approaches based on, for
example, his Cells stuff, is likely the simplest way to go for
current-days GUIs. The advantage of Cells is that you remove not only
manual forwarding of data, but that you also remove effects to a large
degree and essentially get a functional programming style for expressing
GUIs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Thomas Lindgren
Ulf Wiger <ulf....@e-r-i-c-s-s-o-n.com> writes:
> The fact that some people on c.l.l. have issues with Jon
> has hardly escaped anyone reading c.l.f., but that's your
> fight. I've been following c.l.f. for several years now,
> and have recently started tracking the caml-list. Jon is
> a visible member of both forums, but doesn't seem to have
> any problem living up to the standards of either.
>
> I have no quarrel with Jon, and people for whom I have the
> highest regard have praised some of his work. That goes
> a fair way in my book, and I cannot claim to understand
> the cultures of c.l.l. and Wikipedia.
Well, Ulf, you _are_ crossposting into c.l.l at the moment. I'm afraid
my experience with that guy is far less positive. For example:
"If you want your code to work, choose static typing. If you're getting paid
in cash for lashing together porn sites, choose dynamic typing."
-- Jon Harrop, <13g5chf...@corp.supernews.com>
(http://groups.google.com/group/comp.lang.lisp/msg/4280255847a66414?dmode=source)
Plenty more of the same careful, even-handed, well-informed reasoning
where that came from, in thread after thread. So, a zealot and a
preacher, not a useful contributor. But, it should be said, one that
does at least love his ray tracer.
Best,
Thomas
--
Thomas Lindgren "It was all very mechanical -- but
that's the way planetside life is." -- RAW
Duane Rettig
> Raffael Cavallaro wrote:
>> On 2007-10-16 04:52:22 -0400, Ulf Wiger
>> <ulf....@e-r-i-c-s-s-o-n.com> said:
>>
>>> Ken Tilton wrote:
>> [snip]
>>>> tell us the secret: how
>>>> did you get rid of Harrop?
>>>
>>> Why would we want to get rid of him? He's a productive and
>>> knowledgeable member of the FPL community.
>> Because he is an obvious spammer - banned from Wikipedia for spamming
>> for example, and constantly spamming an irrelevant newsgroup, c.l.l
>> with adds for his services relating to languages which are *not
>> lisp*.
>
> The fact that some people on c.l.l. have issues with Jon
> has hardly escaped anyone reading c.l.f., but that's your
> fight.
It becomes your fight, too, when he cross-posts to c.l.l and c.l.f and
you have to see the fallout from the inappropriate (from our point of
view) posting.
I've been following c.l.f. for several years now,
> and have recently started tracking the caml-list. Jon is
> a visible member of both forums, but doesn't seem to have
> any problem living up to the standards of either.
That's fine, and he can post there to his heart's content with no
repercussions. When he posts to c.l.l, it is almost always
inappropriate.
> I have no quarrel with Jon, and people for whom I have the
> highest regard have praised some of his work. That goes
> a fair way in my book, and I cannot claim to understand
> the cultures of c.l.l. and Wikipedia.
I also have no knowledge of Wikipedia's censure, and it makes no
difference to us in c.l.l (except perhaps to demonstrate that the
abuse is not limited to some particular group of overly-sensitive
geeks). But is it so hard to understand that in comp.lang.lisp, we
prefer to talk about Lisp?
> Besides, I have personally experienced being branded, both
> unfairly (IMHO) and sometimes outright maliciously. At times
> like that, I've been grateful for those who have trusted their
> own experience of my work and character. Also for this reason,
> I'm very much against maligning others in public.
I don't much see him being maligned, from our point of view. We do
joke about his company's name in an attempt to cope with the fact that
we can't do anything about his unwelcome presence. And we do question
his honesty (or perhaps even downright deny it) for his presence in
our group, so that might be considered maligning, in the sense of
being negative. But if the negative talk is true, is it really
maligning?
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
John Thingstad
>
> Before improving the languages to express GUIs, it's probably better to
> first investigate how to improve UIs. Not that I have particularly good
> ideas myself, of course... ;-)
>
Have you looked at the work done for Windows Vista. Here the win32 library
gets replaced by WinFX. The interface can then be specified by a
specification language called XAML. This is usually designed by a designer
and requires little programming skills just knowledge of the design tools.
Interface elements can be made to look like anything you want. It can be
video's or it can be 3D design elements. One example I saw, a sportswear
store, had a 3D carousel on which a set of running video's were on the
surface. You then selected the video on the carousel for the type of item
you wanted. Say Slalom. From the programmers perspective it is just a
radio button. You could then select a item from the video say the ski's
and get a picture with the product specs and price..
These links might give you some idea.
http://msdn2.microsoft.com/en-us/library/ms752059.aspx
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031107winfxba/manifest.xml
Ulf Wiger
> Ulf Wiger <ulf....@e-r-i-c-s-s-o-n.com> writes:
>
>> The fact that some people on c.l.l. have issues with Jon
>> has hardly escaped anyone reading c.l.f., but that's your
>> fight. I've been following c.l.f. for several years now,
>> and have recently started tracking the caml-list. Jon is
>> a visible member of both forums, but doesn't seem to have
>> any problem living up to the standards of either.
>>
>> I have no quarrel with Jon, and people for whom I have the
>> highest regard have praised some of his work. That goes
>> a fair way in my book, and I cannot claim to understand
>> the cultures of c.l.l. and Wikipedia.
>
> Well, Ulf, you _are_ crossposting into c.l.l at the moment.
> I'm afraid my experience with that guy is far less
> positive. For example:
>
Fine, but I'm not interested in joining a crusade against
anyone. I've seen a number of quotes intended to prove
that Jon is a troll in c.l.l. I mentioned previously that
I don't read c.l.l. It could well be that it's perfectly
OK in that forum to bash and insult people at will, as
long as your post somehow pertains to Lisp - I don't
know. I'm not prepared to pass judgment on people based
on snippets from a forum that I'm not familiar with.
Anyway, apologies for letting myself get dragged into
the quarrel. I have no interest in it, nor the time.
I will bow out now.
BR,
Ulf W
Ken Tilton
Ulf Wiger wrote:
> Thomas Lindgren wrote:
>
>> Ulf Wiger <ulf....@e-r-i-c-s-s-o-n.com> writes:
>>
>>> The fact that some people on c.l.l. have issues with Jon
>>> has hardly escaped anyone reading c.l.f., but that's your
>>> fight. I've been following c.l.f. for several years now,
>>> and have recently started tracking the caml-list. Jon is
>>> a visible member of both forums, but doesn't seem to have
>>> any problem living up to the standards of either.
>>>
>>> I have no quarrel with Jon, and people for whom I have the
>>> highest regard have praised some of his work. That goes
>>> a fair way in my book, and I cannot claim to understand
>>> the cultures of c.l.l. and Wikipedia.
>>
>>
>> Well, Ulf, you _are_ crossposting into c.l.l at the moment.
>
> > I'm afraid my experience with that guy is far less
> > positive. For example:
>
>>
>> ...
>
>
> Fine, but I'm not interested in joining a crusade against
> anyone.
It's not a crusade against anyone when several members of a movie
theater audience tell someone using a cell phone to STFU.
> I've seen a number of quotes intended to prove
> that Jon is a troll in c.l.l. I mentioned previously that
> I don't read c.l.l.
OK, then maybe you should STFU if you are too lazy to research the
phenomenon for which you have elected yourself ethical monitor.
> It could well be that it's perfectly
> OK in that forum to bash and insult people at will, as
> long as your post somehow pertains to Lisp - I don't
> know.
Nonsense. It does not have to pertain to Lisp.
> I'm not prepared to pass judgment on people based
> on snippets from a forum that I'm not familiar with.
STFAbove.
>
> Anyway, apologies for letting myself get dragged into
> the quarrel. I have no interest in it, nor the time.
> I will bow out now.
Could you /pleeeassseeee/ take Jon with you since you think he is so
wonderful? The problem is that he has no chance of getting hits by
tediously spamming c.l.f, and besides, YDSWYE. c.l.f is a boring empty
niche for the few people who do not understand that functional is a
great paradigm and should be used 95% of the time for all the benefits
we all understand but made the incredibly common mistake of thinking,
Hey! Let's use it for everything! and made entire languages work only
that way except where they realized oh that's silly that won't work and
created monads.
If you don't know what I am talking about, click on that algebra URL in
my sig, my hits are down. <sigh>
E.D.S.
simplified theory, which can be clearly understood by everyone and then
later refined into a more complete theory.
When the user clicks a button, things happen at different levels of
abstraction. The user presses the mouse button, then releases it, at a
low hardware level of abstraction. The user clicks a point on the
screen, at a somewhat higher level of abstraction. That point on the
screen is in a button widget, and the user is clicking that button
widget, at a still higher level of abstraction. At an even higher level
of abstraction than that, the user is making a selection from a group of
buttons. The program, abstracted above the level of the GUI, wants
information from the user, and the user is providing that information.
Each of those layers of abstraction is naturally very complicated,
because a lot of things can happen at any point in time in each layer,
and all of those things have to be taken into account by the software.
The programmer needs widgets because the lower layers of abstraction
below widgets are naturally too messy and tedious. But the programmer
actually needs something at a higher level of abstraction than widgets,
because widgets themselves are too messy and tedious.
None of the toolkits are complete. They're all compromised by the need
for simplicity. Like having a hammer, because it's simple, and makes
every problem a nail.
The bigger your toolkit, the heavier it is, but the more problems you can
solve better. Tools are expensive. People use compromised toolkits,
because they can't afford better ones and they can't afford to deal with
the weight and size of a big toolkit.
But software is different than metal tools. The only things that stop us
from using a twenty ton toolkit are the problem of obtaining the tools
and the problem of keeping each tool handy and not letting it get lost
among the other tools. The problem of the twenty ton weight is easily
solved by modern multi-gigabyte disk storage, which was not easily
available to the original designers of GUI libraries that have been
evolving for decades.
So, what we really need is a way to get a complete set of tools, and a
way to keep each tool handy. Getting a complete set of tools is hard,
especially if we have to design each tool manually. But the OP wants to
use combination to create an orthogonal set of tools from a smaller set
of more primitive tools. If we can do that, it will also help us keep
the tools handy.
Therefore, this discussion should not be construed as an argument about
whether GUILs are inadequate, but, rather, a discussion about the OP's
proposal for solving that inadequacy. A discussion about how to use
combination of primitives to fill in the whole orthogonal set of all
potentially desirable GUI tools. Because we're using combination, we
don't have to name each tool, nor even be aware of each tool. We can
think in terms of the combinations. A push button that toggles and stays
pushed till you push it again to release it, is just another style of
push button. Just a different combination. You don't have to remember
the name of that style vs the original push button. You just have to
remember the combination of features you want it to have. A Mickey Mouse
push button, where he sits down when you push the button, is still
another style. There can be an unlimited number of combinations. Make
the button triangular and make it take half the screen. Just another
combination.
So the issue really is how to build this stuff and make it handy. How to
make it easy for the programmer to tell Mickey to sit down when the
button is pressed, without the need to make such actions part of the
program logic, but just the GUI style combinations.
The programmer needs to be able to add more stuff to be combined in the
combinations. Maybe nobody ever thought to include Mickey Mouse
capability. But that's just another combination of other capabilities.
A different combination could have someone else sitting down, or doing
something else. The programmer needs to be able to easily add whatever
is missing, to be used in whatever combinations are desired.
Keeping a group of buttons lined up is just a matter of making them a
group, which is another kind of widget, and giving that group the right
combination, such as being able to adapt to different layout spaces
without getting distorted.
To restate the theory, GUI's are naturally complicated, not just because
we're doing them wrong. They're complicated because so many different
things can happen in so many different ways. But software is good at
conquering complexity.
Most existing GUILs are compromised for expediency. What we need is
simply one that isn't. One that provides for unlimited combinations,
with unlimited access at all levels for the programmer to easily add
anything missing, without spending any time fighting needless obstacles
such as built in quirks and restrictions on what can be easily added or
combined.
Jon Harrop
> ...banned from Wikipedia for spamming...
Misinformation.
I think what you mean is that a crusade of Lispers tried and failed to get
me banned from Wikipedia. Apparently, they also tried and failed to get me
banned from c.l.lisp by approaching my ISP. They have now retreated into
posting fake reviews of my work. They are easily spotted though, being the
only negative reviews...
> ...adds for his services relating to languages which are *not lisp*.
If someone like "are" posts on c.l.lisp with a subject "Lisp and OCaml" only
to be overrun with misinformation about OCaml from the Lisp community, what
is wrong with me pointing out the faults in their arguing and flaws in
their favourite language that were fixed in ML/Haskell?
From your line of arguing here, for example, it sounds like you would rather
hear an opinion from someone who hadn't written the book on the subject...
Jon Harrop
> So yes, of course, it's good to have a separation between your code and
> the UI. But the UI deserves all your attention. It is my opinion that
> every programmer should research those matters. And instead of
> relegating these to an UI "artist", he should work tightly with him to
> achieve the best possible result.
I agree that programmers should be made far more aware of the artistic side
of GUIs.
However, if you consider the dress-sense of your average programmer would
you really want them having a hand in any customer-facing aspect of your
work, e.g. the GUI?
Look at John McCarthy, for example:
http://www.bartnagel.com/images/John_McCarthy.jpg
Thomas Lindgren
Ulf Wiger <ulf....@e-r-i-c-s-s-o-n.com> writes:
> It could well be that it's perfectly OK in that forum to bash and
> insult people at will, as long as your post somehow pertains to Lisp
> - I don't know.
C.l.l. has a long history of people coming over to say nasty things
about Lisp and related topics (sometimes over and over), and has
admittedly developed a culture of answering back in kind. But I
wouldn't say it's thereby welcomed.
j.oke
> [some mixed letters A-Z, a-z]
Half lost on my firmness gains to more glad heart,
Or violent and from forage drives
A glimmering of all sun new begun
Both harp thy discourse they march'd,
Forth my early, is not without delay;
For their soft with whirlwind; and balm.
Undoubtedly he scornful turn'd round ninefold,
Though doubled now what redounds,
And chains these a lower world devote, yet inflicted?
Till body or rare, and best things else enjoy'd in heav'n
To stand divided light at ev'n and poise their eyes,
Or nourish, lik'ning spiritual, I have thou appear.
-Henley
Damien Kick
> Raffael Cavallaro wrote:
>> On 2007-10-16 04:52:22 -0400, Ulf Wiger
>> <ulf....@e-r-i-c-s-s-o-n.com> said:
>>
>>> Ken Tilton wrote:
>> [snip]
>>>> tell us the secret: how did you get rid of Harrop?
>>>
>>> Why would we want to get rid of him? He's a productive and
>>> knowledgeable member of the FPL community.
>>
>> Because he is an obvious spammer - banned from Wikipedia for spamming
>> for example, and constantly spamming an irrelevant newsgroup, c.l.l
>> with adds for his services relating to languages which are *not
>> lisp*.
>
> The fact that some people on c.l.l. have issues with Jon
> has hardly escaped anyone reading c.l.f., but that's your
> fight.
You know, that's another reason for me not to like you. That rumhead
spent twenty years in jail for poisoning a kid. If you know him, you
must be a jailbird yourself. Would you show these gentlemen to the door?
> I've been following c.l.f. for several years now,
> and have recently started tracking the caml-list. Jon is
> a visible member of both forums, but doesn't seem to have
> any problem living up to the standards of either.
Of course, it isn't too surprising that DDT would have no problems
living up to the standards of a forum like caml-list as writing about
OCaml on caml-list would seem to be <pause> rather /on/ topic.
> [...] and I cannot claim to understand the cultures of c.l.l. and
> Wikipedia.
Fair enough. But then why the apologetic on c.l.l? You seem happy with
FPL and FPL seems quite happy with DDT. You can keep him. Please.
Hey! Get me! I'm giving out wings!