Nabble - Squeak - UI

RE: FillStyles in borders

2008-06-27T08:21:59Z

I agree. In which case Balloon won't cut-the-mustard...

Regards, Gary.

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]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@...>:
> > 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@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T08:08:05Z

2008/6/27 Gary Chambers <gazzaguru2@...>:
> 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@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: FillStyles in borders

2008-06-27T07:53:18Z

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@...
> [mailto:ui-bounces@...]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@...>:
> > 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@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T07:42:40Z

2008/6/27 Gary Chambers <gazzaguru2@...>:
> 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@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T07:38:12Z

2008/6/27 Alain Plantec <alain.plantec@...>:
> On Friday 27 June 2008 15:46:45 you wrote:
>> Certainly possible... though, since maintaining backwards-compatability, it
>> would not gain much (and a small performance hit is likely).
> I was thinking about the possibility for Miro. I would like to get rid of borders as well by only using
> fill style. The performance is maybe an issue but so far, I prefer not to care about that.
> (I prefer simplest possible code)
> Cheers,
> alain
>>

Yes, have that feeling too: borders is an artificial concept to widget
model which falls out the good model.
A decorations is much more powerful an flexible concept.

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: FillStyles in borders

2008-06-27T07:37:20Z

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@...
> [mailto:ui-bounces@...]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@...>:
> > 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@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T07:34:34Z

2008/6/27 Gary Chambers <gazzaguru2@...>:
> 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@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T07:09:40Z

On Friday 27 June 2008 15:46:45 you wrote:
> Certainly possible... though, since maintaining backwards-compatability, it
> would not gain much (and a small performance hit is likely).
I was thinking about the possibility for Miro. I would like to get rid of borders as well by only using
fill style. The performance is maybe an issue but so far, I prefer not to care about that.
(I prefer simplest possible code)
Cheers,
alain
>
> Regards, Gary.
>
>
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: FillStyles in borders

2008-06-27T07:09:28Z

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@...
> [mailto:ui-bounces@...]On Behalf Of Igor Stasenko
> Sent: 27 June 2008 3:04 PM
> To: alain.plantec@...; Squeak's User Interface
> Subject: Re: [UI] FillStyles in borders
>
>
> 2008/6/27 Alain Plantec <alain.plantec@...>:
> > 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@...
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T07:03:54Z

2008/6/27 Alain Plantec <alain.plantec@...>:
> 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@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-27T06:42:45Z

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.
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: FillStyles in borders

2008-06-27T03:28:00Z

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@...
> [mailto:ui-bounces@...]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@...
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
> >
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-17T00:24:07Z

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@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
>
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: FillStyles in borders

2008-06-16T11:25:16Z

Me :)
Unification is good way!

2008/6/16 Gary Chambers <gazzaguru2@...>:

> Just wondering if anyone would like to be able to use fill styles in borders
> (rather than just colours)...
>
> Gary
>
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

FillStyles in borders

2008-06-16T10:21:40Z

Just wondering if anyone would like to be able to use fill styles in borders
(rather than just colours)...

Gary

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Composite fill styles in action (or what to do when you bored).

2008-05-27T06:29:41Z

Another fun alternative:

World fillStyle: (
CompositeFillStyle fillStyles: {
(GradientFillStyle colors: {Color white alpha: 0.1. Color black alpha: 0.5})
origin: 0@0;
direction: 0@ Display height.
(GradientFillStyle colors: {Color paleGreen. Color blue})
origin: 0@0;
direction: Display width@0
})

Gary :-)

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Igor Stasenko
> Sent: 23 May 2008 10:44 PM
> To: Squeak's User Interface; The general-purpose Squeak developers list
> Subject: [UI] Composite fill styles in action (or what to do when you
> bored).
>
>
> Just do following script in latest squeak-dev image with UI
> enhancements installed.
>
>
> World fillStyle: (
> CompositeFillStyle fillStyles: {
> BitmapFillStyle fromForm: (
> (Form extent: 1@2 depth: 32) colorAt: 0@0 put: (Color transparent) ;
> colorAt: 0@1 put: (Color gray)).
> World fillStyle.
> })
>
>
> 2 Gary Chambers: quite confused why style listed last drawn first?
> As for me it is more logical to fill in order of appearance in code,
> not in reverse..
> or i missing something?
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Composite fill styles in action (or what to do when youbored).

2008-05-27T06:15:23Z

Also it matches the order of submorphs in Morphic...

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Gary Chambers
> Sent: 27 May 2008 9:52 AM
> To: Squeak's User Interface
> Subject: RE: [UI] Composite fill styles in action (or what to do when
> youbored).
>
>
> For the order, I think at the time I was optimising for the
> #is... methods, being that the topmost is considered first. Not
> sure is makes much difference to be fair though...
>
> Regards, Gary.
>
> > -----Original Message-----
> > From: ui-bounces@...
> > [mailto:ui-bounces@...]On Behalf Of Igor Stasenko
> > Sent: 23 May 2008 10:44 PM
> > To: Squeak's User Interface; The general-purpose Squeak developers list
> > Subject: [UI] Composite fill styles in action (or what to do when you
> > bored).
> >
> >
> > Just do following script in latest squeak-dev image with UI
> > enhancements installed.
> >
> >
> > World fillStyle: (
> > CompositeFillStyle fillStyles: {
> > BitmapFillStyle fromForm: (
> > (Form extent: 1@2 depth: 32) colorAt: 0@0 put: (Color transparent) ;
> > colorAt: 0@1 put: (Color gray)).
> > World fillStyle.
> > })
> >
> >
> > 2 Gary Chambers: quite confused why style listed last drawn first?
> > As for me it is more logical to fill in order of appearance in code,
> > not in reverse..
> > or i missing something?
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> > _______________________________________________
> > UI mailing list
> > UI@...
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
>
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Composite fill styles in action (or what to do when you bored).

2008-05-27T01:52:05Z

For the order, I think at the time I was optimising for the #is... methods, being that the topmost is considered first. Not sure is makes much difference to be fair though...

Regards, Gary.

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Composite fill styles in action (or what to do when you bored).

2008-05-23T14:43:38Z

Just do following script in latest squeak-dev image with UI
enhancements installed.

World fillStyle: (
CompositeFillStyle fillStyles: {
BitmapFillStyle fromForm: (
(Form extent: 1@2 depth: 32) colorAt: 0@0 put: (Color transparent) ;
colorAt: 0@1 put: (Color gray)).
World fillStyle.
})

2 Gary Chambers: quite confused why style listed last drawn first?
As for me it is more logical to fill in order of appearance in code,
not in reverse..
or i missing something?

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: [BUG] Click events are only honored after moving the mouse

2008-05-08T05:46:23Z

On 08.05.2008, at 11:14, Adrian Lienhard wrote:

> Hi,
>
> From time to time it happens that the image gets into a weird state
> where click events are only honored after moving the mouse. For
> example, in the code browser you click on a method but nothing
> happens until you start moving the cursor. The problem does not seem
> to go away again.
>
> Has anybody else seen this problem? If yes, does a Mantis report
> exist that I have not found?

I have seen this, too. On Linux for sure, and maybe on Mac OS. No idea
for the cause.

- Bert -

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

[BUG] Click events are only honored after moving the mouse

2008-05-08T02:14:12Z

Hi,

From time to time it happens that the image gets into a weird state
where click events are only honored after moving the mouse. For
example, in the code browser you click on a method but nothing happens
until you start moving the cursor. The problem does not seem to go
away again.

Has anybody else seen this problem? If yes, does a Mantis report exist
that I have not found?

Cheers,
Adrian
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Just a thought...

2008-04-29T11:25:55Z

Sorry Sig, thought I'd replied to this...

Appears to be juan's old work...
Looks a bit heavyweight and not addressing translucency blending into a "destination".

Won't worry about it for now, FuzzyLabelMorph will do. :-)

Regards,
Gary

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Igor Stasenko
> Sent: 24 April 2008 11:18 PM
> To: Squeak's User Interface
> Subject: Re: [UI] Just a thought...
>
>
> i just discovered something which may be of you interest :)
> http://wiki.squeak.org/squeak/3269
> See 'melt' filter. I think you can use it for smearing background
>
> 2008/4/19 Gary Chambers <gazzaguru2@...>:
> >
> >
> > Backwards compatability is always an issue, especially here.
> Wondering if we
> > can really move things onwards now...
> >
> > -----Original Message-----
> > From: ui-bounces@...
> > [mailto:ui-bounces@...]On Behalf Of
> Michael van der
> > Gulik
> > Sent: 18 April 2008 4:44 AM
> > To: Squeak's User Interface
> > Subject: Re: [UI] Just a thought...
> >
> >
> >
> >
> >
> > On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers
> <gazzaguru2@...>
> > wrote:
> >
> > > It might be nice that we have some more paint rules in BitBlt. A
> > "fuzz/blur"
> > > effect would be nice and take the load off the Squeak code for such
> > things.
> > >
> > > Just wanting to get more contemporary with the ui look without large
> > > performance penalties.
> > >
> > > Not quite liking the way that effects are hidden behind
> canvas (leading to
> > a
> > > bloated interface, perhaps (c.f. #drawImage...
> #drawTranslucentImage...)).
> > > Not sure where the balance should be. Looks like a
> choke-point that is too
> > > useful to bypass on a case-by-case basis.
> > >
> >
> >
> > If you were to implement some more interesting effects in
> BitBLT, how would
> > you make sure that Morphs that use this code will still work on other
> > targets such as Rome, Postscript Canvases, VNC etc?
> >
> > Gulik
> >
> >
> > --
> > http://people.squeakfoundation.org/person/mikevdg
> > http://gulik.pbwiki.com/
> > _______________________________________________
> > UI mailing list
> > UI@...
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Just a thought...

2008-04-24T15:18:27Z

i just discovered something which may be of you interest :)
http://wiki.squeak.org/squeak/3269
See 'melt' filter. I think you can use it for smearing background

2008/4/19 Gary Chambers <gazzaguru2@...>:

>
>
> Backwards compatability is always an issue, especially here. Wondering if we
> can really move things onwards now...
>
> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Michael van der
> Gulik
> Sent: 18 April 2008 4:44 AM
> To: Squeak's User Interface
> Subject: Re: [UI] Just a thought...
>
>
>
>
>
> On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers <gazzaguru2@...>
> wrote:
>
> > It might be nice that we have some more paint rules in BitBlt. A
> "fuzz/blur"
> > effect would be nice and take the load off the Squeak code for such
> things.
> >
> > Just wanting to get more contemporary with the ui look without large
> > performance penalties.
> >
> > Not quite liking the way that effects are hidden behind canvas (leading to
> a
> > bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)).
> > Not sure where the balance should be. Looks like a choke-point that is too
> > useful to bypass on a case-by-case basis.
> >
>
>
> If you were to implement some more interesting effects in BitBLT, how would
> you make sure that Morphs that use this code will still work on other
> targets such as Rome, Postscript Canvases, VNC etc?
>
> Gulik
>
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
>

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Summary

2008-04-22T10:49:36Z

Looks like exactly the kind of thing I envisaged, though with a possible
mix-n-match approach to the ui construction with fallback options for
unavailable targets.

Gary.

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Michael
> Davies
> Sent: 22 April 2008 6:42 PM
> To: Squeak's User Interface
> Subject: Re: [UI] Summary
>
>
> Thanks for the detailed response Vassili. There's lots of interesting
> stuff in there, and as you say, the ability to dynamically re-map the
> UI onto different host environments must make for a very impressive
> demo!
>
> I look forward to seeing future updates to your blog on this topic
> (http://blog.3plus4.org/ right?).
>
> Cheers,
> Michael
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Summary

2008-04-22T10:41:44Z

Thanks for the detailed response Vassili. There's lots of interesting
stuff in there, and as you say, the ability to dynamically re-map the
UI onto different host environments must make for a very impressive
demo!

I look forward to seeing future updates to your blog on this topic
(http://blog.3plus4.org/ right?).

Cheers,
Michael
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Summary

2008-04-20T15:58:16Z

Hi Michael,

On Sun, Apr 20, 2008 at 5:38 AM, Michael Davies
<mykdavies+squeak@...> wrote:
>
> What are your usage scenarios for Newspeak that are making UI
> development a priority at such an early stage in the development of
> the language?

Gilad mentioned at various points in the talk that Newspeak exists in
the context of a larger application project. This was the reason why
development started with Squeak and not as "come back in two years and
we'll have a platform for you", and also why there was the need for a
GUI early on. Plus of course, it was clear from the start that the
classic Smalltalk browser model was not scalable enough for nested
classes, so without a UI story it would be life with source files in
Emacs.

> Could you explain the relationship between Brazil and Hopscotch, and
> the division of responsibilities between them?

Brazil could be described as an abstract widget and layout framework.
Abstract because the objects you normally work with as the framework
user are some generic constructs materialized behind the scenes as
artifacts of the host OS UI. (Morphic is also treated as a host UI,
and the browser you saw in the demo was in fact made of morphs even
though it wasn't coded in Morphic). As an example, a Brazil Button has
attributes such as the label, the enabled/disabled state, and the
action to invoke when it is pressed. When its container window opens
in Morphic, you get a SystemWindow morph a SimpleButtonMorph inside.
When the same window opens in Windows, you get a native window with a
native Windows button control in it. A UI can be dynamically unmapped
from one host and remapped to the other, retaining any important
state. This makes a neat demo, but is also pretty much a requirement
if you want to support image-based development and allow saving an
image on one OS and opening it on another.

Brazil also manages widget layout, using what's essentially a
capability-based model, which is interesting but best explained
separately. The layout is always computed by Brazil, be it in Windows
which has no layout mechanism of its own or in Morphic which does.

Hopscotch is the application framework and the browser. I myself make
no distinction between the two--at least not to the point of coming up
with separate names--as I've been working on the framework and the
browser together from the start. But strictly speaking they are two
separate things, Hopscotch-the-framework and Hopscotch-the-browser.

The purpose of the framework is to allow expressing and managing
assemblies of widgets that serve a particular purpose. The purpose is
usually to present and manipulate some domain objects, so the
framework is essentially domain-UI glue plus some common UI tools such
as the document model and navigation facilities. That's kind of it in
the most general sense. There are various interesting points about the
way Hopscotch does it, and I plan to eventually tell about it in
detail on my blog and other venues, but it's a little too early yet.
But one interesting point is that similar to how Brazil UIs can
manifest themselves as widgets of different host systems, a Hopscotch
application could be rendered by an underlying widget layer other than
Brazil. For example, it would be possible to run Hopscotch (the
browser/IDE) in a web browser by teaching Hopscotch (the framework)
how to represent itself as ajaxy html. For now this is only a
possibility, but the architecture has hooks to allow things like that.

Cheers,

--Vassili
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Summary

2008-04-20T05:38:11Z

Hi Vassili,

Thanks for responding - I think your name was mentioned in the talk,
but I couldn't find it when I went back to search, so apologies for
not giving you credit.

> I'll give a talk specifically about those
> frameworks at Smalltalk Solutions this June and possibly elsewhere
> sometime later.

I look forward to that - your work looks very interesting.

> But to have the expectations right from the start--you have to realize
> that Brazil and Hopscotch are frameworks for and in Newspeak.

Yes, I should have made that clearer. I think the value in any
discussion would be in understanding the design decisions you are
making, how you're implementing them, and what's driving them.

> And then if you ask me, I don't think that the biggest problem with
> the Squeak UI is dearth of UI frameworks

Perhaps "dearth of robust, attractive UI frameworks in active
development" would have been nearer the mark until recently? Now
though, as Gary's email indicated, there are a number of lines of work
proceeding, and it would be useful to ensure that there's
cross-fertilisation between these efforts. The presence of the UI
mailing list is a good start in that direction.

> much as I believe that Brazil and Hopscotch are The Right Thing :).

:-)

I wonder if you could answer a couple of questions to help my
understanding of your work? I'll understand if you're unable to do so
at present.

What are your usage scenarios for Newspeak that are making UI
development a priority at such an early stage in the development of
the language?
Could you explain the relationship between Brazil and Hopscotch, and
the division of responsibilities between them?

Thanks,
Michael
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Summary

2008-04-19T18:08:33Z

On Sat, Apr 19, 2008 at 1:46 PM, Michael Davies
<mykdavies+squeak@...> wrote:
> It might also be worth finding out some more about Gilad Bracha's work
> on Newspeak. He's got a very slick interface built on top of Squeak,
> using two frameworks - "Brazil" widget framework and "Hopscotch"
> application framework. He discussed them briefly in passing during the
> talk linked to at
> http://news.squeak.org/2008/04/19/video-of-newspeak-lecture-now-available/
> - I think he's still working to persuade the sponsors to allow the
> code to be open-sourced, but there may be a useful discussion to be
> had in the meantime.

I'll be happy to de-lurk and tell more Brazil and Hopscotch. What
would you like to find out? I'll give a talk specifically about those
frameworks at Smalltalk Solutions this June and possibly elsewhere
sometime later.

But to have the expectations right from the start--you have to realize
that Brazil and Hopscotch are frameworks for and in Newspeak. Squeak
is a host at the moment and Morphic is treated by Brazil as one of the
native UIs it maps to, but you can't just transplant the frameworks
into a Squeak image. Also, while Squeak is a host at the moment, it
does not have to stay this way forever.

At the moment, interoperability between the two languages is possible,
but it is not a goal in itself. A plain Squeak program in the same
image could build a Brazil UI. Hopscoth, on the other hand, is
definitely best used in Newspeak. I expect that after my next redesign
it will become even more Newspeak-specific. That is to say, I myself
am not sure how directly useful both are for the future of Squeak UI.
(And then if you ask me, I don't think that the biggest problem with
the Squeak UI is dearth of UI frameworks, much as I believe that
Brazil and Hopscotch are The Right Thing :).

Cheers,

--Vassili
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Summary

2008-04-19T13:46:27Z

On Tue, Apr 15, 2008 at 11:52 PM, Gary Chambers
<gazzaguru2@...> wrote:

> Just to summarise what we should be looking at (IMHO):
>
> Alain Plantec's Miro http://www.squeaksource.com/Miro/
> Juan Vuletich http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html
> (the site appears to be suffering from entropy...)
> Sig's OpenGL canvas (can be Googled, will let Sig let us know...)
> The SqueakGTK project http://wiki.squeak.org/squeak/6043 (older:
> http://www.squeaksource.com/Gtk/)
> Areithfa Ffenestri http://wiki.squeak.org/squeak/3862
>

It might also be worth finding out some more about Gilad Bracha's work
on Newspeak. He's got a very slick interface built on top of Squeak,
using two frameworks - "Brazil" widget framework and "Hopscotch"
application framework. He discussed them briefly in passing during the
talk linked to at
http://news.squeak.org/2008/04/19/video-of-newspeak-lecture-now-available/
- I think he's still working to persuade the sponsors to allow the
code to be open-sourced, but there may be a useful discussion to be
had in the meantime.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Just a thought...

2008-04-18T14:41:06Z

Backwards compatability is always an issue, especially here. Wondering if we can really move things onwards now...

-----Original Message-----
From: ui-bounces@... [mailto:ui-bounces@...]On Behalf Of Michael van der Gulik
Sent: 18 April 2008 4:44 AM
To: Squeak's User Interface
Subject: Re: [UI] Just a thought...

On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers <gazzaguru2@...> wrote:

It might be nice that we have some more paint rules in BitBlt. A "fuzz/blur"
effect would be nice and take the load off the Squeak code for such things.

Just wanting to get more contemporary with the ui look without large
performance penalties.

Not quite liking the way that effects are hidden behind canvas (leading to a
bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)).
Not sure where the balance should be. Looks like a choke-point that is too
useful to bypass on a case-by-case basis.

If you were to implement some more interesting effects in BitBLT, how would you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?

Gulik

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Just a thought...

2008-04-18T12:48:54Z

> -----Original Message-----
> From: ui-bounces@...
> [mailto:ui-bounces@...]On Behalf Of Igor Stasenko
> Sent: 18 April 2008 7:32 AM
> To: Squeak's User Interface
> Subject: Re: [UI] Just a thought...
>
>
> 2008/4/18 Michael van der Gulik <mikevdg@...>:
> >
> >
> > On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers
> <gazzaguru2@...>
> > wrote:
> > > It might be nice that we have some more paint rules in BitBlt. A
> > "fuzz/blur"
> > > effect would be nice and take the load off the Squeak code for such
> > things.
> > >
> > > Just wanting to get more contemporary with the ui look without large
> > > performance penalties.
> > >
> > > Not quite liking the way that effects are hidden behind
> canvas (leading to
> > a
> > > bloated interface, perhaps (c.f. #drawImage...
> #drawTranslucentImage...)).
> > > Not sure where the balance should be. Looks like a
> choke-point that is too
> > > useful to bypass on a case-by-case basis.
> > >
> >
> >
> > If you were to implement some more interesting effects in
> BitBLT, how would
> > you make sure that Morphs that use this code will still work on other
> > targets such as Rome, Postscript Canvases, VNC etc?
> >

Would need to have fallback options for backends that do not directly support any new features.
Sig, below, seems on the right track in terms of refactoring.

> 1. BitBlt already contains many blitting rules which is problematic to
> support on different back ends.
> 2. In future, i suppose, we need a more functional approach how to
> define drawing operations.
> To describe a blitting/drawing operations with classes/objects not
> with integer numbers, like we currently have, which is meaningless and
> hard to determine how they working.
>
> Drawing operation should be represented by object - a
> function(source, destination, arguments..), where function is fully
> reflected in language.
>

Agree about the operation being properly represented *but* still need the extra performance of a backend (primitive) operation. People are complaining enough that Morhpic is slow...

>
> > Gulik
> >
> >
> > --
> > http://people.squeakfoundation.org/person/mikevdg
> > http://gulik.pbwiki.com/
> > _______________________________________________
> > UI mailing list
> > UI@...
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Just a thought...

2008-04-17T23:32:08Z

2008/4/18 Michael van der Gulik <mikevdg@...>:

>
>
> On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers <gazzaguru2@...>
> wrote:
> > It might be nice that we have some more paint rules in BitBlt. A
> "fuzz/blur"
> > effect would be nice and take the load off the Squeak code for such
> things.
> >
> > Just wanting to get more contemporary with the ui look without large
> > performance penalties.
> >
> > Not quite liking the way that effects are hidden behind canvas (leading to
> a
> > bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)).
> > Not sure where the balance should be. Looks like a choke-point that is too
> > useful to bypass on a case-by-case basis.
> >
>
>
> If you were to implement some more interesting effects in BitBLT, how would
> you make sure that Morphs that use this code will still work on other
> targets such as Rome, Postscript Canvases, VNC etc?
>

1. BitBlt already contains many blitting rules which is problematic to
support on different back ends.
2. In future, i suppose, we need a more functional approach how to
define drawing operations.
To describe a blitting/drawing operations with classes/objects not
with integer numbers, like we currently have, which is meaningless and
hard to determine how they working.

Drawing operation should be represented by object - a
function(source, destination, arguments..), where function is fully
reflected in language.

> Gulik
>
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
> _______________________________________________
> UI mailing list
> UI@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
>

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: Just a thought...

2008-04-17T20:44:23Z

On Thu, Apr 17, 2008 at 5:15 AM, Gary Chambers <gazzaguru2@...> wrote:

It might be nice that we have some more paint rules in BitBlt. A "fuzz/blur"
effect would be nice and take the load off the Squeak code for such things.

Just wanting to get more contemporary with the ui look without large
performance penalties.

Not quite liking the way that effects are hidden behind canvas (leading to a
bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)).
Not sure where the balance should be. Looks like a choke-point that is too
useful to bypass on a case-by-case basis.

If you were to implement some more interesting effects in BitBLT, how would you make sure that Morphs that use this code will still work on other targets such as Rome, Postscript Canvases, VNC etc?

Gulik

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Just a thought...

2008-04-16T10:15:34Z

It might be nice that we have some more paint rules in BitBlt. A "fuzz/blur"
effect would be nice and take the load off the Squeak code for such things.

Just wanting to get more contemporary with the ui look without large
performance penalties.

Not quite liking the way that effects are hidden behind canvas (leading to a
bloated interface, perhaps (c.f. #drawImage... #drawTranslucentImage...)).
Not sure where the balance should be. Looks like a choke-point that is too
useful to bypass on a case-by-case basis.

Anyway, just a few thoughts.

Gary.

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

RE: Diff tools.

2008-04-16T09:08:50Z

:)

Cheers,
Juan Vuletich

> +1 against ugly fonts!
>
> We use FreeType because of licensing around the fonts our clients want to
> use. Up to them to supply the fonts (so needs to be dynamic based upon the
> "user"'s pc/device).
>
> It is good we have choices in font approaches. Could do with a thorough
> refactoring now though (on an inclusive basis).
>
> Regards,
> Gary.
>

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui