Still trying to settle on the best approach to developing an alternative
to CLIM, thought I'd get some CL community input (sort of get the arrows
in the chest instead of the back)....
I've implemented a Garnet-like GUI twice, once under MCL/Mac, once under
ACL/Win32. Now the Mac OS way back when did not see buttons as windows.
The window was a window, the button was a control which was not a
window. Win32 like X sees buttons as windows, each for example with
their own event stream.
Midway thru development of the ACL/Win32 version, in the hope of
leveraging groovy widgets like tab controls I spent a month getting my
garnet-like scheme to cope with the X model, to give that a name, but of
course it was win32 I was wrestling with. Got it to work, hated it. So I
pulled the plug and just reinvented widgets as needed, which was vastly
easier AFAIWC than dealing with the X model.
So I am tempted to go with the mac model in which a window is a window
is not a button. But if there is something insanely great about the X
model I would reconsider. Something perhaps to do with efficient
client-server performance?
kenny
clinisys
Rajappa Iyer wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > I've implemented a Garnet-like GUI twice, once under MCL/Mac, once under
> > ACL/Win32. Now the Mac OS way back when did not see buttons as windows.
> > The window was a window, the button was a control which was not a
> > window. Win32 like X sees buttons as windows, each for example with
> > their own event stream.
>
> I'm trying to educate myself here, so don't take the questions as
> challenges. What is the advantage of the MacOS way?
Well first of all, I have been doing some pretty hairy stuff with my
GUI. Imagine a graceful way to do long division at the keyboard (for an
educational app). Lots of tiny little widgets in a complex tree
structure aligning with each other according to all sorts of rules (not
just :sticky-left etc). Crucially, these guys move around, change size,
and do so in ways that affect ech other's size and position. So to make
each widget a window with each their own update event...well, I got
pretty far with some easier stuff but hated myself afterwards. :) There
had been no "win" and much armtwisting. A single bitmap/window/event
stream (the Mac Way) allowed me to create my own rich world with full
control over it, which I think is what you are getting at here:
> is it
> not possible to create a `composite' widget such that the application
> doesn't see a separate event stream?
Yes, that is my plan, and that is what I did under win32. The real
window is a win32 window, everything below that (except dialogs and
menus) is just my emulation of mac controls. (Aside: on the Mac I
wrapped true Mac controls such as buttons and scroll bars, in win32 I
rolled my own.)
> CLIM provides a very nice
> interface to the windowing substrate that can be easily programmed to
> make composite widgets of your own that can hide or expose as much of
> the component widgets as you like.
Right, that is how I want to go, I am just concerned that y'all will
look at the way I turned my back on all-windows-all-the-time and run me
out of Cliki on a rail.
OTOH, it occurs to me that the more we rely on X or GTK or GDK or
anything for window management the less portable a solution we have. Or
maybe I mean the less Lispy a solution we have. Sure a GTK solution is
portable since GTK is implemented lotsa places...I guess I am thinking
in the spirit of the Lisp OS and the adavntages that accrue from a
solution being Lisp All the Way Down.
Maybe what I am proposing is an abstract CL windowing system relying on
What's Underneath only for a bit-mapped window and an event stream to
guide her by.
I looked at CLIM very briefly under MCL (when it was just a contrib) and
I was not impressed. And if all I am going to do is ask for a window and
an event stream, then it occurs to me I can begin with my existing
win32-based stuff to quickly see if anyone cares. a port to any given
window manager substrate should then be cake because of the slight use I
make of it.
One consideration here is that I already have a day job, and as someone
else said this is the kind of project that often peters out. it's
probably better for me to share what I have and see if anyone salutes,
if so tap the energy of others in a collaborative open source effort.
want to do the CLIM port? :)
kt
From: Brian P Templeton
Subject: Re: Best approach for CL GUI?
Date:
Message-ID: <87hermctyh.fsf@tunes.org>
Kenny Tilton <·······@nyc.rr.com> writes:
[...]
> OTOH, it occurs to me that the more we rely on X or GTK or GDK or
> anything for window management the less portable a solution we have. Or
> maybe I mean the less Lispy a solution we have. Sure a GTK solution is
> portable since GTK is implemented lotsa places...I guess I am thinking
> in the spirit of the Lisp OS and the adavntages that accrue from a
> solution being Lisp All the Way Down.
>
Remember that X11 is somewhat portable system (at least, the most
portable windowing system now available) which runs on many different
OSes, including Unices (GNU/Linux, the HURD, *BSD, Slowlaris, etc),
MacOS, VMS, MS-Windows, etc. And unlike GTK+, X11 doesn't rely on C or
any other specific language.
As for Lisp OSes...
(advocacy (format nil "If you want a Lisp OS and a ``Lisp All the Way Down'' solution, help~%
design and implement TUNES!~%
<URL:http://www.tunes.org/>"))
[...]
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton:
BT> Remember that X11 is somewhat portable system [...] which runs on
BT> many different OSes, including Unices (GNU/Linux, the HURD, *BSD,
BT> Slowlaris, etc), MacOS, VMS, MS-Windows,...
... Lisp Machines and OS-less embedded hardware.
Juliusz
P.S. I recall Keith Packard telling me how annoying the Symbolics people
were, asking that he should stop implicitly casting 0 to NULL all
over the place.
Nothing like the people who run Purify over the server, though,
and complain when you send unitialised fields over the wire
(commonly done when a given field is not pertinent to the
generated event).
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> P.S. I recall Keith Packard telling me how annoying the Symbolics
> people were, asking that he should stop implicitly casting 0 to NULL
> all over the place.
Why? 0 in a pointer context _is_ NULL.
--
In article <··············@europe.nortel.com>, "Robert Pluim"
<······@bigfoot.com> wrote:
> Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>> P.S. I recall Keith Packard telling me how annoying the Symbolics
>> people were, asking that he should stop implicitly casting 0 to NULL
>> all over the place.
> Why? 0 in a pointer context _is_ NULL.
Yes, but, in pre-ANSI C pointer context was a lot less clear, given that
there weren't function prototypes. I presume the Symbolics folks were
trying to get the reference X server code to run on the Symbolics Lisp machine,
and I understand that in Symbolics C NULL was Lisp NIL, not the integer 0.
Tim
"Tim Moore" <·····@bricoworks.com> writes:
> In article <··············@europe.nortel.com>, "Robert Pluim"
> <······@bigfoot.com> wrote:
>
>
> > Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> >> P.S. I recall Keith Packard telling me how annoying the Symbolics
> >> people were, asking that he should stop implicitly casting 0 to NULL
> >> all over the place.
> > Why? 0 in a pointer context _is_ NULL.
> Yes, but, in pre-ANSI C pointer context was a lot less clear, given
> that there weren't function prototypes. I presume the Symbolics
> folks were trying to get the reference X server code to run on the
> Symbolics Lisp machine, and I understand that in Symbolics C NULL
> was Lisp NIL, not the integer 0.
Then they were complaining about conversion from NULL to integer 0,
which I can understand. Oh well, I'll file that away under
"historical" ;-)
--
In article <··············@europe.nortel.com>, Robert Pluim wrote:
>Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>
>> P.S. I recall Keith Packard telling me how annoying the Symbolics
>> people were, asking that he should stop implicitly casting 0 to NULL
>> all over the place.
>
>Why? 0 in a pointer context _is_ NULL.
In some situations in the C language, there is no clear context. Such
as the argument expression for the trailing argument of a variadic function,
or an argument to a function that was declared using the old-style.
It's easy to forget and write something like, say:
printf("%p\n", NULL);
printf("%p\n", 0);
rather than
printf("%p\n", (void *) NULL);
printf("%p\n", (void *) 0);
Defining NULL as ((void *) 0) helps, but obviously if the programmer
just uses 0, NULL is for naught. ;) And that solution is not available
in C++, where (void *) 0 is not a null pointer constant, but a null
pointer value of type void *. Some C++ implementors define NULL in
strange ways like 0L, knowing that the wider zero will behave just like
a null pointer in argument passing. You see that on platforms where,
for instance, pointers are 64 bits wide, but ints are 32.
Ah, things broken by design.
"Robert Pluim" <······@bigfoot.com> wrote in message
···················@europe.nortel.com...
> Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>
> > P.S. I recall Keith Packard telling me how annoying the Symbolics
> > people were, asking that he should stop implicitly casting 0 to NULL
> > all over the place.
>
> Why? 0 in a pointer context _is_ NULL.
Not necessarily. One can easily envision memory schemes in which
address ranges are reserved for different uses, such that address 0
is something completely different from a null pointer.
"Zero" has nothing to do with "null" whatsoever.
"Scott McKay" <···@mediaone.net> writes:
> "Robert Pluim" <······@bigfoot.com> wrote in message
> ···················@europe.nortel.com...
>
> > Why? 0 in a pointer context _is_ NULL.
>
> Not necessarily. One can easily envision memory schemes in which
> address ranges are reserved for different uses, such that address 0
> is something completely different from a null pointer.
[This has become completely off-topic for c.l.l but I'll make one last
response]
Note that I didn't say "address 0", I said "0 in a pointer context".
I'm (unfortunately) well aware of the difference.
> "Zero" has nothing to do with "null" whatsoever.
So you claim that:
int * x = 0;
does not initialize x to the NULL pointer in standard C?
Robert
(we can discuss this further in email if you wish).
--
Kenny Tilton <·······@nyc.rr.com> writes:
> So I am tempted to go with the mac model in which a window is a window
> is not a button.
See below.
> But if there is something insanely great about the X model I would
> reconsider. Something perhaps to do with efficient client-server
> performance?
Comments below are about X.
That's right. One of the best things in widgets having their own
window is that each window has its own event-mask, so only the events
that a widget is interested in are reported to the application. This
can save a lot of event processing, especially compared to what you
call "mac model". (You might also consider using input-only windows in
your "mac model" to save on event processing.)
According to CLX documentation about the design goals of X, one is:
Cheap Windows
Windows should be abundant, and ubiquitous. Provide overlapping
windows and a simple mechanism for window hierarchy.
So I don't see why would you refuse to use the services provided. And
I'm quite sure the X server's event processing code is better
optimized and integrated than what you will write on your own (beside
the fact that all events you receive have already gone through the
event-processing in X server).
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
Thx for the input.
Janis Dzerins wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > But if there is something insanely great about the X model I would
> > reconsider. Something perhaps to do with efficient client-server
> > performance?
>
...
>
> So I don't see why would you refuse to use the services provided.
Well, I had a bad experience doing extremely dynamic gui stuff under the
X model, forget the details. Stuff that was effortless in a one-window
model was nasty under X. But it was a short experiment so I would give
it another look if the world has settled on the X model.
I probably should have said up front that in part I felt I was asking
"has the X model taken over the world?" If it has then I do not lose any
generality by building an X/win32 assumption into a CL GUI.
Even so in terms of portability, I like the idea of "Lisp all the way
down" (to the bitmapped window and event stream).
Perhaps the way to go is to go with the X model most of the time but for
tricky stuff like a long division problem take a single window/event
stream and go nuts within that. Best of both worlds and all that.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Well, I had a bad experience doing extremely dynamic gui stuff under
> the X model, forget the details. Stuff that was effortless in a
> one-window model was nasty under X.
The best thing to do I guess would be to update your experiences
(i.e. try to remember the details and come here to check whether you
are not missing something).
> But it was a short experiment so I would give it another look if the
> world has settled on the X model.
See my signature about "the world having settled on something".
> I probably should have said up front that in part I felt I was
> asking "has the X model taken over the world?" If it has then I do
> not lose any generality by building an X/win32 assumption into a CL
> GUI.
I think you should forget about something having taken over the world
and do the right thing instead, and try to not lose any generality by
not building any specific assumptions about low level stuff all over
the place. This of course is harder to do but what's the joy in doing
only the easy stuff? :)
> Even so in terms of portability, I like the idea of "Lisp all the way
> down" (to the bitmapped window and event stream).
What's wrong with "Lisp all the way down" (to the X protocol stream)?
> Perhaps the way to go is to go with the X model most of the time but
> for tricky stuff like a long division problem take a single
> window/event stream and go nuts within that. Best of both worlds and
> all that.
Do you mean you run a function that takes long time to finish and the
application doesn't respond to user interaction meantime?
In this case I don't see how X is different from anything else. If you
have multithreading (even not the native OS threads) it's easy to
process events in another process or processes (connection to X is
just a stream -- you can have an event processing process to receive
events and dispatch them whatever way you want: process them
immediately or put in event queue, which you may have many (say one
per top-level-window)).
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
Janis Dzerins wrote:
>
> I think you should forget about something having taken over the world
> and do the right thing instead, and try to not lose any generality by
> not building any specific assumptions about low level stuff all over
> the place. This of course is harder to do but what's the joy in doing
> only the easy stuff? :)
My stuff gets a lot out of a few core classes thanks to the Garnet-like
rules you can stick on any given attribute. So it's light on the
assumptions but still powerful, a nice mix.
>
> > Even so in terms of portability, I like the idea of "Lisp all the way
> > down" (to the bitmapped window and event stream).
>
> What's wrong with "Lisp all the way down" (to the X protocol stream)?
I've been reading up on CLIM. I see they purposely built it in layers so
roll-your-own projects can jump in at diff levels. How does "my
Garnet-like (lisp) stuff all the way down to CLIM (still Lisp)" sound?
kenny
clinisys
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
>
> I've been reading up on CLIM. I see they purposely built it in layers so
> roll-your-own projects can jump in at diff levels. How does "my
> Garnet-like (lisp) stuff all the way down to CLIM (still Lisp)" sound?
>
It sounds right to me. That's certainly CLIM's intent, although the spec
isn't quite as good as it could be, and the implementations don't implement
the spec perfectly...
Scott McKay wrote:
>
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ······················@nyc.rr.com...
> >
> > I've been reading up on CLIM. I see they purposely built it in layers so
> > roll-your-own projects can jump in at diff levels. How does "my
> > Garnet-like (lisp) stuff all the way down to CLIM (still Lisp)" sound?
> >
>
> It sounds right to me. That's certainly CLIM's intent, although the spec
> isn't quite as good as it could be,
uh-oh :)
> and the implementations don't implement
> the spec perfectly...
uh-oh :)
Sounds like this is what the CL community should do first to improve
acceptance: standardize the GUI at least at some lower level abstracted
from the host OS. As it is, LW has CAPI, ACL has CG, MCL has their own
thing wrapping the MacOS. CLIM is there but not being treated seriously
as a standard?
kenny
clinisys
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> writes:
>
>
> Scott McKay wrote:
>>
>> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
>> ······················@nyc.rr.com...
>> It sounds right to me. That's certainly CLIM's intent, although the spec
>> isn't quite as good as it could be,
>
> uh-oh :)
Given that it's ~400 pages long, it's not that bad. There are a few places
where there are conflicts and a few more spots that could be explained
clearer.
>> and the implementations don't implement
>> the spec perfectly...
>
> uh-oh :)
Since all the commercial CLIMs (AFAIK) come from the same sources, it's not
that big a problem.
> Sounds like this is what the CL community should do first to improve
> acceptance: standardize the GUI at least at some lower level abstracted
> from the host OS. As it is, LW has CAPI, ACL has CG, MCL has their own
> thing wrapping the MacOS. CLIM is there but not being treated seriously
> as a standard?
CLIM is the only hope you really have in writing a portable GUI using CL.
(Short of making your own LCD library.) As for it not being treated seriously
as a standard by the vendors, it's pretty much in the same boat as sockets,
defsystem, FFI. Since these are not specified in the ANSI standard, the
vendors look at them as places to differeniate themselves. Some would say this
is to add value while others would say it's so they can lock you into their
proprietary extensions.
Mike McDonald
·······@mikemac.com
Mike McDonald wrote:
>
> CLIM is the only hope you really have in writing a portable GUI using CL.
> (Short of making your own LCD library.) As for it not being treated seriously
> as a standard by the vendors, it's pretty much in the same boat as sockets,
> defsystem, FFI. Since these are not specified in the ANSI standard, the
> vendors look at them as places to differeniate themselves.
Gotcha. Do you have any sense of which commercial CLIM is closest to
McCLIM differentiation-wise? I know that's hard to put a metric on, but
any anecdotals on ports to/from McCLIM?
kenny
clinisys
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> writes:
>
>
> Mike McDonald wrote:
>>
>> CLIM is the only hope you really have in writing a portable GUI using CL.
>> (Short of making your own LCD library.) As for it not being treated seriously
>> as a standard by the vendors, it's pretty much in the same boat as sockets,
>> defsystem, FFI. Since these are not specified in the ANSI standard, the
>> vendors look at them as places to differeniate themselves.
>
> Gotcha. Do you have any sense of which commercial CLIM is closest to
> McCLIM differentiation-wise? I know that's hard to put a metric on, but
> any anecdotals on ports to/from McCLIM?
Well, since McCLIM is a work in progress (ie, NOT done!), we really haven't
heard of anyone's experience in using McCLIM instead of a vendor's version.
We're trying to implement what the spec says. When the spec isn't clear, we
look at what the commercial implemenation does.
Mike McDonald
·······@mikemac.com
> > Mike McDonald wrote:
> Well, since McCLIM is a work in progress (ie, NOT done!), we really haven't
> heard of anyone's experience in using McCLIM instead of a vendor's version.
> We're trying to implement what the spec says. When the spec isn't clear, we
> look at what the commercial implemenation does.
ok.
1. are you doing McCLIM because:
(a) CLIM is insanely great (ie, you dig it on its merits regardless of
portability)
(b) CLIM is the only portable CL gui game in town
(c) Other______________________________
2. howseabout performance? do the layers of CLIM introduce a performance
hit? this is probably highly implementation-dependent...anyway, anything
you have on this topic will be helpful.
meanwhile i'll go read some more CLIM doc. thx for the input everyone.
kenny
clinisys
On Thu, 15 Nov 2001 22:36:37 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> 2. howseabout performance? do the layers of CLIM introduce a performance
> hit? this is probably highly implementation-dependent...anyway, anything
> you have on this topic will be helpful.
I can't tell you about CLIM performance in general, but I have some
anecdotal evidence on McCLIM.
When I first tried McCLIM[*] with CLISP and CMU CL under Linux on my oooold
Pentium 200 box with 64 MB of RAM, it was really slow. It was so slow that
I wondered whether I would ever have been able to use McCLIM without a
hardware upgrade.
Performance greatly improved over the past few months. Now performance on
the same hardware mentioned above is acceptable even with CLISP, it's no
longer an issue. Now I can move on to writing some code for learning CLIM.
The latest CVS commit logs have mentioned more performance improvements,
but I haven't tried them yet. Kudos to the McCLIM team.
Paolo
[*] Probably shortly after Robert Strandh and his students started working
on it.
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>> > Mike McDonald wrote:
>> Well, since McCLIM is a work in progress (ie, NOT done!), we really haven't
>> heard of anyone's experience in using McCLIM instead of a vendor's version.
>> We're trying to implement what the spec says. When the spec isn't clear, we
>> look at what the commercial implemenation does.
>
> ok.
>
> 1. are you doing McCLIM because:
>
> (a) CLIM is insanely great (ie, you dig it on its merits regardless of
> portability)
I really like the idea of presentation types. I've found that most people
don't understand the beauty of the idea since they have no way of experiencing
them. So I want to fix that.
> (b) CLIM is the only portable CL gui game in town
CLIM is suppose to be a portable GUI but most of the vendors seem to do
everything they can to discourage people from using it. I would rather have
spent my time improving the existing implementation than creating one from
scratch but the licensing/ownership issues with the commercial version appear
to be unsolvable. (The original implementaton is copyrighted by sixdifferent
firms. Half of those have gone thru multiple buyouts/bankruptcies. Determining
who has what rights to the source is a nigthmare.) Writing a "free" version
from scratch seemed to be the only answer.
> 2. howseabout performance? do the layers of CLIM introduce a performance
> hit? this is probably highly implementation-dependent...anyway, anything
> you have on this topic will be helpful.
Of course there's some performance penalty for layering CLIM but it's pretty
acceptable to me. Our first priority has been to get CLIM implemented
correctly and then worry about speed. With the recent redisplay improvements,
it's gotten a lot better. I do all my McCLIM work on my 233MHz laptop so we're
not requiring a multi GHz machine.
Mike McDonald
·······@mikemac.com
I really like the idea of presentation types as well.
How do you implement them though?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> I really like the idea of presentation types as well.
>
> How do you implement them though?
>
> Cheers
>
Guess which part of CLIM hasn't been implemented yet? :-)
Input gestures and pointers are on my list for hacking this weekend. Then
presentation types and input editing.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In article <···············@octagon.mrl.nyu.edu>,
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > I really like the idea of presentation types as well.
> >
> > How do you implement them though?
> >
> > Cheers
> >
>
> Guess which part of CLIM hasn't been implemented yet? :-)
>
> Input gestures and pointers are on my list for hacking this weekend. Then
> presentation types and input editing.
Somehow I am not surprised. I remember somebody making the comment
that PRESENTATION TYPES are not (easily) implementable on top of ANSI
CL.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> ·······@mikemac.com (Mike McDonald) writes:
>
> > Guess which part of CLIM hasn't been implemented yet? :-)
> >
>
> Somehow I am not surprised. I remember somebody making the comment
> that PRESENTATION TYPES are not (easily) implementable on top of ANSI
> CL.
It was a royal pain doing this. We added explicit support to Dylan's
dispatch model to support presentation types ('subclass' dispatch).
Kenny Tilton <·······@nyc.rr.com> writes:
> 1. are you doing McCLIM because:
>
> (a) CLIM is insanely great (ie, you dig it on its merits regardless of
> portability)
>
> (b) CLIM is the only portable CL gui game in town
>
> (c) Other______________________________
I can tell you why I am participating.
First, I needed a GUI for the Gsharp score editor. CLIM has an open
specification, so it seemed appropriate.
Second, I wanted to propose a GUI library for my students to make my
courses based on CL more credible.
Third, writing a free version of CLIM seemed like a great CLOS
exercise for me.
Fourth, it allowed me to propose a number of interesting student
projects.
> 2. howseabout performance? do the layers of CLIM introduce a performance
> hit? this is probably highly implementation-dependent...anyway, anything
> you have on this topic will be helpful.
I agree with Mike that this is not a problem. The CLIM specification
contains provisions for high performance, such as caching of
transformations and compiler macros for simple graphics operations.
Whether the current McCLIM performance is good enough is another
thing. I personally think so, especially now that Mike added
incremental scrolling. But we are working to make it even better. It
is just that our main priority is getting it to work at all.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Thx for the detailed input. From what I hear Good Things are coming out
your your students' efforts. I am still on a fence as to what to do.
What is your platform? intel/linux/cmucl/mcclim? I found your little web
page mentioning Guile, did not see a CL mention.
I made a weak effort to get Debian installed, gave up when it would not
recognize my mouse, did not recognize my graphics card and asked me what
phone number to dial from my cable modem. :) I could try again I
suppose.
I have been having great fun with my dataflow hack, and it seems to me
there is a lot of uncharted potential. I have always thought it would be
great for student projects, research, etc.
kenny
clinisys
Robert Strandh wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > 1. are you doing McCLIM because:
> >
> > (a) CLIM is insanely great (ie, you dig it on its merits regardless of
> > portability)
> >
> > (b) CLIM is the only portable CL gui game in town
> >
> > (c) Other______________________________
>
> I can tell you why I am participating.
>
> First, I needed a GUI for the Gsharp score editor. CLIM has an open
> specification, so it seemed appropriate.
>
> Second, I wanted to propose a GUI library for my students to make my
> courses based on CL more credible.
>
> Third, writing a free version of CLIM seemed like a great CLOS
> exercise for me.
>
> Fourth, it allowed me to propose a number of interesting student
> projects.
>
> > 2. howseabout performance? do the layers of CLIM introduce a performance
> > hit? this is probably highly implementation-dependent...anyway, anything
> > you have on this topic will be helpful.
>
> I agree with Mike that this is not a problem. The CLIM specification
> contains provisions for high performance, such as caching of
> transformations and compiler macros for simple graphics operations.
>
> Whether the current McCLIM performance is good enough is another
> thing. I personally think so, especially now that Mike added
> incremental scrolling. But we are working to make it even better. It
> is just that our main priority is getting it to work at all.
> --
> Robert Strandh
>
> ---------------------------------------------------------------------
> Greenspun's Tenth Rule of Programming: any sufficiently complicated C
> or Fortran program contains an ad hoc informally-specified bug-ridden
> slow implementation of half of Common Lisp.
> ---------------------------------------------------------------------
Kenny Tilton <·······@nyc.rr.com> writes:
> What is your platform? intel/linux/cmucl/mcclim? I found your little web
> page mentioning Guile, did not see a CL mention.
We used to use Guile for Gsharp (I haven't updated the pages). Then
it became clear to me that Guile would probably never be the platform
that I had hoped it would.
We now use exactly what you guessed:
Intel PC + GNU/Linux + CMUCL + McCLIM.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Kenny Tilton:
KT> Win32 like X sees buttons as windows, each for example with their
KT> own event stream.
I know nothing about Win 32, but I would not quite agree with your
description of X. An X client receives a composite stream of all the
events it has selected for, whichever window they come from. You are
free to ignore the window field of the events you receive.
In short: the main role of windows is to allow you to express an
interest for different events on a real-estate basis. A secondary
role of windows is to provide cursor shapes and backgrounds to pieces
of real-estate, thus allowing your application to provide some
near-instantaneous user feedback even if it is swapped out or busy
collecting garbage (or dumping core, if you're a C++ programmer).
KT> But if there is something insanely great about the X model I would
KT> reconsider.
Note that the abstractions provided by X support four different
models. I'd rather call what you've described the ``Xt/Motif'' model,
and there is no reason why you should follow it. (Insert quotation
about X11 providing mechanism not policy, which is why no two X11
applications behave the same.) More below.
KT> Something perhaps to do with efficient client-server performance?
Yes. Basically, the goal is to avoid sending down the wire events
that you are not interested in. There is only one likely case where
the event stream can be the bottleneck: when selecting for motion
events. (Note that some servers will send more motion events than
others. XFree86 4.0 and later will send way more motion events than
3.3 when the server is busy, and the deployment of 4.0 did require
fixing quite a few clients that assumed the behaviour of 3.3.)
A minor point is that you can specify a different cursor for every
window, thus making cursor changes over sensitive areas much more
responsive (e.g. if the client is swapped out). Furthermore,
ReadWrite windows can specify a background, thus making the outline of
your UI appear instantaneously (again, important if the client is
swapped out).
In a Motif-style UI, windows are used for two different purposes:
event distribution and clipping. X11 does not require you to couple
the two, and provides you with:
- GC clipping areas, which perform clipping only;
- ReadOnly windows, which perform event distribution only;
- ReadWrite windows, which perform both clipping and event
distribution.
Thus, you should feel free to use one of the following four models, or
any blend of the four:
(1) use a single toplevel ReadWrite window, and do all clipping and
event distribution client-side (the NeXT model);
(2) use a single toplevel ReadWrite window, and a bunch of GCs with
different clipping areas, thus doing clipping server-side and
event distribution client-side;
(3) use a single toplevel ReadWrite window, and a bunch of ReadOnly
windows: event distribition server-side and clipping client-side;
(4) use a bunch of ReadWrite windows: both clipping and event
distribution server-side (the Motif/Xt model).
When chosing one of the above, you should realise that both GC clips
and windows are represented in XY-banded form within the server; thus,
shaped (non-rectangular) GC clips and windows will lead to poor
performance. (Do not believe that you can set the GC clip to a
pixmap! The server will silently convert it to XY-banded form.) In
addition, setting the GC clip is an expensive operation, which is why
you should use a bunch of GCs rather than a single one.
My gut instinct is that model 3 (server-side event distribution,
client-side clipping), if done right, will offer the best performance,
although making use of window backgrounds (only possible in model 4)
is definitely tempting.
Model 2 is likely to be the most inefficient of the bunch.
Regards,
Juliusz
"Kenny Tilton" <·······@nyc.rr.com> wrote
> Still trying to settle on the best approach to developing an alternative
> to CLIM, thought I'd get some CL community input (sort of get the arrows
> in the chest instead of the back)....
>
> I've implemented a Garnet-like GUI twice, once under MCL/Mac, once under
> ACL/Win32. Now the Mac OS way back when did not see buttons as windows.
> The window was a window, the button was a control which was not a
> window. Win32 like X sees buttons as windows, each for example with
> their own event stream.
>
> Midway thru development of the ACL/Win32 version, in the hope of
> leveraging groovy widgets like tab controls I spent a month getting my
> garnet-like scheme to cope with the X model, to give that a name, but of
> course it was win32 I was wrestling with. Got it to work, hated it. So I
> pulled the plug and just reinvented widgets as needed, which was vastly
> easier AFAIWC than dealing with the X model.
>
> So I am tempted to go with the mac model in which a window is a window
> is not a button. But if there is something insanely great about the X
> model I would reconsider. Something perhaps to do with efficient
> client-server performance?
I have done such a cross platform library once. It was working on Windows,
Mac and X. I have also chosen the "do every thing yourself in one window"
way. There was 2 reasons for this : portability and speed.
The windows are used as graphic ports where buttons, edit boxes, etc. are
drawn. Even the dialog boxes are done that way. That way it is possible to
have a Windows look and feel on the Mac (or the other way if you prefer...).
There is no messages between the widgets but direct method calls. The speed
is quite good and even if today the difference is not perceptible it was
quite an advantage a few years ago. The only drawback is that nobody
understand while it takes so long to integrate a new widget.
I still think it's a good idea for portability but the speed advantage has
vanished.
Marc