Martin Flack | 3 Jun 2007 18:45

cells-gtk drawing-area widget

Hi all,

I'm writing some stock equities charting software in Common Lisp for my
own amusement and to learn the language. I'd like to start by porting
over a simple program I had in Perl to draw daily price bars. I used Tk
in Perl so I was planning to use LTK but cells-gtk caught my eye and
looks interesting.

I noticed the drawing.lisp is commented out in the asdf file - is anyone
actively using this widget in their code? I uncommented it and got it to
compile on SBCL.

Secondly, I can't seem to get the widget to come up. I lifted some
example code from Google, but something's wrong. What I'm trying is
below - what happens is the program runs fine but there is no graphic
element, just the text label and entry box.

Tk does offer a canvas widget which might be helpful to my application,
but I'm thinking that since the objects I'd want to handle will be
conceptually higher than lines, rectangles, etc. that I could program my
own canvas-type abstraction anyway.

Any comments would be appreciated. Thanks! ;-)

Martin

(require :cells)
(require :cells-gtk)

(defpackage hello-world
(Continue reading)

Peter Denno | 4 Jun 2007 14:02
Favicon

Re: cells-gtk drawing-area widget

On Sunday 03 June 2007 12:45, Martin Flack wrote:
> Hi all,
>
> I'm writing some stock equities charting software in Common Lisp
> for my own amusement and to learn the language. I'd like to start
> by porting over a simple program I had in Perl to draw daily price
> bars. I used Tk in Perl so I was planning to use LTK but cells-gtk
> caught my eye and looks interesting.
>
> I noticed the drawing.lisp is commented out in the asdf file - is
> anyone actively using this widget in their code? I uncommented it
> and got it to compile on SBCL.

I wrote it, but I'm not using it yet. 
>
> Secondly, I can't seem to get the widget to come up. I lifted some
> example code from Google, but something's wrong. What I'm trying is
> below - what happens is the program runs fine but there is no
> graphic element, just the text label and entry box.
>
> Tk does offer a canvas widget which might be helpful to my
> application, but I'm thinking that since the objects I'd want to
> handle will be conceptually higher than lines, rectangles, etc.
> that I could program my own canvas-type abstraction anyway.
>
> Any comments would be appreciated. Thanks! ;-)

I've got a paper due today, so I can't comment now, but I did get 
things to work. I had some ideas for the design of this thing that 
I'll try to recall. Tomorrow.
(Continue reading)

Peter Hildebrandt | 4 Jun 2007 22:39
Picon

Re: cells-gtk drawing-area widget

On Mon, 04 Jun 2007 05:02:57 -0700, Peter Denno <peter.denno <at> nist.gov>  
wrote:

> On Sunday 03 June 2007 12:45, Martin Flack wrote:
>> Hi all,
>>
>> I'm writing some stock equities charting software in Common Lisp
>> for my own amusement and to learn the language. I'd like to start
>> by porting over a simple program I had in Perl to draw daily price
>> bars. I used Tk in Perl so I was planning to use LTK but cells-gtk
>> caught my eye and looks interesting.
>>
>> I noticed the drawing.lisp is commented out in the asdf file - is
>> anyone actively using this widget in their code? I uncommented it
>> and got it to compile on SBCL.
>
> I wrote it, but I'm not using it yet.

I am in a similar situation, so if you guys would like to collaborate on  
the issue, that'd be great.

I'm writing a little GUI app as a frontend for my research project.  I  
really like the way cells-gtk works, but I miss the drawing-area widget.

My approach so far is based on Cairo (exporting the graphs to svg or  
postscript would be awesome, given I'd like to use them in a paper).

I started with Warren Wilkinson's patch (posted here on May 22):

http://www3.telus.net/public/thomasw2/dl/cells-gtk-cairo-patch.diff
(Continue reading)

Martin Flack | 10 Jun 2007 06:56

Re: cells-gtk drawing-area widget

Hi guys,

I've managed to get cells-gtk drawing-area to basically work. I'm
attaching the diff. A few notes follow.

In drawing.lisp I shuffled some stuff around and used the double colon
package selector to get it find all the symbols on first load. There may
be a slightly cleaner way to do this.

I fixed a bug where *window* was not bound on first run and caused an
error, but would be ok on later runs in the same Lisp image.

I made button1-down, button2-down, and button3-down all cells so that
you can use them as inputs in the cells-gtk framework.

For the future, I suspect that drawing-expose-event-handler could
probably be simpler and not call init-graphics-context each time? Also
drawing-pointer-motion-handler produces an effect but probably not quite
what was intended (the image is moved while you hold down the button,
but excess areas are not cleaned so it looks slurred along, and
subsequent tries move it from 0,0 again).

I'm on SBCL on Ubuntu 7.04.

Martin Flack

Hi guys,
(Continue reading)

Peter Denno | 12 Jun 2007 16:16
Favicon

Re: cells-gtk drawing-area widget

On Sunday 10 June 2007 00:56, Martin Flack wrote:
> Hi guys,

Hi, Martin.
>
> I've managed to get cells-gtk drawing-area to basically work. I'm
> attaching the diff. A few notes follow.
>
> In drawing.lisp I shuffled some stuff around and used the double
> colon package selector to get it find all the symbols on first
> load. There may be a slightly cleaner way to do this.

Probably just exporting them from wherever they are would be fine. 
>
> I fixed a bug where *window* was not bound on first run and caused
> an error, but would be ok on later runs in the same Lisp image.
>
> I made button1-down, button2-down, and button3-down all cells so
> that you can use them as inputs in the cells-gtk framework.
>
> For the future, I suspect that drawing-expose-event-handler could
> probably be simpler and not call init-graphics-context each time?
> Also drawing-pointer-motion-handler produces an effect but probably
> not quite what was intended (the image is moved while you hold down
> the button, but excess areas are not cleaned so it looks slurred
> along, and subsequent tries move it from 0,0 again).

I don't recall any problems like that.

>
(Continue reading)

Peter Hildebrandt | 12 Jun 2007 17:36
Picon

Re: cells-gtk drawing-area widget


Hi Martin, Hi Peter,

I'm afraid we're duplicating work here.

On Tue, 12 Jun 2007 07:16:21 -0700, Peter Denno <peter.denno <at> nist.gov>  
wrote:
> On Sunday 10 June 2007 00:56, Martin Flack wrote:
>> Hi guys,
>
> Hi, Martin.
>>
>> I've managed to get cells-gtk drawing-area to basically work. I'm
>> attaching the diff. A few notes follow.

I'm still working on it, creating a cells-like interface to cairo.

>>
>> In drawing.lisp I shuffled some stuff around and used the double
>> colon package selector to get it find all the symbols on first
>> load. There may be a slightly cleaner way to do this.
>
> Probably just exporting them from wherever they are would be fine.
>>
>> I fixed a bug where *window* was not bound on first run and caused
>> an error, but would be ok on later runs in the same Lisp image.
>>
>> I made button1-down, button2-down, and button3-down all cells so
>> that you can use them as inputs in the cells-gtk framework.

(Continue reading)

Martin Flack | 24 Jun 2007 23:41

Re: cells-gtk drawing-area widget

Hi Peter (D) & Peter (H),

Thanks for the replies.

The cairo direction sounds good. It's probably more than I need for my
pet projects, but don't let me discourage you. I think I just need basic
shapes on the screen.

It seems conceptually we're moving towards more of a "canvas" type
object. I wonder at what point we separate the drawing object and the
canvas object that builds upon it, if at all. (I don't suppose wrapping
the Gnome Canvas for CL would be easier?)

One thing I would like to see is layers, like gimp and photoshop. So
possibly the :kids could optionally consist of layer objects that
have :kids of their own. Then you could assign objects onto the layers
and they appear in the correct stacking order, and you can show/hide
layers as a whole, etc. Also I'd like to experiment with each layer
having an optional coordinate translation function.

Martin


Gmane