Just wondering if anyone would like to be able to use fill styles in borders (rather than just colours)...
Gary
Me :) Unification is good way!
2008/6/16 Gary Chambers gazzaguru2@btinternet.com:
Just wondering if anyone would like to be able to use fill styles in borders (rather than just colours)...
Gary
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Monday 16 June 2008 19:21:40 Gary Chambers wrote:
Just wondering if anyone would like to be able to use fill styles in borders (rather than just colours)...
I would like it. thanks alain
Gary
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
The lastest (version Pinesoft-Widgets-gvc.324) of Widgets on SqueakSource now has support for FillStyleBorder. Should also support use of composite fill styles.
Just for example:
Morph new extent: 200@150; borderStyle: (FillStyleBorder new width: 20; fillStyle: ((GradientFillStyle colors: {Color red. Color green}) origin: 0@0; direction: 200@150)); openInHand
Regards, Gary.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Alain Plantec Sent: 17 June 2008 8:24 AM To: Squeak's User Interface Subject: Re: [UI] FillStyles in borders
On Monday 16 June 2008 19:21:40 Gary Chambers wrote:
Just wondering if anyone would like to be able to use fill
styles in borders
(rather than just colours)...
I would like it. thanks alain
Gary
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Friday 27 June 2008 12:28:00 Gary Chambers wrote:
The lastest (version Pinesoft-Widgets-gvc.324) of Widgets on SqueakSource now has support for FillStyleBorder. Should also support use of composite fill styles.
I like that. thanks. Do you think it can be possible to get rid of old border styles (inset, outset ...) and replace them with FillStyleBorder together with a GradientFillStyle ? (by having 4 different fillstyles, each one for one side maybe ?). alain
Just for example:
Morph new extent: 200@150; borderStyle: (FillStyleBorder new width: 20; fillStyle: ((GradientFillStyle colors: {Color red. Color green}) origin: 0@0; direction: 200@150)); openInHand
Regards, Gary.
2008/6/27 Alain Plantec alain.plantec@univ-brest.fr:
On Friday 27 June 2008 12:28:00 Gary Chambers wrote:
The lastest (version Pinesoft-Widgets-gvc.324) of Widgets on SqueakSource now has support for FillStyleBorder. Should also support use of composite fill styles.
I like that. thanks. Do you think it can be possible to get rid of old border styles (inset, outset ...) and replace them with FillStyleBorder together with a GradientFillStyle ? (by having 4 different fillstyles, each one for one side maybe ?). alain
If it not slows things down a lot, then why not. In discussions with Gary we both agreed that it would be good if drawing primitives could be based on uniform model: any drawing operation can be represented by a function(shape, arguments .. )
This update getting us closer to such representation. The number of supported functions currently are quite few: - draw with solid color - draw with gradient - draw with infinite form - draw with finite form (also known as blitting)
but its difficult to make a clean implementation on top of graphic primitives, which we currently have. Most of primitives are optimized for single kind of shape - line , rectangle, ellipse. But none of them can use any shape as input.
Just for example:
Morph new extent: 200@150; borderStyle: (FillStyleBorder new width: 20; fillStyle: ((GradientFillStyle colors: {Color red. Color green}) origin: 0@0; direction: 200@150)); openInHand
Regards, Gary.
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
Perhaps a "clean" model coul;d be something for Pharo...
Maybe borders could be modelled via a decorator pattern to do away with some of these special cases. (think fillWith: fillStyle clippingTo: generalClipShape)The border (itself a morph) being a decoration of the morph... or maybe not called morph in a generalised framework, though interpreted that way for Morphic support...
Then again, to go the full-hog, the "ordinates" idea should cover all bases (with adaptation to Morphic).
Just a thought.
Gary.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Igor Stasenko Sent: 27 June 2008 3:04 PM To: alain.plantec@univ-brest.fr; Squeak's User Interface Subject: Re: [UI] FillStyles in borders
2008/6/27 Alain Plantec alain.plantec@univ-brest.fr:
On Friday 27 June 2008 12:28:00 Gary Chambers wrote:
The lastest (version Pinesoft-Widgets-gvc.324) of Widgets on
SqueakSource
now has support for FillStyleBorder. Should also support use
of composite
fill styles.
I like that. thanks. Do you think it can be possible to get rid of old border styles
(inset, outset ...)
and replace them with FillStyleBorder together with a
GradientFillStyle ?
(by having 4 different fillstyles, each one for one side maybe ?). alain
If it not slows things down a lot, then why not. In discussions with Gary we both agreed that it would be good if drawing primitives could be based on uniform model: any drawing operation can be represented by a function(shape, arguments .. )
This update getting us closer to such representation. The number of supported functions currently are quite few:
- draw with solid color
- draw with gradient
- draw with infinite form
- draw with finite form (also known as blitting)
but its difficult to make a clean implementation on top of graphic primitives, which we currently have. Most of primitives are optimized for single kind of shape - line , rectangle, ellipse. But none of them can use any shape as input.
Just for example:
Morph new extent: 200@150; borderStyle: (FillStyleBorder new width: 20; fillStyle: ((GradientFillStyle colors: {Color red. Color green}) origin: 0@0; direction: 200@150)); openInHand
Regards, Gary.
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
2008/6/27 Gary Chambers gazzaguru2@btinternet.com:
Perhaps a "clean" model coul;d be something for Pharo...
Maybe borders could be modelled via a decorator pattern to do away with some of these special cases. (think fillWith: fillStyle clippingTo: generalClipShape)The border (itself a morph) being a decoration of the morph... or maybe not called morph in a generalised framework, though interpreted that way for Morphic support...
Then again, to go the full-hog, the "ordinates" idea should cover all bases (with adaptation to Morphic).
Just a thought.
Btw, i was wrong: there is a 'generic' shape drawing primitives in BalloonEngine. They used mostly to draw arbitrary Bezier shapes. For instance, an SVGMorph using it to draw any SWG graphic - be it a set of lines/curves or anything else.
It would be interesting, how this can be adopted to draw anything. So, we could have few primitives which draw every bit on screen.
Gary.
Aye, clipping is another matter though (would want the "interior" of a border to not be drawn, for performance and not having to wory about draw-order/translucency issues).
Gary
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Igor Stasenko Sent: 27 June 2008 3:35 PM To: Squeak's User Interface Subject: Re: [UI] FillStyles in borders
2008/6/27 Gary Chambers gazzaguru2@btinternet.com:
Perhaps a "clean" model coul;d be something for Pharo...
Maybe borders could be modelled via a decorator pattern to do
away with some of these special cases.
(think fillWith: fillStyle clippingTo: generalClipShape)The
border (itself a morph) being a decoration of the morph... or maybe not called morph in a generalised framework, though interpreted that way for Morphic support...
Then again, to go the full-hog, the "ordinates" idea should
cover all bases (with adaptation to Morphic).
Just a thought.
Btw, i was wrong: there is a 'generic' shape drawing primitives in BalloonEngine. They used mostly to draw arbitrary Bezier shapes. For instance, an SVGMorph using it to draw any SWG graphic - be it a set of lines/curves or anything else.
It would be interesting, how this can be adopted to draw anything. So, we could have few primitives which draw every bit on screen.
Gary.
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
2008/6/27 Gary Chambers gazzaguru2@btinternet.com:
Aye, clipping is another matter though (would want the "interior" of a border to not be drawn, for performance and not having to wory about draw-order/translucency issues).
Well, in general, clipping is nothing more than a boolean operation on shapes: you take two shapes , subtract one from another and you got another shape which is a result of clipping.
The order of drawing is important , of course. If we could get rid of borders and replace them with more generic 'decoration' concept, then order is obvious: first, draw a morph , then draw decoration.
Gary
Except when the border and interior overlap... (which can be desired, modern "Mac style" default focus indications, as an example). Again, for that, a decoration would be best (not a border in the strictest sense).
As for clipping, the lack of low-level support for arbitrary shape clipping in Balloon is a problem and stencil-based clipping might be computationally expensive in BitBlt.
Gary.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Igor Stasenko Sent: 27 June 2008 3:43 PM To: Squeak's User Interface Subject: Re: [UI] FillStyles in borders
2008/6/27 Gary Chambers gazzaguru2@btinternet.com:
Aye, clipping is another matter though (would want the
"interior" of a border to not be drawn, for performance and not having to wory about draw-order/translucency issues).
Well, in general, clipping is nothing more than a boolean operation on shapes: you take two shapes , subtract one from another and you got another shape which is a result of clipping.
The order of drawing is important , of course. If we could get rid of borders and replace them with more generic 'decoration' concept, then order is obvious: first, draw a morph , then draw decoration.
Gary
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
2008/6/27 Gary Chambers gazzaguru2@btinternet.com:
Except when the border and interior overlap... (which can be desired, modern "Mac style" default focus indications, as an example). Again, for that, a decoration would be best (not a border in the strictest sense).
As for clipping, the lack of low-level support for arbitrary shape clipping in Balloon is a problem and stencil-based clipping might be computationally expensive in BitBlt.
Stencil-based clipping has its own drawbacks: its very hard to draw shapes antialiased once you clip area on per-pixel basis. I think, better would be to keep with shapes, and make engine which can have a notion of current clipping shape.
Gary.
I agree. In which case Balloon won't cut-the-mustard...
Regards, Gary.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Igor Stasenko Sent: 27 June 2008 4:08 PM To: Squeak's User Interface Subject: Re: [UI] FillStyles in borders
2008/6/27 Gary Chambers gazzaguru2@btinternet.com:
Except when the border and interior overlap... (which can be
desired, modern "Mac style" default focus indications, as an example).
Again, for that, a decoration would be best (not a border in
the strictest sense).
As for clipping, the lack of low-level support for arbitrary
shape clipping in Balloon is a problem and stencil-based clipping might be computationally expensive in BitBlt.
Stencil-based clipping has its own drawbacks: its very hard to draw shapes antialiased once you clip area on per-pixel basis. I think, better would be to keep with shapes, and make engine which can have a notion of current clipping shape.
Gary.
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-
Alain Plantec -
Gary Chambers -
Igor Stasenko