I am looking for recomodations on GUI-tools. I need the following features:
- should run on multiple platforms (at least linux and windows) without
much code change.
- easy to build, preferably CLOS-alike
- free of charge
I prefer working in SBCL.
Oyvin Halfdan Thuv wrote:
> I am looking for recomodations on GUI-tools. I need the following features:
>
> - should run on multiple platforms (at least linux and windows) without
> much code change.
> - easy to build, preferably CLOS-alike
> - free of charge
>
> I prefer working in SBCL.
A few folks are trying to port my free (MIT license) Cello GUI from
AllegroCL-or-Lispworks/win32 to Linux, under various Lisp
implementations. Screenshots here:
http://www.tilton-technology.com/cellophane.html
That also has a link to the project and a mailing list you can watch to
see if anyone succeeds:
http://www.common-lisp.net/project/cells/
Discussion is there until the end of the week, when we should either
have Some Port (to Linux or OS X) working, at which point a separate
Cello project will be started.
Back at the first link you will find bindings to OpenGL and FreeGlut,
the basis of Cello. This AM I will add a version of my GUI which uses
nothing but those. That unfortunately also means limited font support,
since Glut offers only a few.
The next upload (later today? tomorrow?) will include bindings to
ImageMagick which will allow convenient access to JPGs, BMPs, and dozens
of other formats, /and/ access to any FreeType fonts (tho I am ahead of
myself here, because I have not yet played with fonts using ImageMagick).
I am doing the latter because one porter is having trouble so far
loading on Linux the FTGL lib I use for fonts under win32. And anyway,
it would be nice to have these libraries as clearly delineated
components one can use or not without giving up the rest of Cello.
If your SBCL/Linux is strong and you really want a GUI, hey, help is
needed. All components are portable in theory, so it is just a question
of sorting out the usual practical aggravation.
Cello needs a bunch more standard widgets, but I can churn those out in
short order. Right now we are focused on getting the thing running on a
different platform.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
>
> The next upload (later today? tomorrow?) will include bindings to
> ImageMagick which will allow convenient access to JPGs, BMPs, and
> dozens of other formats, /and/ access to any FreeType fonts (tho I am
> ahead of myself here, because I have not yet played with fonts using
> ImageMagick).
>
> I am doing the latter because one porter is having trouble so far
> loading on Linux the FTGL lib I use for fonts under win32. And anyway,
> it would be nice to have these libraries as clearly delineated
> components one can use or not without giving up the rest of Cello.
what's his problem? FTGL works here (gentoo GNU/Linux, not sure if i
haven't compiled it myself though).
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>The next upload (later today? tomorrow?) will include bindings to
>>ImageMagick which will allow convenient access to JPGs, BMPs, and
>>dozens of other formats, /and/ access to any FreeType fonts (tho I am
>>ahead of myself here, because I have not yet played with fonts using
>>ImageMagick).
>>
>>I am doing the latter because one porter is having trouble so far
>>loading on Linux the FTGL lib I use for fonts under win32. And anyway,
>>it would be nice to have these libraries as clearly delineated
>>components one can use or not without giving up the rest of Cello.
>
>
> what's his problem? FTGL works here (gentoo GNU/Linux, not sure if i
> haven't compiled it myself though).
>
Are you using FTGL from Lisp? Without C glue?
What I did on win32 was write a few lines of C glue to get at the C++
FTGL classes, then rebuild the FTGL dll with that code. I believe the
porter created a .SO for the C glue, linking that with a virgin FTGL
static lib. AllegroCL on Linux then screams about something being
unreadable when he tries to load the glue SO. Look for a recent query
here from Frank G. He is able to load SOs as a rule, but the ones he
builds have an issue, so it is probably some obscure linker incantation
or compiler directive that is needed. Ideas welcome.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
>>>I am doing the latter because one porter is having trouble so far
>>>loading on Linux the FTGL lib I use for fonts under win32. And anyway,
>>>it would be nice to have these libraries as clearly delineated
>>>components one can use or not without giving up the rest of Cello.
>> what's his problem? FTGL works here (gentoo GNU/Linux, not sure if i
>> haven't compiled it myself though).
>
> Are you using FTGL from Lisp? Without C glue?
nope. i misunderstood "loading on Linux the FTGL lib". sorry.
> What I did on win32 was write a few lines of C glue to get at the C++
> FTGL classes, then rebuild the FTGL dll with that code. I believe the
> porter created a .SO for the C glue, linking that with a virgin FTGL
> static lib. AllegroCL on Linux then screams about something being
> unreadable when he tries to load the glue SO. Look for a recent query
> here from Frank G. He is able to load SOs as a rule, but the ones he
> builds have an issue, so it is probably some obscure linker
> incantation or compiler directive that is needed. Ideas welcome.
i'm doing something similar but with cmucl, i wanna use my favorite
media library from lisp, but it has ugly API so i'm writing some
helper functions to hide ugliness from lisp. i can use the library
from C without much thinking, but when loading it into lisp i have to
say:
(load-foreign
'("artm-wrap.o"
"libmedia1.a"
"libmedia2.a")
:libraries '("-lc"
"-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/"
"-lgcc"
"-lz"))
i guess the libmedia uses some gcc-specific features on linux which
require linking with gcc... i'm not sure how this would have looked
in allegrocl, but the issue might be the same, no?
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski wrote:
> i'm doing something similar but with cmucl, i wanna use my favorite
> media library from lisp, but it has ugly API so i'm writing some
> helper functions to hide ugliness from lisp. i can use the library
> from C without much thinking, but when loading it into lisp i have to
> say:
>
> (load-foreign
> '("artm-wrap.o"
> "libmedia1.a"
> "libmedia2.a")
> :libraries '("-lc"
> "-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/"
> "-lgcc"
> "-lz"))
>
> i guess the libmedia uses some gcc-specific features on linux which
> require linking with gcc... i'm not sure how this would have looked
> in allegrocl, but the issue might be the same, no?
Ya never know, and maybe it will give us some ideas even if not directly
applicable. Thx for the input. I see libmedia is a C lib, whereas FTGL
is C++, and I think that is the problem. We'll see. Thx again.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Artem Baguinski wrote:
>
>> i'm doing something similar but with cmucl, i wanna use my favorite
>> media library from lisp, but it has ugly API so i'm writing some
>> helper functions to hide ugliness from lisp. i can use the library
>> from C without much thinking, but when loading it into lisp i have to
>> say:
>> (load-foreign
>> '("artm-wrap.o"
>> "libmedia1.a"
>> "libmedia2.a")
>> :libraries '("-lc"
>> "-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/"
>> "-lgcc"
>> "-lz"))
>> i guess the libmedia uses some gcc-specific features on linux which
>> require linking with gcc... i'm not sure how this would have looked
>> in allegrocl, but the issue might be the same, no?
>
>
> Ya never know, and maybe it will give us some ideas even if not
> directly applicable. Thx for the input. I see libmedia is a C lib,
> whereas FTGL is C++, and I think that is the problem. We'll see. Thx
> again.
i haven't used C++ for a long time, but some applications i use - do
and as far as i know they all are linked against some libraries with
'std' or 'c++' in their names. the directory where i find libgcc.a
contains those as well:
····@caracolito artm $ ls /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/*{std,c++}*
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.a
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.a
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.la
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.la
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++_pic.a
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++_pic.a
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libsupc++.a
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libsupc++.la
--
gr{oe|ee}t{en|ings}
artm
On 24 Feb 2004 12:25:30 +0100, Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> wrote:
> I am looking for recomodations on GUI-tools. I need the following
> features:
>
> - should run on multiple platforms (at least linux and windows) without
> much code change.
> - easy to build, preferably CLOS-alike
> - free of charge
>
> I prefer working in SBCL.
This is asked here every two weeks or so. You might want to search
Google Groups.
The short answer is: If you drop the "free of charge" requirement you
can use LispWorks/CAPI which is cross-platform on Linux, Windows, Mac
OS X, and - I think - several commercial Unix implementations.
If you drop the Windows requirement (which you have to do anyway if
you want to use SBCL) you might want to take a look at
<http://www.cliki.net/Graphics%20Toolkit>.
If you can't drop any of your requirements then maybe you should help
the McCLIM hackers with a Windows port... :)
Edi.
PS: Oh, yes, and then there's "Cello" by Kenny Tilton which aims to
become what you're looking for but isn't yet:
<http://www.tilton-technology.com/cellophane.html>
Edi Weitz <···@agharta.de> writes:
> On 24 Feb 2004 12:25:30 +0100, Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> wrote:
>
> > I am looking for recomodations on GUI-tools. I need the following
> > features:
> >
> > - should run on multiple platforms (at least linux and windows) without
> > much code change.
> > - easy to build, preferably CLOS-alike
> > - free of charge
> >
> > I prefer working in SBCL.
>
> This is asked here every two weeks or so. You might want to search
> Google Groups.
Yeh, I have seen similiar discussions before. The answer below, however,
is a lot more descriptive than anything I've found earlier. Thanks.
> The short answer is: If you drop the "free of charge" requirement you
> can use LispWorks/CAPI which is cross-platform on Linux, Windows, Mac
> OS X, and - I think - several commercial Unix implementations.
>
> If you drop the Windows requirement (which you have to do anyway if
> you want to use SBCL) you might want to take a look at
>
> <http://www.cliki.net/Graphics%20Toolkit>.
>
> If you can't drop any of your requirements then maybe you should help
> the McCLIM hackers with a Windows port... :)
I've had a look at McCLIM earlier, and I like the idea of making a free
version of such a widespread standard. It seems, though, that it is quite
limited (does not support all CLIM features). Anyway, my windows knowledge
is quite limited when it comes to stuff like that.
Garnet seems easy to use and is old enough to provide stability.
> PS: Oh, yes, and then there's "Cello" by Kenny Tilton which aims to
> become what you're looking for but isn't yet:
>
> <http://www.tilton-technology.com/cellophane.html>
Hm. Very interesting indeed. I think I will keep an eye on this one for
later (whenever I have time to look into it).
Thanks for the suggestions.
--
Oyvin
Oyvin Halfdan Thuv wrote:
>>PS: Oh, yes, and then there's "Cello" by Kenny Tilton which aims to
>> become what you're looking for but isn't yet:
>>
>> <http://www.tilton-technology.com/cellophane.html>
>
>
> Hm. Very interesting indeed. I think I will keep an eye on this one for
> later (whenever I have time to look into it).
Ah, the Lispnik credo in a nutshell: wait for the Open Source Fairy to
leave a library under your pillow.
:)
kenny
ps. actually, I have been swamped by porters, but if you know anything
about (and AllegroCL Linux-shared-libraries), we're all ears.
kt
pps. Garnet must be great. They killed it and it won't die. Good choice
until the OSF comes.
k
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On 2004-02-24 21:38:55, Kenny Tilton wrote:
> Ah, the Lispnik credo in a nutshell: wait for the Open Source Fairy to
> leave a library under your pillow.
There must be a "Piss newbies off because that makes them harder!"
credo, too.
Stefan Scholl wrote:
> On 2004-02-24 21:38:55, Kenny Tilton wrote:
>
>>Ah, the Lispnik credo in a nutshell: wait for the Open Source Fairy to
>>leave a library under your pillow.
>
>
> There must be a "Piss newbies off because that makes them harder!"
> credo, too.
Stefan, you ignorant slut. /I/ am the newby hugger, not you. Hence the
smiley you deliberately deleted so you could pose as their champion.
Shut up and go write an open source interface between Lisp and
Supercollider. Or do I have to do everything around here?
:)
peace, love, and synthDefs,
kenny, The Open Source GUI Fairy*
* Franz tech support copped a plea to not doing well with shared libs
named, say, "FTGL.so.1". The lib now loads and the Cello rover is on its
way again.
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Oyvin Halfdan Thuv wrote:
>
> >>PS: Oh, yes, and then there's "Cello" by Kenny Tilton which aims to
> >> become what you're looking for but isn't yet:
> >>
> >> <http://www.tilton-technology.com/cellophane.html>
> > Hm. Very interesting indeed. I think I will keep an eye on this one
> > for
> > later (whenever I have time to look into it).
>
> Ah, the Lispnik credo in a nutshell: wait for the Open Source Fairy to
> leave a library under your pillow.
OK. OK. I'll give it a go (garnet seemed more outdated than stable when reading
a bit about it).
I don't have much time as I said, but I can always test i on Linux and FreeBSD
(probably done already). I also have access to AllegroCL on Solaris (and
Windows).
--
Oyvin
Oyvin Halfdan Thuv wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Oyvin Halfdan Thuv wrote:
>>
>>
>>>>PS: Oh, yes, and then there's "Cello" by Kenny Tilton which aims to
>>>> become what you're looking for but isn't yet:
>>>>
>>>> <http://www.tilton-technology.com/cellophane.html>
>>>
>>>Hm. Very interesting indeed. I think I will keep an eye on this one
>>>for
>>>later (whenever I have time to look into it).
>>
>>Ah, the Lispnik credo in a nutshell: wait for the Open Source Fairy to
>>leave a library under your pillow.
>
>
> OK. OK. I'll give it a go
Fantastic.
(garnet seemed more outdated than stable when reading
> a bit about it).
I guess one problem even Garnetites concede is the disconnect with CLOS.
>
> I don't have much time as I said, but I can always test i on Linux and FreeBSD
> (probably done already).
The Open Source Fairy is in da house: Linux, yes (as of a few hours
ago). FreeBSD not yet in the bag.
I also have access to AllegroCL on Solaris (and
> Windows).
Good choice. The Linux port was done with AllegroCL Trial.
Lispworks/win32 is in the bad as well. See more deets in a separate thread.
welcome aboard the cello juggernaut. :)
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Lispworks/win32 is in the bad as well.
That should be "in the bag", as in "working nicely". Lispworks has the
advantage of being less forgiving than AllegroCL, so it picks up certain
things ACL lets slide (only to cause later puzzles). So the Lispworks
port is a kind of software validation, QA step which /I think/ means
other Lisps will now fall in line.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On 25 Feb 2004 11:23:33 +0100, Oyvin Halfdan Thuv
<·····@remove.spam.oyvins.net> wrote:
My idea was to use UFFI to interface to the Gnome library.
Gnome should be a natural mach for lisp and the fact that it
is written in C ratner than C++ simplifies writing the interface.
Altso the library runs under both Unix/Linux and Windows.
I am currently creating a website for my book on lisp games.
For source and other tidbits look here.
I will keep you posted when it comes into operation.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> writes:
> I've had a look at McCLIM earlier, and I like the idea of making a free
> version of such a widespread standard.
Good.
> It seems, though, that it is quite
> limited (does not support all CLIM features).
To me it looks sufficiently close to supporting all CLIM features that
I would not call it "quite limited".
--
Robert Strandh