Re: GF/ST Cairo Backend

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: GF/ST Cairo Backend

Steven Kelly
Re: [vwnc] Anything like Ned Konz's Connectors in VW?

Hi Stewart,

 

I think zooming should work just by setting the scale in the graphics context: the Cairoized primDisplay* methods already use it (apart from arcs, for some reason). In our code we have that factored slightly differently, to avoid duplicating the “scale ifTrue:ifFalse:” code in every primDisplay* method, and to keep the scale value easily available in the actual drawing code.

 

primDisplayLineFrom: startPoint to: endPoint

                | offset |

                offset := self cairoOffset.

                self cairoScaledDo: [:cr :blockScale |

                                cr 

                                                moveTo: startPoint * blockScale + offset;

                                                lineTo: endPoint * blockScale + offset;

                                                stroke]

 

cairoScaledDo: drawBlock

                scale

                                ifTrue:   [self scaledDo: [:blockScale | self newCairoContextWhile: [:cr | drawBlock value: cr value: blockScale]]]

                                ifFalse:  [self newCairoContextWhile: [:cr | drawBlock value: cr value: 1]]

 

cairoOffset

                "Makes one pixel wide lines appear as a single full-on pixel wide, rather than being two half-on pixels wide. Change to return 0@0 if you prefer the softer looking and graphically more accurate two half-on pixels"

               

                ^(self lineWidth isZero or: [self lineWidth odd])

                                ifTrue: [0.5 @ 0.5]

                                ifFalse: [0 @ 0]

 

primDisplayArcBBoxOrigin: originPoint extent: extentPoint startAngle: startAngle sweepAngle: sweepAngle

                "Copyright (C) 1993-1996 Polymorphic Software, Inc.  All Rights Reserved"

                "Display an elliptical arc defined by the bounding rectangle of the

                ellipse and by the starting angle and angle of sweep for the arc. "

               

                self cairoScaledDo: [:cr :blockScale |

                                cr translate: (originPoint + extentPoint half) * blockScale + self cairoOffset.

                                cr saveWhile:

                                                [cr scale: extentPoint * blockScale.

                                                cr arcDegreeStart: startAngle sweep: sweepAngle center: 0 @ 0 radius: 0.5].

                                cr stroke]

 

In our later work, we’ve changed from passing a simple Point blockScale to passing a matrix transformation. That gets fairly complex though, and is pretty strongly intertwined with our use of GF/ST.

 

All the best,

Steve

 

From: Stewart MacLean [mailto:[hidden email]]
Sent: Monday, August 5, 2013 11:25 AM
To: Steven Kelly
Cc: 'McNeil, Andrew'; [hidden email]
Subject: RE: GF/ST Cairo Backend

 

Hi Steve,

 

I haven’t delved into Henrik’s code deeply, but I did try it on the organisational chart example, and it was a vast improvement. Still garish colours, but I should be able to incorporate the gradient rounded rectangles to get the “sheen”.

 

The only feature that didn’t work was zooming, which I believe should be possible using the matrix transformations in Cairo. I’d be grateful if you’ve got any suggestions as to how to approach this?

 

Nevertheless, this should be a huge help in getting me started towards a decent looking tree diagram UI.

 

Thanks for the suggestions.

 

Cheers,

 

Stewart

 

 

 

-----Original Message-----
From: Steven Kelly [[hidden email]]
Sent: 2 August 2013 2:33 a.m.
To: McNeil, Andrew; [hidden email]
Subject: RE: GF/ST Cairo Backend

 

Hi Andrew,

 

As I just wrote in a more detailed message to Stewart, I took a look at the “GFST Base Cairoized.zip” DropBox link posted by Henrik Johansen [[hidden email]] 30.7., and found it basically the same as our initial version. Since our work then diverged in ways that mostly aren’t useful to others, I suggested Stewart start with Henrik’s code.

 

All the best,

Steve

 

 

From: Steven Kelly [[hidden email]]
Sent: Friday, 26 July 2013 3:43 AM
To: [hidden email]
Cc: McNeil, Andrew
Subject: RE: GF/ST Cairo Backend

 

Hi Stewart,

 

Andrew McNeil mentioned you in connection with a similar question back in February, about my post from 2008:
http://comments.gmane.org/gmane.comp.lang.smalltalk.vwnc/15836
I answered:

-----

Oh dear. I appear to have provisionally promised to publish that, and then let the timetable slip a little - 5 years! The problem is our other GF/ST changes, which are extensive. GF/ST without them is basically pretty unusable by today's standards (unless Cincom have done something major to GF/ST since VW 7.7.1).

 

However, most of the worst bits of the unaltered GF/ST were in responding to input. There's thus some hope that our "Cairoized GF/ST" package wouldn't need much integration, i.e. would work with stock Cairo and GF/ST, since it's only concerned with drawing.

 

...

 

All the best,

Steve

 


From: Stewart MacLean [[hidden email]]
Sent: Thu 25/07/2013 11:03
To: Steven Kelly
Subject: GF/ST Cairo Backend

Hi Steve,

 

Not sure if you recall, but I found a message from years back that you where going to make your Cairo backend for GF/ST available?

 

Since then I’ve been round the houses and got some familiarity with Cairo via various examples and packages.

 

I’ve come back to GF/ST as this seems like a solid framework that has evolved over the years and stood the test of time. I’m still figuring out how to plug in the CairoContext, which I think equates to aPen in the GF/ST VSE code.

 

...

 

I was wondering if you would consider releasing the code for your Cairo backend, in some form or another that could help get me started? (still remembering a lesson in computer science in the days of punched cards which was – “has somebody else done this?” J).

 

Thanks,

Stewart

 

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Steven Kelly
Sent: 24 July 2013 5:21 p.m.
To: Ken G. Brown
Cc: VW NC
Subject: Re: [vwnc] Anything like Ned Konz's Connectors in VW?

 

You might also want to look at GF/ST. We use it in MetaEdit+, where we've also added a Cairo backend.

 

All the best,

Steve

 


From: [hidden email] on behalf of Niall Ross
Sent: Wed 24/07/2013 00:13
To: Ken G. Brown
Cc: VW NC
Subject: Re: [vwnc] Anything like Ned Konz's Connectors in VW?

Dear Ken,

>Is there anything like Ned Konz's Connectors in VW?
><http://squeak.pbworks.com/w/page/10713913/Connector%20Tutorial>

>

Depends how like is like.  Is HotDraw like enough?  At the other
extreme, David Buck's ElastoLab (http://simberon.com/elastolab.htm) may
be far beyond what you want.

             Yours faithfully
                   Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: GF/ST Cairo Backend

Stew MacLean
Re: [vwnc] Anything like Ned Konz's Connectors in VW?

Hi Steve,

 

Thanks for the zooming pointers. Nice refactoring – the beauty of blocks!.

 

Time to get busy on the train…

 

Cheers,

 

Stewart

 

-----Original Message-----
From: Steven Kelly [mailto:[hidden email]]
Sent: 6 August 2013 12:03 a.m.
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: RE: GF/ST Cairo Backend

 

Hi Stewart,

 

I think zooming should work just by setting the scale in the graphics context: the Cairoized primDisplay* methods already use it (apart from arcs, for some reason). In our code we have that factored slightly differently, to avoid duplicating the “scale ifTrue:ifFalse:” code in every primDisplay* method, and to keep the scale value easily available in the actual drawing code.

 

primDisplayLineFrom: startPoint to: endPoint

                | offset |

                offset := self cairoOffset.

                self cairoScaledDo: [:cr :blockScale |

                                cr 

                                                moveTo: startPoint * blockScale + offset;

                                                lineTo: endPoint * blockScale + offset;

                                                stroke]

 

cairoScaledDo: drawBlock

                scale

                                ifTrue:   [self scaledDo: [:blockScale | self newCairoContextWhile: [:cr | drawBlock value: cr value: blockScale]]]

                                ifFalse:  [self newCairoContextWhile: [:cr | drawBlock value: cr value: 1]]

 

cairoOffset

                "Makes one pixel wide lines appear as a single full-on pixel wide, rather than being two half-on pixels wide. Change to return 0@0 if you prefer the softer looking and graphically more accurate two half-on pixels"

               

                ^(self lineWidth isZero or: [self lineWidth odd])

                                ifTrue: [0.5 @ 0.5]

                                ifFalse: [0 @ 0]

 

primDisplayArcBBoxOrigin: originPoint extent: extentPoint startAngle: startAngle sweepAngle: sweepAngle

                "Copyright (C) 1993-1996 Polymorphic Software, Inc.  All Rights Reserved"

                "Display an elliptical arc defined by the bounding rectangle of the

                ellipse and by the starting angle and angle of sweep for the arc. "

               

                self cairoScaledDo: [:cr :blockScale |

                                cr translate: (originPoint + extentPoint half) * blockScale + self cairoOffset.

                                cr saveWhile:

                                                [cr scale: extentPoint * blockScale.

                                                cr arcDegreeStart: startAngle sweep: sweepAngle center: 0 @ 0 radius: 0.5].

                                cr stroke]

 

In our later work, we’ve changed from passing a simple Point blockScale to passing a matrix transformation. That gets fairly complex though, and is pretty strongly intertwined with our use of GF/ST.

 

All the best,

Steve

 

From: Stewart MacLean [mailto:[hidden email]]
Sent: Monday, August 5, 2013 11:25 AM
To: Steven Kelly
Cc: 'McNeil, Andrew'; [hidden email]
Subject: RE: GF/ST Cairo Backend

 

Hi Steve,

 

I haven’t delved into Henrik’s code deeply, but I did try it on the organisational chart example, and it was a vast improvement. Still garish colours, but I should be able to incorporate the gradient rounded rectangles to get the “sheen”.

 

The only feature that didn’t work was zooming, which I believe should be possible using the matrix transformations in Cairo. I’d be grateful if you’ve got any suggestions as to how to approach this?

 

Nevertheless, this should be a huge help in getting me started towards a decent looking tree diagram UI.

 

Thanks for the suggestions.

 

Cheers,

 

Stewart

 

 

 

-----Original Message-----
From: Steven Kelly [[hidden email]]
Sent: 2 August 2013 2:33 a.m.
To: McNeil, Andrew; [hidden email]
Subject: RE: GF/ST Cairo Backend

 

Hi Andrew,

 

As I just wrote in a more detailed message to Stewart, I took a look at the “GFST Base Cairoized.zip” DropBox link posted by Henrik Johansen [[hidden email]] 30.7., and found it basically the same as our initial version. Since our work then diverged in ways that mostly aren’t useful to others, I suggested Stewart start with Henrik’s code.

 

All the best,

Steve

 

 

From: Steven Kelly [[hidden email]]
Sent: Friday, 26 July 2013 3:43 AM
To: [hidden email]
Cc: McNeil, Andrew
Subject: RE: GF/ST Cairo Backend

 

Hi Stewart,

 

Andrew McNeil mentioned you in connection with a similar question back in February, about my post from 2008:
http://comments.gmane.org/gmane.comp.lang.smalltalk.vwnc/15836
I answered:

-----

Oh dear. I appear to have provisionally promised to publish that, and then let the timetable slip a little - 5 years! The problem is our other GF/ST changes, which are extensive. GF/ST without them is basically pretty unusable by today's standards (unless Cincom have done something major to GF/ST since VW 7.7.1).

 

However, most of the worst bits of the unaltered GF/ST were in responding to input. There's thus some hope that our "Cairoized GF/ST" package wouldn't need much integration, i.e. would work with stock Cairo and GF/ST, since it's only concerned with drawing.

 

...

 

All the best,

Steve

 


From: Stewart MacLean [[hidden email]]
Sent: Thu 25/07/2013 11:03
To: Steven Kelly
Subject: GF/ST Cairo Backend

Hi Steve,

 

Not sure if you recall, but I found a message from years back that you where going to make your Cairo backend for GF/ST available?

 

Since then I’ve been round the houses and got some familiarity with Cairo via various examples and packages.

 

I’ve come back to GF/ST as this seems like a solid framework that has evolved over the years and stood the test of time. I’m still figuring out how to plug in the CairoContext, which I think equates to aPen in the GF/ST VSE code.

 

...

 

I was wondering if you would consider releasing the code for your Cairo backend, in some form or another that could help get me started? (still remembering a lesson in computer science in the days of punched cards which was – “has somebody else done this?” J).

 

Thanks,

Stewart

 

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of Steven Kelly
Sent: 24 July 2013 5:21 p.m.
To: Ken G. Brown
Cc: VW NC
Subject: Re: [vwnc] Anything like Ned Konz's Connectors in VW?

 

You might also want to look at GF/ST. We use it in MetaEdit+, where we've also added a Cairo backend.

 

All the best,

Steve

 


From: [hidden email] on behalf of Niall Ross
Sent: Wed 24/07/2013 00:13
To: Ken G. Brown
Cc: VW NC
Subject: Re: [vwnc] Anything like Ned Konz's Connectors in VW?

Dear Ken,

>Is there anything like Ned Konz's Connectors in VW?
><http://squeak.pbworks.com/w/page/10713913/Connector%20Tutorial>

>

Depends how like is like.  Is HotDraw like enough?  At the other
extreme, David Buck's ElastoLab (http://simberon.com/elastolab.htm) may
be far beyond what you want.

             Yours faithfully
                   Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc