From: Eric Marsden
Subject: Re: Thoughts on CLIO/CLUE/CLX
Date:
Message-ID: <wzihess3zlv.fsf@laas.fr>
>>>>> "ri" == Rajappa Iyer <···@panix.com> writes:
ri> Has anyone any thoughts on the merits of the CLIO/CLUE/CLX GUI
ri> `stack'? Has anyone got it working on CMUCL or CLISP?
I tried to make them work with CMUCL, to experiment with the Closure
web browser by Gilbert Baumann. I started from the CLIO and CLUE
packages in the CMUCL source distribution (which were already modified
by pw for CMUCL), and made the code more ANSI compliant, mainly
changing old-style VALUES declarations.
My experience is that exposure events are not handled properly, and
keyboard input doesn't really work. I can't judge how much work would
be required to fix this.
CLX works quite well, but obviously is much more low level.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
>
> >>>>> "ri" == Rajappa Iyer <···@panix.com> writes:
>
> ri> Has anyone any thoughts on the merits of the CLIO/CLUE/CLX GUI
> ri> `stack'? Has anyone got it working on CMUCL or CLISP?
>
> I tried to make them work with CMUCL, to experiment with the Closure
> web browser by Gilbert Baumann.
How did it go? I have been thinking a CL browser could do some very cool
stuff, did not know one existed till now. Is Closure under active
development? Latest source I saw was '99.
I am also interested in finding a nice entry point in the 'stack' for
developing a new Garnet-like CL GUI. The stack frame I am after, to
continue the metaphor, would be one offering the same level of
abstraction as programming the Mac OS Toolbox or Win32. I had been
leaning towards one of the CL binding sets for GTK+, but CLX sounds
good, too. One thing about GTK+ is that it seems to cover Win32 as well
as X systems.
Anyway, I am pretty lost in all the possibilities. Not really interested
in being a sysadmin, but it would be nice to find a reasonably portable
library to build on. Now with MacOSX it seems something X is definitely
in order.
kenny
clinisys
From: Eric Marsden
Subject: Re: Thoughts on CLIO/CLUE/CLX
Date:
Message-ID: <wziu1wr39ly.fsf@laas.fr>
>>>>> "kt" == Kenny Tilton <·······@nyc.rr.com> writes:
ecm> I tried to make them work with CMUCL, to experiment with the
ecm> Closure web browser by Gilbert Baumann.
kt> How did it go? I have been thinking a CL browser could do some
kt> very cool stuff, did not know one existed till now. Is Closure
kt> under active development? Latest source I saw was '99.
my expectations were similar to Johnson's: GUI development in the free
CL implementations is like a dog's walking on its hind legs. It is not
done well, but you are suprised to find it done at all. (It would be
great if the situation changed!)
Considering the difficulty of the problem, Closure is really
impressive; it can parse and display complex web pages correctly,
including tables and CSS, and is reasonably fast. However, not being
able to enter new URLs from the keyboard is annoying, and refreshes
aren't handled correctly (I think both these problems are really with
CLIO, not with Closure).
Gilbert told me that he is developing a new interface for McCLIM (he
should really update that web page!).
kt> I am also interested in finding a nice entry point in the
kt> 'stack' for developing a new Garnet-like CL GUI. The stack frame
kt> I am after, to continue the metaphor, would be one offering the
kt> same level of abstraction as programming the Mac OS Toolbox or
kt> Win32. I had been leaning towards one of the CL binding sets for
kt> GTK+, but CLX sounds good, too.
it seems that McCLIM, a free CLIM reimplementation, is progressing
reasonably well. I think it has CLX, GTk and Postscript interfaces,
maybe OpenGL (hopefully someone can say more, I haven't followed
development).
<URL:http://www.mikemac.com/mikemac/McCLIM/>
kt> One thing about GTK+ is that it seems to cover Win32 as well as
kt> X systems.
and Aqua on MacOS10 -- <URL:http://www.macgimp.org/>.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden <········@laas.fr> writes:
> it seems that McCLIM, a free CLIM reimplementation, is progressing
> reasonably well. I think it has CLX, GTk and Postscript interfaces,
> maybe OpenGL (hopefully someone can say more, I haven't followed
> development).
>
> <URL:http://www.mikemac.com/mikemac/McCLIM/>
How usable is this getting? (it's kind of hard to tell from the
minimal web page). So, PostScript ... does that mean PS for printing
only, or is there hope for Display PostScript :) ?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Eric Marsden <········@laas.fr> writes:
>
> > it seems that McCLIM, a free CLIM reimplementation, is progressing
> > reasonably well. I think it has CLX, GTk and Postscript interfaces,
> > maybe OpenGL (hopefully someone can say more, I haven't followed
> > development).
> >
> > <URL:http://www.mikemac.com/mikemac/McCLIM/>
> How usable is this getting? (it's kind of hard to tell from the
> minimal web page). So, PostScript ... does that mean PS for
> printing only, or is there hope for Display PostScript :) ?
I just downloaded it, and started the load of it atop CCLAN...
My loader, after a bit of light hacking on system.lisp to load in
dependancies via:
(require :cmucl-graystream)
(require :cmucl-clx)
;;; $Id$
;;; cbbrowne
;;; Mon Oct 22 17:51:28 EDT 2001
(load "system.lisp")
(load "patch-cmu.lisp")
(operate-on-system :clim :load :load-source-instead-of-binary t)
(operate-on-system :clim-clx :load :load-source-instead-of-binary t)
(operate-on-system :clim :compile)
(operate-on-system :clim-clx :compile)
(operate-on-system :clim-examples :compile)
(operate-on-system :clim :load)
(operate-on-system :clim-clx :load)
(operate-on-system :clim-examples :load)
; Loading #p"/brownes/chvatal/home/cbbrowne/init.lisp".
;; Loading #p"/var/lib/cmucl/site-init.lisp".
;;; Loading #p"/etc/lisp-config.lisp".
;;; Loading #p"/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp".
CMU Common Lisp release x86-linux 3.0.4 18c+ 24 September 2001 build 2687, running on chvatal
For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS.
or to ········@debian.org
type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (load "loader.lisp")
; Loading #p"/opt/Lisp/McCLIM/loader.lisp".
;; Loading #p"/opt/Lisp/McCLIM/system.lisp".
;;; Loading #p"/usr/share/common-lisp/systems/cmucl-graystream.system".
;;; Loading #p"/usr/share/common-lisp/systems/cmucl-clx.system".
;; Loading #p"/opt/Lisp/McCLIM/patch-cmu.lisp".
;; (DEFCLASS) is patched.
;; (DEFCONSTANT) is patched.
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
NIL is not of type (MOD 536870911)
Restarts:
0: [CONTINUE] Return NIL from load of "/opt/Lisp/McCLIM/ports.lisp".
1: Return NIL from load of "loader.lisp".
2: [ABORT ] Return to Top-Level.
Debug (type H for help)
(POSITION #\. NIL :FROM-END NIL ...)
Source:
; File: target:code/seq.lisp
; File has been modified since compilation:
; target:code/seq.lisp
; Using form offset instead of character position.
(DEFUN POSITION (ITEM SEQUENCE &KEY FROM-END (TEST #'EQL) ...)
"Returns the zero-origin index of the first element in SEQUENCE
satisfying the test (default is EQL) with the given ITEM"
(SEQ-DISPATCH SEQUENCE (LIST-POSITION* ITEM SEQUENCE FROM-END TEST ...)
(VECTOR-POSITION* ITEM SEQUENCE FROM-END TEST ...)))
0] 0
Warning: This variable is undefined:
TYPE-ERROR
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable TYPE-ERROR is unbound.
Error flushed ...
0] 0
Warning: These functions are undefined:
MAKE-LINE-STYLE MAKE-TEXT-STYLE
The slot PCL:CLASS-PRECEDENCE-LIST is unbound in the object #<Standard-Class CLX-PORT
{4820A90D}>
Restarts:
0: [CONTINUE] Return NIL from load of "/opt/Lisp/McCLIM/clx-port.lisp".
1: Return NIL from load of "loader.lisp".
2: [ABORT ] Return to Top-Level.
Debug (type H for help)
(PCL::|(FAST-METHOD SLOT-UNBOUND (T T T))| #<unused-arg>
#<unused-arg>
#<unused-arg>
#<Standard-Class CLX-PORT
{4820A90D}>
...)
Source:
; File: target:pcl/slots.lisp
; File has been modified since compilation:
; target:pcl/slots.lisp
; Using form offset instead of character position.
(ERROR 'UNBOUND-SLOT :SLOT SLOT-NAME :INSTANCE ...)
0] 0
Warning: CLIM-INTERNALS also shadows the following symbols:
(CLIM-INTERNALS::LETF)
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
NIL is not of type (MOD 536870911)
Restarts:
0: [CONTINUE] Return NIL from load of "/opt/Lisp/McCLIM/ports.x86f".
1: Return NIL from load of "loader.lisp".
2: [ABORT ] Return to Top-Level.
Debug (type H for help)
(POSITION #\. NIL :FROM-END NIL ...)
Source:
; File: target:code/seq.lisp
; File has been modified since compilation:
; target:code/seq.lisp
; Using form offset instead of character position.
(DEFUN POSITION (ITEM SEQUENCE &KEY FROM-END (TEST #'EQL) ...)
"Returns the zero-origin index of the first element in SEQUENCE
satisfying the test (default is EQL) with the given ITEM"
(SEQ-DISPATCH SEQUENCE (LIST-POSITION* ITEM SEQUENCE FROM-END TEST ...)
(VECTOR-POSITION* ITEM SEQUENCE FROM-END TEST ...)))
0] 0
Error in function OPEN:
Error opening #p"/opt/Lisp/McCLIM/grafts.x86f", Permission denied.
Restarts:
0: [CONTINUE] Try again.
1: Return NIL from load of "loader.lisp".
2: [ABORT ] Return to Top-Level.
Debug (type H for help)
(OPEN #p"/opt/Lisp/McCLIM/grafts.x86f" :DIRECTION :OUTPUT :ELEMENT-TYPE ...)
Source:
; File: target:code/fd-stream.lisp
; File has been modified since compilation:
; target:code/fd-stream.lisp
; Using form offset instead of character position.
(CERROR "Try again."
"Error opening ~S, ~A."
PATHNAME
(UNIX:GET-UNIX-ERROR-MSG ERRNO))
0] 1
NIL
*
Doesn't seem to be quite usable as-is; maybe I'm missing something
dumb, though I don't think so. This would be a rather nifty thing to
get put into CCLAN in anything resembling a _vaguely_ working state...
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www.cbbrowne.com/info/languages.html
Rules of the Evil Overlord #134. "If I am escaping in a large truck
and the hero is pursuing me in a small Italian sports car, I will not
wait for the hero to pull up along side of me and try to force him off
the road as he attempts to climb aboard. Instead I will slam on the
brakes when he's directly behind me. (A rudimentary knowledge of
physics can prove quite useful.)" <http://www.eviloverlord.com/>
········@acm.org writes:
Sorry about your bad experience trying to use McCLIM.
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ;; Loading #p"/opt/Lisp/McCLIM/patch-cmu.lisp".
> ;; (DEFCLASS) is patched.
> ;; (DEFCONSTANT) is patched.
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> NIL is not of type (MOD 536870911)
>
> Restarts:
> 0: [CONTINUE] Return NIL from load of "/opt/Lisp/McCLIM/ports.lisp".
> 1: Return NIL from load of "loader.lisp".
> 2: [ABORT ] Return to Top-Level.
I have never seen this problem.
> Warning: These functions are undefined:
> MAKE-LINE-STYLE MAKE-TEXT-STYLE
Yes, this is a known problem that should be fixed
>
> The slot PCL:CLASS-PRECEDENCE-LIST is unbound in the object #<Standard-Class CLX-PORT
> {4820A90D}>
>
> Restarts:
> 0: [CONTINUE] Return NIL from load of "/opt/Lisp/McCLIM/clx-port.lisp".
> 1: Return NIL from load of "loader.lisp".
> 2: [ABORT ] Return to Top-Level.
Never seen this problem either. It looks like things don't get loaded
in the right order.
> [etc]
> Doesn't seem to be quite usable as-is; maybe I'm missing something
> dumb, though I don't think so.
We certainly don't get this kind of problem. There are tons of
warnings from the compiler, but everything compiles without errors,
and the result is usable.
> This would be a rather nifty thing to
> get put into CCLAN in anything resembling a _vaguely_ working state...
I agree.
--
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.
---------------------------------------------------------------------
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> How usable is this getting? (it's kind of hard to tell from the
> minimal web page). So, PostScript ... does that mean PS for printing
> only, or is there hope for Display PostScript :) ?
There are two (maybe more) different ways of thinking about "Display
PostScript".
One would be to use an existing implementation of Display PostScript
as a backend for McCLIM. I suspect that would be a fairly easy thing
to do, given the simplicity of the existing PostScript code in McCLIM.
But I don't know how useful it would be. Are there still systems
around that use Display PostScript?
The other would be an implementation of Display PostScript (or
something similar) in McCLIM. That would be incredibly useful, for
instance so that PostScript fonts could be used in McCLIM windows with
all the backends. I have weak moments when I think I might implement
this, but then I remember that I have no spare time to do it.
--
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.
---------------------------------------------------------------------
Eric Marsden <········@laas.fr> writes:
> >>>>> "kt" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> kt> One thing about GTK+ is that it seems to cover Win32 as well as
> kt> X systems.
>
> and Aqua on MacOS10 -- <URL:http://www.macgimp.org/>.
I think the Gimp and other GTK+ apps need an X Server to run on Mac OS
X, either XFree86-Aqua or one of the commercial offerings like Tenon
or Exodus - you can't run the Gimp as a native Carbon or Cocoa
application.
Regards,
Edi.
I've used wxWindows (http://www.wxwindows.org) as a cross-platform GUI
tool for a computed tomography simulator (http://www.ctsim.org). On
UNIX platforms, it work's with GTK or Motif, on Windows it uses Win32,
and their is a beta version for MacOS. It works well and is well
documented.
It has bindings for C++, Python, and a basic-like language wxBasic.
It it wasn't such a large package, I'd consider writting a Lisp
interface layer. However, wxWindows tries, IMHO too hard, to be a
complete cross-platform OS. It has a file layer, threads, sockets,
ODBC, property files, HTML viewing and printing, opengl and much
more. Trying to write a lisp interface to all of those systems is
beyond my time availability.
I do wonder how feasible it would be to write a Lisp layer just for
the GUI part of wxWindows. With that binding layer, it should be
transparent to have a GUI application run on GTK, Motif, Win32, and
MacOS.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
Eric Marsden wrote:
>
> it seems that McCLIM, a free CLIM reimplementation, is progressing
> reasonably well. I think it has CLX, GTk and Postscript interfaces,
> maybe OpenGL (hopefully someone can say more, I haven't followed
> development).
>
> <URL:http://www.mikemac.com/mikemac/McCLIM/>
>
> kt> One thing about GTK+ is that it seems to cover Win32 as well as
> kt> X systems.
>
> and Aqua on MacOS10 -- <URL:http://www.macgimp.org/>.
doh! I saw a link to McCLIM and assumed it was a Mac/MCL port of CLIM,
didn't look any further. thx for the lead, looks promising. I am
guessing I can leverage all the lower-level interfaces to roll my own
GUI, bypassing the CLIM model for higher-level stuff.
I just DLed McCLIM and I do see OpenGL stuff in there.
"Dr. Edmund Weitz" wrote:
> I think the Gimp and other GTK+ apps need an X Server to run on Mac OS
> X, either XFree86-Aqua or one of the commercial offerings like Tenon
> or Exodus - you can't run the Gimp as a native Carbon or Cocoa
> application.
I am clueless on X, but would this "X Server for Mac" also be an
option?:
http://www.microimages.com/freestuf/mix/macindex.htm
I actually have a few MCL licenses from an earlier venture, might want
to dust those off, snag a new G4 with OSX (and iMusic <g>) and see if
McCLIM will run over there.
Or sit tight on this NT box and get by with MI/X for Windoze--I kinda
like the idea of using a full-featured commercial Lisp and /not/ getting
into sysadmin stuff, tho the upshot of the Debian-BSD thread seems to be
that I would do OK if I went with a stable release and kept my mitts off
of things.
Lessee, taking McCLIM as a given...
Lisp: ACL, LispWorks, CormanCL, CMUCL, MCL, OpenMCL
OS: BSD, Linux, LinuxPPC, NT+MI/X, OSX+MI/X
Geez, I need more options so I can be totally paralyzed by confusion. :)
kenny
clinisys
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> writes:
> I actually have a few MCL licenses from an earlier venture, might want
> to dust those off, snag a new G4 with OSX (and iMusic <g>) and see if
> McCLIM will run over there.
I always thought MCL came with CLIM. If you do have the real thing, why
would you want to use McCLIM instead? (As far as I know, no one has ever tried
compiling McCLIM on MCL.)
> Lessee, taking McCLIM as a given...
I wouldn't say that! :-) McCLIM is definitely a work in progress. Thanks
mostly to a group of hard working students in France! And others! (I don't
want to get into trouble for not appreciating everyone who's contributed to
the effort.)
Mike McDonald
·······@mikemac.com
Mike McDonald wrote:
>
> In article <·················@nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > I actually have a few MCL licenses from an earlier venture, might want
> > to dust those off, snag a new G4 with OSX (and iMusic <g>) and see if
> > McCLIM will run over there.
>
> I always thought MCL came with CLIM. If you do have the real thing, why
> would you want to use McCLIM instead? (As far as I know, no one has ever tried
> compiling McCLIM on MCL.)
Well I am definitely open to suggestions. My MCLs are five+ years old,
and in fact the last time I looked -- waaaay back when -- Digitool was
coming up short on promised releases because they were scrambling to get
CLIM done. So I was pre-MCL/CLIM and I am not sure MCL/CLIM is what I
want. The thing that got me going about McCLIM was:
> Eric Marsden:
> it seems that McCLIM, a free CLIM reimplementation, is progressing
> reasonably well. I think it has CLX, GTk and Postscript interfaces,
> maybe OpenGL (hopefully someone can say more, I haven't followed
> development).
As advertised previously I am clueless: does MCL/CLIM offer those same
interfaces? I don't really want CLIM, I want to build a new Garnet-like
GUI framework on top of those interfaces.
>
> > Lessee, taking McCLIM as a given...
>
> I wouldn't say that! :-) McCLIM is definitely a work in progress. Thanks
> mostly to a group of hard working students in France! And others!
Conceivably I could just make my stuff a contrib to McCLIM, then start
growing a parallel GUI parasitically within the project. Not to be
disruptive but as long as the McCLIM interfaces would be core to my GUI,
to keep the overall CL GUI effort in one place.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Conceivably I could just make my stuff a contrib to McCLIM, then start
> growing a parallel GUI parasitically within the project. Not to be
> disruptive but as long as the McCLIM interfaces would be core to my GUI,
> to keep the overall CL GUI effort in one place.
I think that's a good idea. Anything that helps the usefulness of
McCLIM is welcome. And whenever you need to implement some general
functionality, please consider making part of McCLIM itself.
--
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.
---------------------------------------------------------------------
Robert STRANDH wrote:
>
> And whenever you need to implement some general
> functionality, please consider making part of McCLIM itself.
That's what I was thinking, make it easier for general stuff to spill
over into the CLIM effort.
Still educating myself, and this has me puzzled: I see mention of
"interface to CLX", but CLX is CL so I do not need an interface--true?
ie, better expressed as "CLIM implemented on top of CLX"?
OTOH the OpenGL interface might be a big help, and I do fancy doing
learning the 3D stuff.
I am thinking: Debian+CMUCL+ILisp+Emacs on my Pentium, maybe all under
VMWare (sp?). How's that for a platform?
kenny
clinisys
uh-oh, what's this?:
http://catalog.com/hopkins/unix-haters/x-windows/disaster.html
Seven years old, but...from the horror Hopkins describes not sure how
any number of years could make a difference. Never did like the idea of
a button as a window myself.
Is "X" a necessary evil (for its universality) or is everybody now
tickled to death with the thing (universal and slick and efficient)?
I just need a bitmapped window, draw routines, and event/message stream,
and am tempted to just do native Mac/Win32 implementation layers if X
will be a needless drain on my energies. I mean, if I can build a better
Open CLIM some X afficionado can do an X port, yes?
Only thing is I /am/ keen to support OpenGL.
confused,
kenny
clinisys
* Kenny Tilton wrote:
> Is "X" a necessary evil (for its universality) or is everybody now
> tickled to death with the thing (universal and slick and efficient)?
X was really slow on Sun3-class machines, especially pre X11R4 (I
think, I forget which one had the big speed improvements that made it
work OK on a 3/50). But machines are a bit faster now, and programs
are bigger while X has remained pretty much the same - a megabyte used
to seem like appalling bloat for an X server when the machine had 4Mb
of memory, it doesn't any more. Unless you need *really* high
performance for video games or serious visualisation stuff, I think X
is fast and small now.
--tim
Tim Bradshaw wrote:
> But machines are a bit faster now, and programs
> are bigger while X has remained pretty much the same - a megabyte used
> to seem like appalling bloat for an X server when the machine had 4Mb
> of memory, it doesn't any more.
Sounds like Lisp. :)
> Unless you need *really* high
> performance for video games or serious visualisation stuff, I think X
> is fast and small now.
OK, thx, I'll keep an open mind. But this bit of Hopkins caught my eye:
"The database client/server model...makes sense. The computation
client/server model...makes sense. But a graphical client/server model
that slies [sic] the interface down some arbitrary middle is like
Solomon following through with his child-sharing strategy."
That sounds right to me, makes me worry that the X model might be out of
whack. and...
"The right graphical client/server model is to have an extensible
server. ...Downloaded code can draw windows, track input eents, provide
fast interactive feedback, and minimize network traffic by communicating
with the application using a dynamic, high-level protocol. "
...hey, code as data, sounds like Lisp to me. :) Actually, my little
Garnet-like hack provides a nice organizing principle for shipping code
around. Hmmm...
Now what's this?:
"Programming X-Windows is like trying to find the square root of pi
using roman numerals. -- Unknown"
OK, the hardware can handle the load today, but is X any easier to live
with? I was wondering why there were so many wrapper systems for X. :) I
think I need to go to the bookstore and sit on the floor in the middle
of a big pile of books. :) Gonna check out an X newsgroup, too.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Tim Bradshaw wrote:
> > But machines are a bit faster now, and programs
> > are bigger while X has remained pretty much the same - a megabyte used
> > to seem like appalling bloat for an X server when the machine had 4Mb
> > of memory, it doesn't any more.
> Sounds like Lisp. :)
Mind you, X sessions can, in these modern days where graphics cards
may have 64MB of RAM on them, grow to Considerable Size.
(XFree86 appears to be eating about 80MB of RAM on my system at the
moment, including the 16MB of video card RAM. Not _too_ significant
when the machine has 640MB, but it's by no means tiny...)
> > Unless you need *really* high performance for video games or
> > serious visualisation stuff, I think X is fast and small now.
> OK, thx, I'll keep an open mind. But this bit of Hopkins caught my
> eye:
> "The database client/server model...makes sense. The computation
> client/server model...makes sense. But a graphical client/server
> model that slies [sic] the interface down some arbitrary middle is
> like Solomon following through with his child-sharing strategy."
> That sounds right to me, makes me worry that the X model might be
> out of whack. and...
> "The right graphical client/server model is to have an extensible
> server. ...Downloaded code can draw windows, track input eents,
> provide fast interactive feedback, and minimize network traffic by
> communicating with the application using a dynamic, high-level
> protocol. "
> ....hey, code as data, sounds like Lisp to me. :) Actually, my little
> Garnet-like hack provides a nice organizing principle for shipping code
> around. Hmmm...
If you have a mechanism for making sure that there's some sort of
"extensible server" sitting near the X server, then the situation is,
if not _totally_ resolved, at least considerably mitigated...
> Now what's this?:
> "Programming X-Windows is like trying to find the square root of pi
> using roman numerals. -- Unknown"
> OK, the hardware can handle the load today, but is X any easier to
> live with? I was wondering why there were so many wrapper systems
> for X. :) I think I need to go to the bookstore and sit on the floor
> in the middle of a big pile of books. :) Gonna check out an X
> newsgroup, too.
Hardly anybody except for those building GUI toolkits programs X
directly; it certainly would be a good idea to look at some of the
toolkits.
Ones that you should certainly be aware of include:
- GTK - fairly ubiquitous; C-oriented, but with bindings to lots of
languages _including CL_;
- Qt - pretty much just for use with C++ (with bindings to Python and
Perl);
- Motif - CLM apparently interfaces to this;
- FLWM - an apparently nice C++-based library;
- WxWindows - a multi-platform library that can use GTK as the
renderer; also C++-oriented;
- Tk - multi-platform, oriented towards TCL and C, but with many
bindings to many languages.
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/sgml.html
"The newsreader abuse likely stems from more fundamental, than merely
just the UI, design disagreements. Requests from Unix programmers to
replicate Free Agent rightfully so should trigger the throwing of
sharp heavy objects at the requesting party."
-- ····@dementia.mishnet (jedi)
········@acm.org wrote:
> Hardly anybody except for those building GUI toolkits programs X
> directly; it certainly would be a good idea to look at some of the
> toolkits.
Well, "building GUI toolkit", that's me, maybe I should start with CLX,
see how far I get. The Cliki page seems to recommend CLOCC as the best
CLX source.
I /was/ eyeballing GTK for a while, but I think if I am trying to do a
common CL gui the non-CL layer should be as thin as possible for max
portability and flexibility--any wrapper is bound to impose its own GUI
model we'd be stuck with.
kenny
clinisys
* Kenny Tilton wrote:
> Well, "building GUI toolkit", that's me, maybe I should start with CLX,
> see how far I get. The Cliki page seems to recommend CLOCC as the best
> CLX source.
> I /was/ eyeballing GTK for a while, but I think if I am trying to do a
> common CL gui the non-CL layer should be as thin as possible for max
> portability and flexibility--any wrapper is bound to impose its own GUI
> model we'd be stuck with.
The problem with this approach is that it means you have to implement
*all* the look and feel of the thing yourself. If you want your
buttons to have nice shaded edges you have to do that, in terms of
Xlib. if you want to look like other toolkits, then you have to do
that, and you have to track all the changes they make, and understand
whatever mechanisms they use to set preferences and so on. You might
need to work at this level, but it means that you have a *lot* of work
ahead of you unless you want to end up with something like Xaw used to
be before Xaw3d. Ending up with something that looks like Xaw used to
may make for interesting research, but it won't be something that's
widely used.
--tim (not that I have anything against Xaw: I build xemacs with it,
but I'm not your standard GUI user).
Tim Bradshaw wrote:
>
> * Kenny Tilton wrote:
> > I /was/ eyeballing GTK for a while, but I think if I am trying to do a
> > common CL gui the non-CL layer should be as thin as possible for max
> > portability and flexibility--any wrapper is bound to impose its own GUI
> > model we'd be stuck with.
>
> The problem with this approach is that it means you have to implement
> *all* the look and feel of the thing yourself. If you want your
> buttons to have nice shaded edges you have to do that, in terms of
> Xlib.
Yes, we rolled our own 3D effects in Quickdraw on the Mac, used the 3d
effects offered by win32.
> if you want to look like other toolkits, then you have to do
> that, and you have to track all the changes they make, and understand
> whatever mechanisms they use to set preferences and so on.
Why look like other toolkits? I mean, it's good to look /nice/, but you
talk about tracking changes to other toolkits so I guess you mean
duplicating their look-and-feel right down the line. Why would that be
an objective for an Open CL GUI project? (Not arguing, puzzled!)
You might
> need to work at this level, but it means that you have a *lot* of work
> ahead of you unless you want to end up with something like Xaw used to
> be before Xaw3d. Ending up with something that looks like Xaw used to
> may make for interesting research, but it won't be something that's
> widely used.
Just went over and looked at Xaw-Xpm and Xaw3d, thx for the lead.
Well one thing I gotta make clear is that the main point of this CL Open
GUI (CLOG? Cloggy?) project would be the Garnet-ish constraints (yechh)
aspect and the power that gives to an interface developer. I think eye
candy (a Good Thing) will be easy to layer in if the research project
(yes!) takes hold.
kenny
clinisys
* Kenny Tilton wrote:
> Why look like other toolkits? I mean, it's good to look /nice/, but you
> talk about tracking changes to other toolkits so I guess you mean
> duplicating their look-and-feel right down the line. Why would that be
> an objective for an Open CL GUI project? (Not arguing, puzzled!)
People like their screens to look reasonably integrated. Until you
have *all* the tools people want to use they are going to use other
toolkits too. When they ask gnome to change the buttons to look like
so-and-so, they aren't going to like it when half the applications
don't change. Even more they aren't going to like it whe one specific
application behaves differently than all the others. Of course, nerds
will tolerate this, but nerds are not enough to fund the kind of
effort you need to keep a GUI alive - look what happened to symbolics.
--tim
Kenny Tilton <·······@nyc.rr.com> writes:
> ········@acm.org wrote:
> > Hardly anybody except for those building GUI toolkits programs X
> > directly; it certainly would be a good idea to look at some of the
> > toolkits.
> Well, "building GUI toolkit", that's me, maybe I should start with
> CLX, see how far I get. The Cliki page seems to recommend CLOCC as
> the best CLX source.
> I /was/ eyeballing GTK for a while, but I think if I am trying to do
> a common CL gui the non-CL layer should be as thin as possible for
> max portability and flexibility--any wrapper is bound to impose its
> own GUI model we'd be stuck with.
I'd actually suggest GTK as a pretty _good_ choice; it _does_ run on
multiple platforms (Unix and Win32), and by using it, you'd get the
"themability" relatively "for free."
If you started from scratch with CLX, you'd be starting from zero, and
throwing in (say) 3D-like bitmaps would require significant surgery to
your code, and likely be slower than GTK. (Not that the nifty
'bitmap' functionality comes cheaply, CPU-wise...)
I think you'd be a LOT better off going with something like GTK, which
is _somewhat_ X-independent, than starting from scratch, at least from
the "eye-candy" perspective. "Eye-candy" may not be _important
functionality_, but perception is important, and a lot of people
_perceive_ that to be attractive...
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/advocacy.html
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
········@acm.org wrote:
> I'd actually suggest GTK as a pretty _good_ choice; it _does_ run on
> multiple platforms (Unix and Win32), and by using it, you'd get the
> "themability" relatively "for free."
ok, the needle swings back towards GTK. :) Indeed the first thing that
attracted me to McCLIM was a mistaken belief it had interfaces to GTK.
One thing I liked about GTK was the win32 support. But isn't XFree86 (?)
or someone also talking about providing X on win32?
Lessee, if I go with GTK on Win32 does that mean I can duck Linux and
CMUCL, sit tight on this NT box and snag CormanCL and cl-gtk or clg as
starting points? Or is it actually easier to go Debian/Linux/CMUCL and
not fight the current?
> "Eye-candy" may not be _important
> functionality_, but perception is important
i'm down with that. might be a quick win to be made more purely CL down
the road if anything comes of the project.
I am curious what the CL community would like in the way of an open GUI
project. thx for the strong vote for GTK.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> ········@acm.org wrote:
>
> > I'd actually suggest GTK as a pretty _good_ choice; it _does_ run on
> > multiple platforms (Unix and Win32), and by using it, you'd get the
> > "themability" relatively "for free."
>
> ok, the needle swings back towards GTK. :) Indeed the first thing that
> attracted me to McCLIM was a mistaken belief it had interfaces to GTK.
>
> One thing I liked about GTK was the win32 support. But isn't XFree86 (?)
> or someone also talking about providing X on win32?
I don't believe it'll ever make it to the DOS-based Windows platforms.
It works fine on NT, though, so depending on how much you can control
the deployment environment (and requiring the user to install
cygwin+Xfree is a big request), it's a good solution. Heck, thanks to
a burst of custom-looking small applications (WinAmp comes to mind),
Windows users are actually willing to consider "foreign"-looking apps.
Back to GTK, it's build on top of GDK (Gtk Drawing Kit, I think),
which means that you can take/leave as much of it as you like.
> Lessee, if I go with GTK on Win32 does that mean I can duck Linux and
> CMUCL, sit tight on this NT box and snag CormanCL and cl-gtk or clg as
> starting points? Or is it actually easier to go Debian/Linux/CMUCL and
> not fight the current?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> Back to GTK, it's build on top of GDK (Gtk Drawing Kit, I think),
> which means that you can take/leave as much of it as you like.
right, I want to make my own widgets so GDK seems to be the entry point
within the entry point of GTK.
But I think I need to learn a little X, so the current leader is:
Debian/Linux/iLisp/Emacs/CMUCL/CLX on Intel, as a contrib to McCLIM
y'all will with the insanely easy Debian/CMUCL install, right? :)
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> > Back to GTK, it's build on top of GDK (Gtk Drawing Kit, I think),
> > which means that you can take/leave as much of it as you like.
>
> right, I want to make my own widgets so GDK seems to be the entry point
> within the entry point of GTK.
>
> But I think I need to learn a little X, so the current leader is:
>
> Debian/Linux/iLisp/Emacs/CMUCL/CLX on Intel, as a contrib to McCLIM
>
> y'all will with the insanely easy Debian/CMUCL install, right? :)
If you can get Debian to install on your system, CMUCL is a simple
apt-get away. I've only had problems installing Debian on laptops or
other profoundly weird hardware. If that's the case for you,
linux.debian.user is your friend.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
> If you can get Debian to install on your system, CMUCL is a simple
> apt-get away.
OK, I just ordered a CD based on the Debian page suggestion that that
would be the easiest install, might try a download approach while I wait
and fall back on the CD if necessary when it arrives.
> If that's the case for you,
> linux.debian.user is your friend.
ok, i was wondering which NG would be best. hmmm, roadrunner does not
have that, only linux.redhat.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> ok, i was wondering which NG would be best. hmmm, roadrunner does not
> have that, only linux.redhat.
Google does, and it's also the debian-user mailing list (but it's
easier to use this kind of list through a mail interface, at least for
me).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
found it, thx. also just snagged a book (Lin, Norman "Linux 3d...") at
B&N with Debian and Mesa and more on the CD, away we go.
kenny
clinisys
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > ok, i was wondering which NG would be best. hmmm, roadrunner does not
> > have that, only linux.redhat.
>
> Google does, ...
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Heck, thanks to a burst of custom-looking small applications (WinAmp
> comes to mind), Windows users are actually willing to consider
> "foreign"-looking apps.
And if you consider the latest MediaPlayer (or whatewer it is called)
you see that Maosoft itself is pushing this to the [l]users -- soon
they all will not only be willing to consider, but demand that every
application has its own look/feel. (Considerable part of them are
already used to the fact that games come with different GUIs each;
this may be a legacy from DOS times when every game *had* to rool its
own GUI.)
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
Kenny Tilton <·······@nyc.rr.com> writes:
> One thing I liked about GTK was the win32 support. But isn't XFree86 (?)
> or someone also talking about providing X on win32?
<http://sources.redhat.com/cygwin/xfree/>
Kenny Tilton <·······@nyc.rr.com> writes:
> I am curious what the CL community would like in the way of an open GUI
> project. thx for the strong vote for GTK.
Thorough, concise, accurate, and up-to-date documentation. An active
development and user group. Stability, as few bugs as possible, and
portability to clisp and CMUCL.
The above are *WAY* more important to me then what's under the
hood. Note that writing top-notch documentation and keeping it in
synch with software can be as much (if not more) work then actual
coding.
Please don't think I'm greedy and unnapreciative of free software
which doesn't have the above. Just sharing what I personally would
look for in an "open GUI project".
Gabe Garza
Gabe Garza wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > I am curious what the CL community would like in the way of an open GUI
> > project. thx for the strong vote for GTK.
>
> Thorough, concise, accurate, and up-to-date documentation.
oops. i don't do doc.
> An active
> development and user group. Stability, as few bugs as possible, and
> portability to clisp and CMUCL.
my experience with clog antecedents has been that a relatively thin
interface to the window system can be used to effortlessly whip up any
given widget. so the thin layer means less to debug and keep stable,
then yer on yer own, free btw of assumptions forced on you by a
particular GUI framework.
stability will not matter because you can roll your own powerful widgets
so easily on top of the core. I did version one of scroll bars in a day,
likewise version one of a win32 tab control and VB grid controls. all
from scratch, mind you.
> Note that writing top-notch documentation and keeping it in
> synch with software can be as much (if not more) work then actual
> coding.
that's why I don't do doc.
>
> Please don't think I'm greedy and unnapreciative of free software
> which doesn't have the above. Just sharing what I personally would
> look for in an "open GUI project".
I guess that is the great thing about open software. From each according
to their ability and interest. If Clog takes off maybe some tech
writing-inclined soul will fill the gap.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Gabe Garza wrote:
> >
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > I am curious what the CL community would like in the way of an open GUI
> > > project. thx for the strong vote for GTK.
> >
> > Thorough, concise, accurate, and up-to-date documentation.
>
> oops. i don't do doc.
And I don't do large libraries with no documentation.
> > An active
> > development and user group. Stability, as few bugs as possible, and
> > portability to clisp and CMUCL.
>
> my experience with clog antecedents has been that a relatively thin
> interface to the window system can be used to effortlessly whip up any
> given widget. so the thin layer means less to debug and keep stable,
> then yer on yer own, free btw of assumptions forced on you by a
> particular GUI framework.
>
> stability will not matter because you can roll your own powerful widgets
> so easily on top of the core. I did version one of scroll bars in a day,
> likewise version one of a win32 tab control and VB grid controls. all
> from scratch, mind you.
When I write an application that uses a GUI, I don't want to have to
spend any more time/effort on the GUI than I need to. If the widget
system keeps getting all up in my face, I'm going to use another.
Docs, and the fact that it's stable (stable, dead, same difference :)
and doesn't force me to think about it all the time, are the major
reasons I use Garnet.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > oops. i don't do doc.
>
> And I don't do large libraries with no documentation.
Well first things first, there is not even a library to document. Some
folks will wait till it is all done, stable, documented, and gathering
dust before they look at it, other folks will take release 0.0a and
start playing with it because it is so cool. The latter don't need doc
because they can email the author and i'll add an appropriate example to
the Examples library. I myself prefer good working examples to Doc.
After examples my second choice is having the source, I read code more
easily than natural language.
One thing I have not made clear is that the interesting thing about this
GUI project is not the GUI, it is the constraints (ptooey) mechanism,
which does more than jut give you a powerful way to build interfaces. So
it might be fun for some to play on the bleeding edge even before the
package is all polished up with doc and stuff.
>
> When I write an application that uses a GUI, I don't want to have to
> spend any more time/effort on the GUI than I need to. If the widget
> system keeps getting all up in my face, I'm going to use another.
Sounds like your GUI requirements are vanilla, if so this GUI will be
insanely easy to live with. Even hairy stuff is easy. But there will
definitely be a time between when I start and when it will be ready for
prime time, dive in if/when you like.
kenny
clinisys
Lieven Marchand wrote:
> If you're interested in constraints and lisp, are you aware of the
> scwm window manager? It's partly written by a researcher in constraint
> algorithms and uses them for window layouts.
thx for the lead, i love the amount of stuff i run into involving
constraints. my approach is actually rather trivial in that there is no
"solving" by a constraints engine, it's just a dataflow model in which
slots get their values from rules. the spreadsheet metaphor works best.
i saw once in the literature that the constraints crowd consider this a
trivial case--i understand, but it sure makes programming easy and it
avoids all the problems of solution engines giving unexpected (and
unintended) results.
anyway, my current status is: gave up on Linux and have now installed
Gimp for Windows, which sits on top of the GTK. I also have DLed Gilbert
Baumann's CL-GTK bindings and Espen Johnson's bindings as well, gonna
see if I can get to the GDT from ACL.
My thinking is anything I do on win32 using gtk (gdt really) will port
to the linux world easily enough if the project proves worthwhile.
meanwhile I get further sooner on familiar ground.
kenny
clinisys
* cbbrowne wrote:
> Mind you, X sessions can, in these modern days where graphics cards
> may have 64MB of RAM on them, grow to Considerable Size.
> (XFree86 appears to be eating about 80MB of RAM on my system at the
> moment, including the 16MB of video card RAM. Not _too_ significant
> when the machine has 640MB, but it's by no means tiny...)
Depending on how carefully you (or the system) is counting it may or
may not be using that. In a lot of cases X server memory usage is
reported hopelessly wrongly because it may have multiple mappings of a
chunk of memory (often the framebuffer...) which are being counted as
different memory, when they aren't.
The other reason is things like backing store - a 24bit 600x400 window
is 700k, so if you have a lot of them this can eat a lot of memory.
Saving window contents is actually quite a good use of memory.,
--tim
Christopher Browne:
CB> (XFree86 appears to be eating about 80MB of RAM on my system at the
CB> moment, including the 16MB of video card RAM. Not _too_ significant
CB> when the machine has 640MB, but it's by no means tiny...)
Sorry for the offtopic comment, but this is complete and utter FUD.
The RSS that the system reports for the X server is completely
meaningless, as it includes any devices that the X server may be
mapping into its address space. With this new-fangled DRI thing, the
X server can often map the same device *multiple times*.
Hopkins:
>> "The right graphical client/server model is to have an extensible
>> server. ...Downloaded code can draw windows, track input eents,
>> provide fast interactive feedback, and minimize network traffic by
>> communicating with the application using a dynamic, high-level
>> protocol. "
Hopkins is a little disingeneous here. If you have high network
latencies, you do indeed want to download complete widgets to the
server (as in NeWS -- which is the background Hopkins comes from -- or
with Java applets). On the other hand, if a round-trip for every user
interaction is tolerable, the batching of requests by Xlib achieves
much the same effect as downloading rendering code to the server would.
Where Hopkins is right, though, is that X11 provides a completely
brain-damaged rendering model. (The event distribution model is
rather nice, though, in my opinion.)
Kenny Tilton:
>> ....hey, code as data, sounds like Lisp to me. :)
One of the main designer of NeWS -- which is what Hopkins is referring
to -- was James Gosling. Who, I am told, was aware of the existence
of Lisp.
(But so were the designers of X11. Not by accident, the XID range --
the type of the integer handles that the protocol uses to refer to
server-side objects -- is defined to be 29 bits.)
>> OK, the hardware can handle the load today, but is X any easier to
>> live with?
You're not supposed to program X11 at the protocol level. The tragedy
is that the work on the higher-level interface was never completed,
and then Motif came along.
GTK+ and Qt may very well be providing this higher level, 15 years late.
Juliusz
Juliusz Chroboczek wrote:
> On the other hand, if a round-trip for every user
> interaction is tolerable, the batching of requests by Xlib achieves
> much the same effect as downloading rendering code to the server would.
I do not know if you were speaking strictly when you said "downloading
rendering code", but I was thinking about DLing /parameters/ to code
supplied by the X server. I do not mean to quibble, just trying to make
sure I understand this brave new world. Granted, some widgets need their
own draw functions, but the GUI I will be offering generally gets by
with parametrization of a few classes, so perhaps less demands can be
made of the bandwidth.
>
> GTK+ and Qt may very well be providing this higher level, 15 years late.
>
What about CLX? From what I hear X is Hell, but CLX sure looks
approachable and familiar to me from my Mac Toolbox and Win32
experience. Well, plan A is to see how far I get with CLX and jump to
GTK+ if necessary, now I gotta go look at Qt. :)
General update: I installed VMWare atop NT, bought a book with a Debian
2.2 potato CD and installed on top of VMWare (the partitioning
requirement was a mystery solved only by a nice install tutorial at
debian.org) then picked a bunch of likely looking packages and let her
rip. Graphics card was not recognized, mouse could not be made to work,
oh well, once more into the breach when I have the energy.
kenny
clinisys
>> On the other hand, if a round-trip for every user interaction is
>> tolerable, the batching of requests by Xlib achieves much the same
>> effect as downloading rendering code to the server would.
KT> I do not know if you were speaking strictly when you said
KT> "downloading rendering code", but I was thinking about DLing
KT> /parameters/ to code supplied by the X server. I do not mean to
KT> quibble, just trying to make sure I understand this brave new
KT> world. Granted, some widgets need their own draw functions, but
KT> the GUI I will be offering generally gets by with parametrization
KT> of a few classes, so perhaps less demands can be made of the
KT> bandwidth.
There are two distinct issues. One is the issue of bandwith; the
other is the issue of the roundtrip time.
The thing that *must* *absolutely* be avoided is roundtrips. A single
roundtrip takes two context switches in the local case, a bunch of ms
on a LAN, and a significant fraction of a second on a transcontinental
link.
One way to avoid roundtrips is to download code into the server once
and for all. However, X11 has shown that this is not needed. Unless
I'm missing something, X11 manages to avoid roundtrips in all but three
cases:
(i) user interaction;
(ii) determining the position of *toplevel* windows;
(iii) querying font information.
(i) is unavoidable unless you're willing to download widget code to
the server; (ii) is unavoidable if you want to allow multiple window
management styles with no changes to applications. As to (iii), it is
due to the fact that the X11 font system is completely and utterly
brain-damaged.
Note that XFree86 are doing away with the core X11 fonts system,
moving to an elegant extension called RENDER together with a
client-side library called Xft.
The other issue is bandwidth. On modern networks (anything at least
as fast as a 32 kbps line), bandwidth is never an issue for 2D
graphics, except when dealing with images. And X11 already has the
ability to cache images server-side, so the ability to program the
server would not buy you much.
(With surprising regularity, the issue of providing an image compres-
sion extension for XFree86 comes up. However, nothing has come out of
that yet.)
(First person to mention XIE pays the next round.)
KT> What about CLX? From what I hear X is Hell, but CLX sure looks
KT> approachable and familiar to me from my Mac Toolbox and Win32
KT> experience.
Er... where did you get the impression that Xlib is worse than win32?
The X protocol is a protocol for manipulating complex server-side data
structures. Obviously, doing that will be much easier with a garbage
collector, keyword arguments, a garbage collector, dynamic typing, and
a garbage collector. (Did I mention memory allocation issues?)
Let me try to illustrate this. The CreateWindow protocol request
takes quite a few optional arguments. In order to express this in C,
the Xlib interface to CreateWindow, the XCreateWindow function, takes
a structure ``attributes'' containing the optional values together
with a bitmap ``valuemask'' which specifies which values in
``attributes'' are significant:
Window XCreateWindow(Display *display,
...,
unsigned long valuemask,
XSetWindowAttributes *attributes);
Of course, this being C, you need to manage the allocation of
``attributes'' and the consistency of ``valuemask'' with
``attributes'' by hand. Much of the boilerplate in Xlib (and Xt)
clients is due to this sort of issues.
The CLX version, CREATE-WINDOW, just needs to take a bunch of &KEY
arguments (see requests.lisp, near the top). Thus, 20 lines of
boilerplate are made obsolete with a single elegant language feature.
But CLX does not change the level of abstraction: just like Xlib, it
is a mere interface to the X11 protocol, only a slightly more elegant
one. It still exposes you to everything that the X11 protocol exposes
you to, including device coordinates, hardware-dependent PutImage
request, searching for the right visual, etc. (Hopkins quotes JWZ on
this very subject; search for a mail full of ``AIEEE'' and other
cartoon-like onomatopeia.)
To summarise, the only difference between Xlib and CLX is the amount
of boilerplate code you need to include.
(Actually, that's not quite true. There is one fundamental difference
between CLX and Xlib: in CLX, you can at least try to recover when you
get a protocol error; in Xlib, all you can do is save all files and
abort. For some reason I cannot recall right now, by the time your
error-handler is entered, you no longer can longjmp back into your
application.)
So while CLX is most definitely a better base for a window library
than Xlib, it is definitely not something that the user should be
forced to program to.
Regards,
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Christopher Browne:
>
> CB> (XFree86 appears to be eating about 80MB of RAM on my system at the
> CB> moment, including the 16MB of video card RAM. Not _too_ significant
> CB> when the machine has 640MB, but it's by no means tiny...)
>
> Sorry for the offtopic comment, but this is complete and utter FUD.
> The RSS that the system reports for the X server is completely
> meaningless, as it includes any devices that the X server may be
> mapping into its address space. With this new-fangled DRI thing, the
> X server can often map the same device *multiple times*.
I don't know what utilities/kernels you [bath] use, but for me top
shows memory usage like this:
PID USER TTY SIZE SWAP RSS %CPU %MEM TIME COMMAND
347 root ? 73240 62M 7920 2.9 6.2 34:04 XFree86
I assume all mmap'ped memory is counted as swap...
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
········@acm.org wrote:
>
>Hardly anybody except for those building GUI toolkits programs X
>directly; it certainly would be a good idea to look at some of the
>toolkits.
>
>Ones that you should certainly be aware of include:
>
> - GTK - fairly ubiquitous; C-oriented, but with bindings to lots of
> languages _including CL_;
Win32 port exists as well as linux (?) fb one.
> - Qt - pretty much just for use with C++ (with bindings to Python and
> Perl);
Qt is evil.
> - Motif - CLM apparently interfaces to this;
>
> - FLWM - an apparently nice C++-based library;
ITYM FLTK. Isn't FL*WM* a windowmanager based on it?
> - WxWindows - a multi-platform library that can use GTK as the
> renderer; also C++-oriented;
>
> - Tk - multi-platform, oriented towards TCL and C, but with many
> bindings to many languages.
Just a couple of details.
--
If xawtv dumps core, you can fix this with "ulimit -c 0".
* Kenny Tilton wrote:
> "The database client/server model...makes sense. The computation
> client/server model...makes sense. But a graphical client/server model
> that slies [sic] the interface down some arbitrary middle is like
> Solomon following through with his child-sharing strategy."
> That sounds right to me, makes me worry that the X model might be
> out of whack. and...
Well, yes, X sucks. Unix sucks too, but in neither of these cases do
you really want to get involved in redesign if you want to actually
write an application rather than writing a window system or an OS.
And you *definitely* don't want to do either unless you understand
*exactly* why they both suck and how they could be better.
One thing X definitely sucks *less* than is any model which assumes
you have a local framebuffer, in my opinion, like Windows does. That's
just really a pain for me - I *really want* to be able to have windows
from all sorts of machines on my screen. This may be my bias as a
systems person - I *need* to have windows from lots of machines since
I'm often dealing with lots of machines. I'm constantly amazed how
Windows people cope (the solution seems to be (a) walking around a lot
and (b) video/keyboard switches: somehow serial consoles behind a
switch and X is ... better).
(And of course Windows has made the additional decision to put a whole
lot of the window system into kernel space, where rogue code can eat
the machine. This is obviously the correct thing to do for Windows
since the core Windows market is video games, and basically no one
gives two hoots about reliability of Windows machines: they're just
expected to crash all the time.)
> "The right graphical client/server model is to have an extensible
> server. ...Downloaded code can draw windows, track input eents, provide
> fast interactive feedback, and minimize network traffic by communicating
> with the application using a dynamic, high-level protocol. "
Yes, this was NeWS. It would be interesting to know why it failed - I
suspect it was at least partly the proprietariness of PS. It was also
deeply, amazingly slow: much slower than X.
> OK, the hardware can handle the load today, but is X any easier to live
> with? I was wondering why there were so many wrapper systems for X. :) I
> think I need to go to the bookstore and sit on the floor in the middle
> of a big pile of books. :) Gonna check out an X newsgroup, too.
Well, X was *designed* to have wrappers around it. I think its main
problem was at the time it was being written there wasn't (or its
developers didn't think there was) a reasonable language in which to
implement a toolkit, so Xtk is this awful hack in C. Then, of course,
C++ happened, so people did toolkits in that, and they're probably
worse than Xtk, by the nature of C++.
I think what I'm trying to say is: yes, X is grot. But about 90% of
everything is grot, and a lot of it is *significantly* worse grot than
X, and you have to decide which bit of grot is most important to fix:
maybe that bit is not X.
--tim
> Well, yes, X sucks. Unix sucks too, but in neither of these cases do
> you really want to get involved in redesign if you want to actually
> write an application rather than writing a window system or an OS.
> And you *definitely* don't want to do either unless you understand
> *exactly* why they both suck and how they could be better.
Tell it like it is Tim! The major complaint about X seems to be that is
complex. Well GUIs are complex. Who said they were easy? I am sure that X
is a tradeoff that solves lots of real problems, otherwise it would not have
survived for so long.
Thanks Tim.
Wade
"Wade Humeniuk" <········@cadvision.com> writes:
> > Well, yes, X sucks. Unix sucks too, but in neither of these cases
> > do you really want to get involved in redesign if you want to
> > actually write an application rather than writing a window system
> > or an OS. And you *definitely* don't want to do either unless you
> > understand *exactly* why they both suck and how they could be
> > better.
>
> Tell it like it is Tim! The major complaint about X seems to be
> that is complex.
X is complex when one has to do the programming in C. When I first saw
CLX I was really amazed how simple it is (comparing to aforementioned
C). (Yes, I like CLX.)
> Well GUIs are complex. Who said they were easy?
Common Lisp looks like the most natural way to do GUI -- everything
that lacks keyword arguments will look complex. Not to mention real
macros.
> I am sure that X is a tradeoff that solves lots of real problems,
> otherwise it would not have survived for so long.
Maybe it has survived for the lack of better alternatives?
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
Janis Dzerins wrote:
>
> X is complex when one has to do the programming in C. When I first saw
> CLX I was really amazed how simple it is (comparing to aforementioned
> C). (Yes, I like CLX.)
Ahhh. CLX looks very familiar to me having dealt with the Mac and win32,
had me wondering what all the fuss was about over X being a disaster. :)
kenny
clinisys
In article <···············@cley.com>,
Tim Bradshaw <···@cley.com> writes:
> Yes, this was NeWS. It would be interesting to know why it failed - I
> suspect it was at least partly the proprietariness of PS. It was also
> deeply, amazingly slow: much slower than X.
If X is a pig, then NeWS(DPS) is a fricken beached whale! IMNSOHO. :-)
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> If X is a pig, then NeWS(DPS) is a fricken beached whale! IMNSOHO. :-)
Sun's NeWS is not the same thing as Adobe's Display Postscript.
Tim Bradshaw wrote:
> Well, yes, X sucks. Unix sucks too, but in neither of these cases do
> you really want to get involved in redesign if you want to actually
> write an application rather than writing a window system or an OS.
I do not want to make an app, I want to start an Open, cross-platform,
CL Gui project powered by Garnet-like constraints (tho I hate that
word). Before I have taken the MCL and ACL window classes and ignored
the rest. On the Mac I wrapped ToolBox controls, but on ACL my controls
are from scratch. I need an event stream from the OS (including update
events) and bit-mapped drawing functions.
> And you *definitely* don't want to do either unless you understand
> *exactly* why they both suck and how they could be better.
Agreed.
>
> One thing X definitely sucks *less* than is any model which assumes
> you have a local framebuffer,
not sure what that means, but I do like the idea of the app putting up a
window on a different box. btw, does X /really/ switch the meaning of
client and server as Hopkins alleges? I always thought the server had
the app and database and the client was where the user sat, Hopkins says
X reversed that.
> Well, X was *designed* to have wrappers around it.
OK, fair enough.
>
> I think what I'm trying to say is: yes, X is grot.
Well I'll at least make its acquaintance. If I isolate it as an
implementation layer it can always be swapped out, meanwhile it is
cross-platform and works remotely, which is nice.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Tim Bradshaw wrote:
> > One thing X definitely sucks *less* than is any model which assumes
> > you have a local framebuffer,
>
> not sure what that means, but I do like the idea of the app putting up a
> window on a different box. btw, does X /really/ switch the meaning of
> client and server as Hopkins alleges? I always thought the server had
> the app and database and the client was where the user sat, Hopkins says
> X reversed that.
Many of the complaints about X in that article were valid. This one
is just being obtuse: if you're confused about what's a client and
what's a server, just add an adjective. "Display server" -- it's
pretty easy to see that this serves up the display to the application,
which is a "display client".
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kenny Tilton <·······@nyc.rr.com> writes:
[SNIP]
> not sure what that means, but I do like the idea of the app putting up a
> window on a different box. btw, does X /really/ switch the meaning of
> client and server as Hopkins alleges? I always thought the server had
> the app and database and the client was where the user sat, Hopkins says
> X reversed that.
Depends on your definition of "client" and "server". My definition is
that the client is what requests something to happen and the server is
what makes that happen.
In X the application acts as a client to the X server (that draws on
the screen that the client human sits in front of).
This does reverse the meaning of "the client is what always runs on
the box where the human sits and the server doesn't, necessarily".
//Ingvar (have I said this before, I think I have)
--
Self-referencing
Five, seven, five syllables
This haiku contains
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> [SNIP]
> > not sure what that means, but I do like the idea of the app putting up a
> > window on a different box. btw, does X /really/ switch the meaning of
> > client and server as Hopkins alleges? I always thought the server had
> > the app and database and the client was where the user sat, Hopkins says
> > X reversed that.
> Depends on your definition of "client" and "server". My definition
> is that the client is what requests something to happen and the
> server is what makes that happen.
> In X the application acts as a client to the X server (that draws on
> the screen that the client human sits in front of).
> This does reverse the meaning of "the client is what always runs on
> the box where the human sits and the server doesn't, necessarily".
Exactly so.
The client/server system SAP R/3 describes _all_ of its system
components as being "servers" of one sort or another; you've got:
- Database servers;
- Application servers, where application code runs;
- Spool servers, where printed output is managed;
- Presentation servers, which is what the "GUI" part is called.
In effect, the X way of describing it represents a "peer-to-peer" way
of looking at networked applications.
A program or component that provides a "service" to another program or
component is characterized as a "server," whilst anything that
requests services is characterized as a "client."
Things get murky if a particular program behaves in both ways, that
is, it provides services to some, but also requests services of
others.
If you're looking at a strict "master/slave" situation (which, while
politically-incorrect, is a much more accurate way of looking at
things), things are not supposed to _be_ both ways. Masters are
masters; slaves are slaves; the only changes that take place would be
manumission or death.
The "X perspective" is much more consistent with a peer-to-peer view
of things...
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/x.html
Replying to one's own message is a rarely-exposed technique for
switching positions once you have thought about something only after
sending mail.
-- from the Symbolics Guidelines for Sending Mail
Tim Bradshaw <···@cley.com> writes:
> * Kenny Tilton wrote:
> > "The database client/server model...makes sense. The computation
> > client/server model...makes sense. But a graphical client/server model
> > that slies [sic] the interface down some arbitrary middle is like
> > Solomon following through with his child-sharing strategy."
>
> > That sounds right to me, makes me worry that the X model might be
> > out of whack. and...
> Well, yes, X sucks. Unix sucks too, but in neither of these cases
> do you really want to get involved in redesign if you want to
> actually write an application rather than writing a window system or
> an OS. And you *definitely* don't want to do either unless you
> understand *exactly* why they both suck and how they could be
> better.
.. And have the time and money to spend on what is likely to be a
Really Huge Task.
That's essentially why the "Let's Make a LispOS" project is more or
less perpetually doomed to failure:
-> On the one hand, it seems such a cool idea to build a kernel in
Lisp;
-> On the other hand, the project involves _really a lot of ongoing
work_:
- Creating device drivers for the current hardware you're using;
- Building new ones, a year down the road, because the hardware
that was available a year ago is no longer for sale because
Adaptec bought out your SCSI provider, or S3 went belly up, or
Intel is making a new motherboard chipset;
- Building probably a multiplicity of compiler backends for
different architectures, because next year, AMD Sledgehammer or
IA-64 may be out in quantity, or the Alpha version may be
largely pointless because Compaq has largely discontinued sales
of hardware, or 3Com may have discontinued the supported NIC;
- The same principles apply to a graphical subsystem; it's likely
to be of limited interest unless it's "smart enough" to host
Emacs, which means it needs to be pretty sophisticated and
complex, and the effort involved in making GNU/X Emacs host atop
something completely new would be Rather Substantial.
> One thing X definitely sucks *less* than is any model which assumes
> you have a local framebuffer, in my opinion, like Windows
> does. That's just really a pain for me - I *really want* to be able
> to have windows from all sorts of machines on my screen. This may
> be my bias as a systems person - I *need* to have windows from lots
> of machines since I'm often dealing with lots of machines. I'm
> constantly amazed how Windows people cope (the solution seems to be
> (a) walking around a lot and (b) video/keyboard switches: somehow
> serial consoles behind a switch and X is ... better).
A typical gripe amongst Linux folk is along the lines of:
"I hate how big X is; wouldn't it be smaller and faster if they
omitted network support?"
[Retorts left as an exercise for the reader :-).]
> (And of course Windows has made the additional decision to put a
> whole lot of the window system into kernel space, where rogue code
> can eat the machine. This is obviously the correct thing to do for
> Windows since the core Windows market is video games, and basically
> no one gives two hoots about reliability of Windows machines:
> they're just expected to crash all the time.)
> > "The right graphical client/server model is to have an extensible
> > server. ...Downloaded code can draw windows, track input eents,
> > provide fast interactive feedback, and minimize network traffic by
> > communicating with the application using a dynamic, high-level
> > protocol. "
> Yes, this was NeWS. It would be interesting to know why it failed -
> I suspect it was at least partly the proprietariness of PS. It was
> also deeply, amazingly slow: much slower than X.
There was concern about Postscript being proprietary; there were also
strong reactions against the hefty control over Unix graphics that
NeWS would give to _Sun_.
Retrospectively, concerns about Adobe seem well-placed; when Apple
bought NeXT, the arrangements surrounding DPS licensing were
terminated, with the result that Apple had to recreate the whole
rendering system, at which point they created _their own_ system,
Quartz, rather than licensing something from Adobe.
> > OK, the hardware can handle the load today, but is X any easier to
> > live with? I was wondering why there were so many wrapper systems
> > for X. :) I think I need to go to the bookstore and sit on the
> > floor in the middle of a big pile of books. :) Gonna check out an
> > X newsgroup, too.
> Well, X was *designed* to have wrappers around it. I think its main
> problem was at the time it was being written there wasn't (or its
> developers didn't think there was) a reasonable language in which to
> implement a toolkit, so Xtk is this awful hack in C. Then, of
> course, C++ happened, so people did toolkits in that, and they're
> probably worse than Xtk, by the nature of C++.
> I think what I'm trying to say is: yes, X is grot. But about 90% of
> everything is grot, and a lot of it is *significantly* worse grot
> than X, and you have to decide which bit of grot is most important
> to fix: maybe that bit is not X.
That's a good way of putting it.
There would be merit to creating something Better Than X, but the
overall architecture/analysis/design/implementation process
necessarily requires a really substantial amount of time, effort, and
resources.
Just to put a _vague_ pricetag on it, I'd have to suggest something
like $100M as the _starting_ point of an estimate. The processes
required to design and develop X cost somewhere on that sort of order
of magnitude.
If a million Linux users threw $100 at the wall to do such a project,
that might be enough _money_; that doesn't establish that there would
necessarily be an effort sufficiently organized to actually build
something better than X, or that the results would amount to
substantially more than a very loud set of "clunks" as many small
objects strike a wall...
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.cbbrowne.com/info/spreadsheets.html
PALINDROME spelled backwards is EMORDNILAP.
········@acm.org writes:
> Tim Bradshaw <···@cley.com> writes:
> > Yes, this was NeWS. It would be interesting to know why it failed -
> > I suspect it was at least partly the proprietariness of PS. It was
> > also deeply, amazingly slow: much slower than X.
>
> There was concern about Postscript being proprietary; there were also
> strong reactions against the hefty control over Unix graphics that
> NeWS would give to _Sun_.
>
> Retrospectively, concerns about Adobe seem well-placed; when Apple
> bought NeXT, the arrangements surrounding DPS licensing were
> terminated, with the result that Apple had to recreate the whole
> rendering system, at which point they created _their own_ system,
> Quartz, rather than licensing something from Adobe.
Of course, anyone could have done what the GNU project did, and just
paid Alladin to build them a PS system. I mean, if the FSF, for
godsakes, could come up with the money needed, a commercial unix
vendor could have.
Hmm, I should probably go read up on Quartz, but it's essentially
Display PDF, right? That's kind of too bad, because that means you
can't compute things with it, which means a dumb display server, which
is really at odds with reality (when was the last time you saw a
display server dumb enough not to be able to run its widgets,
connected to a network fast enough to transmit them?). I hope I'm
wrong about that, because Apple's looking more and more like it's
going to be my favorite Unix vendor.
That PostScript-in-Lisp package in the CMU AI repository got me all
excited once about the possibilities of a CL GUI toolkit that could
display on something like NeWS, because based around a package like
that one ... wow, you could do cool shit. But I forced myself to go
do something useful, on account of NeWS and OpenStep aren't exactly
common, to say the least.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* cbbrowne wrote:
> There was concern about Postscript being proprietary; there were also
> strong reactions against the hefty control over Unix graphics that
> NeWS would give to _Sun_.
Yes I'd forgotten that they owned it. That was one of their several
attempts to wander off and set their own standard like MS do now, only
to fail because they weren't a big enough player. I kind of hope they
learnt their lesson as they're getting frighteningly close to being
the only significant commercial Unix vendor (assuming HP/Compaq are as
dead at they smell, I guess there's IBM), and trying it now only hands
more power to MS.
> Just to put a _vague_ pricetag on it, I'd have to suggest something
> like $100M as the _starting_ point of an estimate. The processes
> required to design and develop X cost somewhere on that sort of order
> of magnitude.
Right, and the Windows GUI has probably had at least 10x that spent on
it.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
> Yes I'd forgotten that they owned it. That was one of their several
> attempts to wander off and set their own standard like MS do now, only
> to fail because they weren't a big enough player. I kind of hope they
> learnt their lesson as they're getting frighteningly close to being
> the only significant commercial Unix vendor (assuming HP/Compaq are as
> dead at they smell, I guess there's IBM), and trying it now only hands
> more power to MS.
You forgot Apple. It is a Unix vendor now with OSX. Since its new GUI
looks as bad and pain to use as other OSes, I think they can be hugely
successful.
abe
--
<keke at mac com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Still educating myself, and this has me puzzled: I see mention of
> "interface to CLX", but CLX is CL so I do not need an interface--true?
> ie, better expressed as "CLIM implemented on top of CLX"?
Sure, if you want. On the other hand, every library or other code
body such as CLX will have a hidden part that contains code to make
the thing work but that is hidden from the outside. I would call that
the "implementation of the code body". Then there is the part that is
accessible to the outside, the functions that are defined in the
documentation. These make up the "interface to the code body". Hence
"the interface to CLX".
--
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:
> Still educating myself, and this has me puzzled: I see mention of
> "interface to CLX", but CLX is CL so I do not need an interface--true?
> ie, better expressed as "CLIM implemented on top of CLX"?
>
What does the "I" in API stand for ?
--
H�kon Alstadheim, Montreal, Quebec, Canada
<heh-heh> "better expressed" would have been better expressed as "also
expressed". I did not mean to (but did!) challenge the usage "interface
to CLX".
My big worry was that what was being said was that McCLIM provided glue
if you will to CLX, meaning I did not in fact understand what CLX was.
kenny
clinisys
"H�kon Alstadheim" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Still educating myself, and this has me puzzled: I see mention of
> > "interface to CLX", but CLX is CL so I do not need an interface--true?
> > ie, better expressed as "CLIM implemented on top of CLX"?
> >
>
> What does the "I" in API stand for ?
>
> --
> H�kon Alstadheim, Montreal, Quebec, Canada
Kevin Rosenberg wrote:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > What does the "I" in API stand for ?
>
> Interface.
heh-heh, that was actually Hakon's question, and may have been
rhetorical. :)
kenny
clinisys
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
>
>
> heh-heh, that was actually Hakon's question, and may have been
> rhetorical. :)
>
What makes questions rhetorical? ;-)
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> What makes questions rhetorical? ;-)
A rhetorical question is a question not used for obtaining
information, but as a device in a discussion. Usually it is used to
make the other party look at things from a different angle, or to make
him look foolish.
In retrospect I was acting a bit too superior in this instance. My
thinking was as follows: Kenny Tilton <·······@nyc.rr.com> is thinking
the word "interface" is inappropropriate when talking about a layer on
top of CLX, since both are CL . (This , by the way , is a sure tip-off
that my question is rhetorical, I obviously knew the answer). I jump
to the conclusion that he is thinking FFI when he sees the word
interface, and I want to redirect his thinking, by pointing to the
term API.
My counter-example (API) was not a very good one, since API means so
many different things to different people. For the record: my
understanding of API is any kind of documented set of functions to
handle communications with a software toolbox or process of some kind.
Many others will assume this toolbox has to be another program, so you
end up with something very much like FFI. This obviously spoils the
cleverness of my first post in this thread. I shall shut up now and go
back to lurking.
--
H�kon Alstadheim, Montreal, Quebec, Canada
In article <·················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> writes:
> Still educating myself, and this has me puzzled: I see mention of
> "interface to CLX", but CLX is CL so I do not need an interface--true?
> ie, better expressed as "CLIM implemented on top of CLX"?
How about "a back end to CLIM has been implemented using CLX"? The CLIM spec
specifies the interface (set of routines and data structures) that CLIM uses
to access the display (a "PORT" in CLIM terms).
> OTOH the OpenGL interface might be a big help, and I do fancy doing
> learning the 3D stuff.
CLIM its self doesn't include 3D graphic operations. It's strickly a 2D
system. I haven't played with the OpenGL code in McCLIM yet so I'm not sure
what it does. A back end using OpenGL doesn't seem that exciting to me. Being
able to use OpenGL in a CLIM window, that'd be useful. IMNSHO!
Mike McDonald
·······@mikemac.com
Kenny Tilton <·······@nyc.rr.com> writes:
> I am clueless on X, but would this "X Server for Mac" also be an
> option?:
>
> http://www.microimages.com/freestuf/mix/macindex.htm
I'm pretty sure this one won't work with OS X, only with 'Classic' Mac
OS. I tried it a long time ago - it works but it basically has _no_
features. IIRC the only other option for Mac OS 9.x or lower is
Exodus <http://www.powerlan-usa.com/exodus/>.
The situation is different with OS X where you can choose between
Exodus, Xtools <http://www.tenon.com/products/xtools/> and XDarwin
<http://sourceforge.net/projects/xonx/> which is free. All of these
offer a rootless mode and a rather tight integration with the native
Aqua GUI of OS X.
HTH,
Edi.
Eric Marsden <········@laas.fr> writes:
> it seems that McCLIM, a free CLIM reimplementation, is progressing
> reasonably well. I think it has CLX, GTk and Postscript interfaces,
> maybe OpenGL (hopefully someone can say more, I haven't followed
> development).
Perhaps this is the time to give a general status report.
As far as I know, we do not have a GTk interface. The backend we are
mostly working with is CLX, but the OpenGL backend should work as
well.
The PostScript interface is for printing only. No display PostScript
backend has been worked on.
There is still plenty of stuff missing (in particular presentation
types). But the basic functionality is there: sheets, panes, gadgets,
output streams, output recording, frames, etc. There are even some
extensions (images, for instance).
The clim-fig demo should give you an idea of what can be done with
McCLIM in its current state. We are also currently using McCLIM for
the Gsharp interactive score editor project here in Bordeaux.
While work is progressing slowly but steadily, there is still a long
way to go. Nobody I know of has any clue as to how to implement
presentation types. I think it requires modifying CLOS method
combination and other things I know very little about. There are
literally hundreds of compiler warnings that I would like to get rid
of. Some of them are mostly a matter of putting in the right
declaration in the right place. Others are minor errors and omissions
that we need to fix at some point.
To our defense, I'd like to say that we have not oriented our work
towards general distribution quality. Given that, McCLIM is actually
fairly stable and useful. But at some point, it would be nice to have
a partial, but stable, distribution that compiles and runs out of the
box.
--
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.
---------------------------------------------------------------------
> I was wondering if CLUE + CLIO was a good starting point for getting
> something like STk for CL. Theoretically, it seems so. CLUE is
> perhaps closest to "raw" Tk (that hides most of the complexity of
> programming X directly) and CLIO is probably more like a widget
> library that one would like to program with.
If one isn't content to wait for McCLIM, which seems to be the most
promising lisp GUI effort, one might also take a look at XIT.
I've managed to get it to work under CMUCL + CLUE.
It's a CLOS-based Garnet knockoff, as best I can figure.
Its look and feel is old-style, and it's got some rough edges, but
someone might be able to have fun with it.
--
Fred Gilham ······@csl.sri.com
Ah, the 20th century, when the flight from reason crash-landed into
the slaughterhouse. --- James Ostrowski