Several weeks ago, I registered a new project at common-lisp.net
called Graphic-Forms to implement a UI library for Windows in
Common Lisp. I'm just about ready to release the first pre-alpha
version. With recent postings regarding cool work that other folks
are doing, I couldn't resist posting a link to some screenshots
of my own:
https://sourceforge.net/project/screenshots.php?group_id=163034
The main project page for Graphic-Forms is:
http://common-lisp.net/project/graphic-forms/
--
Jack Unrue
Looks great but i can't get the subversion, my firewall don't like cvs
external,
could, you tar/zip a version that could be download without going by
cvs call.
// Anders
From: Ken Tilton
Subject: Re: Graphic-Forms screenshots
Date:
Message-ID: <iGyTf.6$Sr5.2@fe10.lga>
AndersPE wrote:
> Looks great but i can't get the subversion, my firewall don't like cvs
> external,
> could, you tar/zip a version that could be download without going by
> cvs call.
> // Anders
>
Look for the download link in the list to the top right here:
http://common-lisp.net/project/graphic-forms/
And folks, any c-l.net cvs repository node has a "download tarball" link
at the bottom of the page when using ViewCVS (which c-l.net offers when
you come in at the top and choose "View repositories" or whatever that
link is.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
On 20 Mar 2006 02:25:30 -0800, "AndersPE" <················@telia.com> wrote:
>
> Looks great but i can't get the subversion, my firewall don't like cvs
> external,
> could, you tar/zip a version that could be download without going by
> cvs call.
> // Anders
Hi, Anders. In addition to what Ken wrote, I intend to make the
first release available in the near future, at which point you'll
be able to download from SourceForge as well.
--
Jack Unrue
On Mon, 20 Mar 2006 06:44:19 GMT, Jack Unrue <·······@example.tld> wrote:
>
> https://sourceforge.net/project/screenshots.php?group_id=163034
>
Sorry about that, I shouldn't copy/paste links when logged into
my account.
http://sourceforge.net/project/screenshots.php?group_id=163034
--
Jack Unrue
From: Ken Tilton
Subject: Re: Graphic-Forms screenshots
Date:
Message-ID: <FlzTf.2$GW3.1@fe11.lga>
Jack Unrue wrote:
> Several weeks ago, I registered a new project at common-lisp.net
> called Graphic-Forms to implement a UI library for Windows in
> Common Lisp. I'm just about ready to release the first pre-alpha
> version. With recent postings regarding cool work that other folks
> are doing, I couldn't resist posting a link to some screenshots
> of my own:
>
> https://sourceforge.net/project/screenshots.php?group_id=163034
>
> The main project page for Graphic-Forms is:
>
> http://common-lisp.net/project/graphic-forms/
>
There it says:
"Why implement another UI toolkit? The niche for Graphic-Forms is that
it emphasizes the use of Windows� features without comprising
functionality due to portability constraints. "
What compromises do you see in Cells-Gtk and LTk?
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Ken Tilton wrote:
> What compromises do you see in Cells-Gtk and LTk?
I'm not the author of the Graphi-Forms package, but I see one problem with
Gtk is that it doesn't use the native system widgets, so e.g. if you write
a business application with standard GUI controls like buttons, edit fields
etc., it doesn't look and feel like other Windows applications (which will
be even worse with new Windows versions, like Vista and "Aero Glass").
LTk uses native controls and it is easy to use, but at least I had problems
with the communication from Lisp to the LTk process: When trying to stream
large bitmaps for displaying, sometimes it timeouted at program start and
you don't get high framerates, if you want to implement games with it.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>What compromises do you see in Cells-Gtk and LTk?
>
>
> I'm not the author of the Graphi-Forms package, but I see one problem with
> Gtk is that it doesn't use the native system widgets, so e.g. if you write
> a business application with standard GUI controls like buttons, edit fields
> etc., it doesn't look and feel like other Windows applications
Oh, I thought Gtk was native on win32.
> (which will
> be even worse with new Windows versions, like Vista and "Aero Glass").
heh-heh, MS sure is trying to really once and for all take over the
universe with their increasing isolation. I wonder if the OpenGL
community is having any luck getting better support for that moving forward.
>
> LTk uses native controls and it is easy to use, but at least I had problems
> with the communication from Lisp to the LTk process: When trying to stream
> large bitmaps for displaying, sometimes it timeouted at program start and
> you don't get high framerates, if you want to implement games with it.
>
As I understand it, LTk will move to FFI when needed. Probably a high
frame-rate requirment would do that.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
On Mon, 20 Mar 2006 09:53:24 -0500, Ken Tilton <·········@gmail.com> wrote:
> >
> >
> > The main project page for Graphic-Forms is:
> >
> > http://common-lisp.net/project/graphic-forms/
> >
>
> There it says:
>
> "Why implement another UI toolkit? The niche for Graphic-Forms is that
> it emphasizes the use of Windows� features without comprising
> functionality due to portability constraints. "
>
> What compromises do you see in Cells-Gtk and LTk?
Well, first I'd say that Cells is a separate topic from Gtk,
and I don't have any issues with Cells -- I haven't tried it
(yet). And secondly, reasonable people can disagree about what
constitutes the right set of tradeoffs, and so I recognize that
there are lots of people out there for whom Gtk and LTk (and
the others) are just right. So my issues are purely from the
standpoint of wanting to write Windows apps in Lisp that
look and feel exactly right and take advantage of
platform-specific features.
As Frank mentioned, and as far as I can tell he's correct, the
controls aren't native. Using a Spy utility like Winspector,
you can see that controls are implemented using a window class
called gdkWindowChild and these do not have the usual Win32
style flags. And so there are various details about controls
that are wrong. For instance, the drop-down behavior for
combo boxes is clearly not native (the position and width of
the dropdown component is wrong from a native Win32 standpoint).
Listboxes appear to be aggregates of gdkWindowChild as well.
The two Gtk-based apps that I've evaluated (Gimp and Gaim)
have look-and-feel issues. For example, one would normally
subclass the common file dialog to provide extra features
like the preview and pre-defined folder structure, but Gimp
has what looks like a variation of the Gtk file dialog.
Other dialogs appear to all be based on the GdkWindowToplevel
window class and they have a frame window style rather than
the expected dialog style, and while one can consciously
decide not to use modal dialogs, the problem I have with
these dialogs is that they don't get the ownership hierarchy
right, so they aren't modeless dialogs either.
Extending Gtk means writing C code, whereas I would prefer
to stay in Lisp. This is actually a subtle issue, though,
which could be a separate discussion.
The last time I evaluated Tk on Windows, there was a promising
set of extensions being developed that really improves on the
look-and-feel, because the standard Tk l-n-f is not acceptable
(again, that's coming from someone who is picky about l-n-f
issues on Windows, not a general value judgement). Extending
LTk is a matter of writing in Tcl/Tk, so again there is an
issue of what language am I writing code in. Also, my perception
has been that performance of drawing operations suffers a bit,
although I admit to not having hard numbers at this point. And
finally, I have experimented with LTk a couple times and have
seen the demo app hang.
Also, LTk and Foil are examples of an integration strategy that
I don't personally agree with for UI code -- I think the path
between application code and the GUI should be as fast and short
as possible, and not have complications like I/O and
parsing/interpretation. BTW, I know all about the X Window
client/server model and I'm not lumping that in with this
particular issue because that is a different ball of wax.
Writing portable UI toolkits is necessarily an exercise
in tradeoffs. I know because in the past I worked on a
commercial portable toolkit, and I've used quite a few
(more modern) libraries since then.
I'd rather have a library that integrated tightly with
Windows, where extending the library is done directly
in terms of Windows features and APIs.
--
Jack Unrue
Jack Unrue wrote:
> On Mon, 20 Mar 2006 09:53:24 -0500, Ken Tilton <·········@gmail.com> wrote:
>
>>>
>>>The main project page for Graphic-Forms is:
>>>
>>>http://common-lisp.net/project/graphic-forms/
>>>
>>
>>There it says:
>>
>>"Why implement another UI toolkit? The niche for Graphic-Forms is that
>>it emphasizes the use of Windows� features without comprising
>>functionality due to portability constraints. "
>>
>>What compromises do you see in Cells-Gtk and LTk?
>
>
> Well, first I'd say that Cells is a separate topic from Gtk,
Yes, I almost said just "Gtk" but decided it was better to refer to the
Lisp wrapper than the C library since that would be the alternative.
> As Frank mentioned, and as far as I can tell he's correct, the
> controls aren't native. Using a Spy utility like Winspector,
> you can see that controls are implemented using a window class
> called gdkWindowChild and these do not have the usual Win32
> style flags.
OK, maybe when I heard it was native they meant it was a little native. :)
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
On Mon, 20 Mar 2006 14:18:59 -0500, Ken Tilton <·········@gmail.com> wrote:
> Jack Unrue wrote:
> > On Mon, 20 Mar 2006 09:53:24 -0500, Ken Tilton <·········@gmail.com> wrote:
> >
> > >
> > > What compromises do you see in Cells-Gtk and LTk?
> >
> >
> > Well, first I'd say that Cells is a separate topic from Gtk,
>
> Yes, I almost said just "Gtk" but decided it was better to refer to the
> Lisp wrapper than the C library since that would be the alternative.
No problem...and I didn't mean it to come across the wrong
way. I totally respect your work on Cells. I just haven't had
time yet to really investigate, and if I were to start working
on a Graphic-Forms port for Cells (if that made sense), the first
places I'd look for guidance on how to do that are the Cells-xxx
UI libraries.
--
Jack Unrue
Jack Unrue wrote:
> On Mon, 20 Mar 2006 14:18:59 -0500, Ken Tilton <·········@gmail.com> wrote:
>
>>Jack Unrue wrote:
>>
>>>On Mon, 20 Mar 2006 09:53:24 -0500, Ken Tilton <·········@gmail.com> wrote:
>>>
>>>
>>>>What compromises do you see in Cells-Gtk and LTk?
>>>
>>>
>>>Well, first I'd say that Cells is a separate topic from Gtk,
>>
>>Yes, I almost said just "Gtk" but decided it was better to refer to the
>>Lisp wrapper than the C library since that would be the alternative.
>
>
> No problem...and I didn't mean it to come across the wrong
> way. I totally respect your work on Cells. I just haven't had
> time yet to really investigate, and if I were to start working
> on a Graphic-Forms port for Cells (if that made sense), the first
> places I'd look for guidance on how to do that are the Cells-xxx
> UI libraries.
>
Back in the day I did get Cells working with native win32 widgets. It
was a bit of an effort because my GUIs are more dynamic than average,
including widgets moving around from time to time. It took a bit of
doing to prevent all sorts of unpleasant flashing as I told widgets to
move. I /think/ I got it to work but then decided not to use native
widgets because they were not buying me anything.
I suppose if one is not into dancing widgets, Cells would bolt on a lot
more easily. :)
Right now I am working on Celtk (+ Cells Ltk). I have my own demo, but
now I am working on doing the standard Ltk demo in Celtk to give those
interested in using Celtk a before-after translation to help them
understand how a declarative GUI works. If you end up with a similar
demo for your package I might do the same for that.
So where on earth did you get the name Graphic-Forms? :)
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Vagif Verdi wrote:
> If you are working with Lispworks, can you marry CAPI and Cells the way
> you did it with Gtk ?
>
(a) I use AllegroCL.
(b) Without even looking I am sure Cells and CAPI could be made to work
together. I have driven Mac OS9 native widgets with cells, then
AllegroCL Common Graphics widgets. OpenGL turned out to be the best fit
of all (at the graphics level, of course I had to roll my own widgets
(but I had done that on win32 as well using just GDI).
(c) It will not be like the marriage of Cells with Gtk or LTk. In those
cases, there is an entire C framework to drive. And live with.
Cells-powered classes mirror C classes. It is all a lot harder. Tk
especially is a PITA. Hell, I had to add a whole new mechanism to Cells
just to deal with limitations in Tk, and it still was enough. A scroller
widget simply could not be built without an un-Cellsy kludge.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
On Mon, 20 Mar 2006 15:40:57 -0500, Ken Tilton <·········@gmail.com> wrote:
>
> Back in the day I did get Cells working with native win32 widgets. It
> was a bit of an effort because my GUIs are more dynamic than average,
> including widgets moving around from time to time. It took a bit of
> doing to prevent all sorts of unpleasant flashing as I told widgets to
> move. I /think/ I got it to work but then decided not to use native
> widgets because they were not buying me anything.
>
> I suppose if one is not into dancing widgets, Cells would bolt on a lot
> more easily. :)
I need to start finding testcases to port to GF that are really
demanding re: dynamic controls/child window geometry, so I can make
my layout managers robust (I only have one right now but plan to
add more).
> Right now I am working on Celtk (+ Cells Ltk). I have my own demo, but
> now I am working on doing the standard Ltk demo in Celtk to give those
> interested in using Celtk a before-after translation to help them
> understand how a declarative GUI works. If you end up with a similar
> demo for your package I might do the same for that.
Cool. Yep, I'm planning to have at least one fancy demo.
> So where on earth did you get the name Graphic-Forms? :)
My weak justification is that it incorporates "graphical"
and "forms" as in "Lisp forms". Plus it lends itself to
extension, like if I ported to Cells then maybe the project
would be called Graphic-Cells? Hmm...that might be too clunky.
So probably the only redeeming aspect is that I didn't turn up
any existing uses of that name when I searched SourceForge,
CLiki, clnet, Amazon, google, etc :-)
--
Jack Unrue
Jack Unrue wrote:
> On Mon, 20 Mar 2006 15:40:57 -0500, Ken Tilton <·········@gmail.com> wrote:
>
>>Back in the day I did get Cells working with native win32 widgets. It
>>was a bit of an effort because my GUIs are more dynamic than average,
>>including widgets moving around from time to time. It took a bit of
>>doing to prevent all sorts of unpleasant flashing as I told widgets to
>>move. I /think/ I got it to work but then decided not to use native
>>widgets because they were not buying me anything.
>>
>>I suppose if one is not into dancing widgets, Cells would bolt on a lot
>>more easily. :)
>
>
> I need to start finding testcases to port to GF that are really
> demanding re: dynamic controls/child window geometry, so I can make
> my layout managers robust (I only have one right now but plan to
> add more).
Oh. Stop. :) I invented Cells to do layout management. It eliminates the
layout manager. I do have classes called stacks, rows, grids, but they
work via the same mechanism as anything else: rules on px, py (position
in parent coordinate system), ll, lt, lr, and lb (the four local
bounds). The stacks et al make use of a hack that lets a parent supply
rules for its kids. So the kids do not need to know they are in a stack.
This is a lot more powerful than the usual layout-manager approach (such
as the Tk pack and grid games) that make you learn their own little
language, while things like stacks show one can have the convenience at
the same time. Anyway...
>
>
>>Right now I am working on Celtk (+ Cells Ltk). I have my own demo, but
>>now I am working on doing the standard Ltk demo in Celtk to give those
>>interested in using Celtk a before-after translation to help them
>>understand how a declarative GUI works. If you end up with a similar
>>demo for your package I might do the same for that.
>
>
> Cool. Yep, I'm planning to have at least one fancy demo.
>
>
>>So where on earth did you get the name Graphic-Forms? :)
>
>
> My weak justification is that it incorporates "graphical"
> and "forms" as in "Lisp forms".
I like it.
> Plus it lends itself to
> extension, like if I ported to Cells then maybe the project
> would be called Graphic-Cells?
That is why I asked. I cannot think of anything cute to with (+
Graphic-Forms Cells). :) GFCells?
Well, with LTk I used just its core capabilities, not the whole
framework. Cells and the full LTk got into a fight over the accessors.
Won't know about GF till I see it.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
On Mon, 20 Mar 2006 17:17:21 -0500, Ken Tilton <·········@gmail.com> wrote:
>
> Oh. Stop. :) I invented Cells to do layout management. It eliminates the
> layout manager. I do have classes called stacks, rows, grids, but they
> work via the same mechanism as anything else: rules on px, py (position
> in parent coordinate system), ll, lt, lr, and lb (the four local
> bounds). The stacks et al make use of a hack that lets a parent supply
> rules for its kids. So the kids do not need to know they are in a stack.
I promise I will take a thorough look at this (after I get 0.2.0
released). My layout management design is somewhat influenced by
my experience using SWT layouts (and to a lesser extent Swing's),
and since that's a model that some non-Lisp folks are already familiar
with, I was initially inclined to try to maintain a certain degree
of resemblance.
But we'll see. More thought needed, etc.
--
Jack Unrue
> Back in the day I did get Cells working with native win32 widgets. It
> was a bit of an effort because my GUIs are more dynamic than average,
> including widgets moving around from time to time. It took a bit of
> doing to prevent all sorts of unpleasant flashing as I told widgets to
> move. I /think/ I got it to work but then decided not to use native
> widgets because they were not buying me anything.
>
> I suppose if one is not into dancing widgets, Cells would bolt on a lot
> more easily. :)
>
> Right now I am working on Celtk (+ Cells Ltk). I have my own demo, but
> now I am working on doing the standard Ltk demo in Celtk to give those
> interested in using Celtk a before-after translation to help them
> understand how a declarative GUI works. If you end up with a similar
> demo for your package I might do the same for that.
Wouldn't it be best to have some generic Cells-Windowing framework that
supports multiple backends like (g)tk, native windows for differents OS
and so on? I have no idea about how much backend-specific stuff you
would lose by a common interface - it it's too much one could think of a
common part and still the ability to write specific code..
I think the McClim guys try to go this way, but I don't know how
successful they are with this.
Benjamin
Benjamin Teuber wrote:
>> Back in the day I did get Cells working with native win32 widgets. It
>> was a bit of an effort because my GUIs are more dynamic than average,
>> including widgets moving around from time to time. It took a bit of
>> doing to prevent all sorts of unpleasant flashing as I told widgets to
>> move. I /think/ I got it to work but then decided not to use native
>> widgets because they were not buying me anything.
>>
>> I suppose if one is not into dancing widgets, Cells would bolt on a
>> lot more easily. :)
>>
>> Right now I am working on Celtk (+ Cells Ltk). I have my own demo, but
>> now I am working on doing the standard Ltk demo in Celtk to give those
>> interested in using Celtk a before-after translation to help them
>> understand how a declarative GUI works. If you end up with a similar
>> demo for your package I might do the same for that.
>
>
> Wouldn't it be best to have some generic Cells-Windowing framework that
> supports multiple backends like (g)tk, native windows for differents OS
> and so on?
And so on being Common Graphics, CAPI, the MCL framework...
(a) if you are going to do the native OSes, you do not need to do the
frameworks built to be portable across the native OSes.
(b) doing the native OSes is a big job left as an exercise to the
reader. Piggybacking Celtk on Tk or Gtk is a nice sortcut.
(c) once you have a framework like Gtk or Tk, they are so hairy that
writing one project to use either would be harder than (b). (No, that is
not what McCLIM talks about.
> I have no idea about how much backend-specific stuff you
> would lose by a common interface - it it's too much one could think of a
> common part and still the ability to write specific code..
heh-heh, deeper and deeper we sink in this effort.
>
> I think the McClim guys try to go this way, but I don't know how
> successful they are with this.
Well, they do not run on 90% of the desktops out there, so that might be
one measure of their success. And you are actually thinking about McCLIM
talking about supporting multiple graphic backends such as OpenGL. That
is much more manageable than trying to sit atop multiple huge frameworks
each with their own event models, class hierarchies, etc etc.
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Since you are targeting windows platfor specificly. I have a question
for you.
Which lisp implementation ?
As far as I know there's no good lisp on windows.CLISP is not
multithreaded and SBCL is in process of proting, i.e. not stable.
I'm not counting commercial lisps because both Lispwork and ACL come
with their own GUI toolkits.
So what lisp do you use on windows ?
On 20 Mar 2006 16:05:03 -0800, "Vagif Verdi" <···········@gmail.com> wrote:
>
> Since you are targeting windows platfor specificly. I have a question
> for you.
> Which lisp implementation ?
> As far as I know there's no good lisp on windows.CLISP is not
> multithreaded and SBCL is in process of proting, i.e. not stable.
> I'm not counting commercial lisps because both Lispwork and ACL come
> with their own GUI toolkits.
>
> So what lisp do you use on windows ?
Hi Vagif. My intention is to support every Lisp on Windows that
CFFI supports (but I have to caution that this might yet turn
out to be unreasonable). So that would include open-source as well
as the commercial stuff. Right now I'm working with LispWorks
and CLISP, and would like to add Allegro next (no timetable on
that, though).
Corman Lisp is on my list too, but I'm slightly bothered by the
hoops you have to jump through to get ASDF working. I really need
to spend some quality time with Corman Lisp to decide where it
should ultimately be in terms of priority.
Actually, I think CLISP on Windows is great. If I could just
nail down some intermittent GPFs I'm seeing, I'd be very
pleased with CLISP (n.b., I have to assume these are my
bugs until I can prove otherwise).
I view threading as an application design choice (or requirement).
Graphic-Forms will be thread-agnostic -- not require thread
support but also not preclude their use. Win32 imposes some rules
about threads and event queues that I have to pay attention to. Also,
I need to get more knowledgeable about the LispWorks and Allegro
(and SBCL too?) threading models so that GF is thread-safe without
adding a whole bunch of unnecessary overhead.
--
Jack Unrue
On 20 Mar 2006 17:36:25 -0800, "Vagif Verdi" <···········@gmail.com> wrote:
>
> So you are developing on LispWorks. Good :)
> Can you give comparison of GF and CAPI ?
Nope :-) I mean, GF has a long way to go before it
would make sense to start doing comparisons like that.
If LispWorks decide in the next release to open-source
CAPI, I'll have to re-evaluate what I'm doing. But that
will always be important to do anyway.
> As far as I understand CAPI is windows native implementation too.
--
Jack Unrue