Re: GF/ST Cairo Backend
Locked
 
|
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]] 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----- 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]] Hi Stewart, Andrew McNeil mentioned you in connection with a similar question back in February, about my post from 2008: ----- 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]] 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----- 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 Dear Ken, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi Steve, Thanks for the zooming pointers. Nice refactoring – the beauty of blocks!. Time to get busy on the train… Cheers, Stewart -----Original Message----- 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]] 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----- 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]] Hi Stewart, Andrew McNeil mentioned you in connection with a similar
question back in February, about my post from 2008: ----- 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]] 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----- 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 Dear Ken, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |