On 3 April 2016 at 13:27, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

It is indeed logical :)

However, in most UI of applications (in web, mobile) it is extremely rare that clipping or event handling areas differ from drawing one (visual one - one that user sees in the end).

But wait, what i saw in this thread: Stef presented a simple use case - he wants to draw a rectangle plus circle or a line..

and got lost.. confused and frustrated.

And i am far to see how such use case can be called something exceptionally rare. Do you?

The goal of good design is to make common cases extremely simple, non-common cases - harder. But not impossible.

And by impossible i mean not that you cannot do anything by yourself, but what you can do using existing framework. The fact that i can override and rewrite anything and make it my way - is not a valid argument.

Yes, i made a slight detour in discussion, to demonstrate that actually single shape per morph is no go.. And there's multiple shapes can be involved and each for own role. And allowing only a single one feels a bit limiting, as to me.

But of course i understand, that it is not so common, except when i wanna draw a label on top of background, which requires at least two shapes. :)

As for clipping/ui shapes, i don't understand, it is really not that hard to do, i.e.:

clippingShape

��^ clippingShape ifNil: [ self shape ] ��

.. which means you can still have a single shape by default, but in case you need - here you go, you free to define own.

But anyways.. All i want is to be convinced that my fears are not that bad.

Btw, i have a question about your statement, quote:

You don't want to draw a shape, you configure it. Shape can not be drawn, it is not an AthensPath.

Hmm. At least in Athens, by design AthensPath is a shape. It is a shape, that is drawn by Athens. Path is just a single concrete case how you could define a shape. Rectangle is another one.. And there's no limitation in Athens, what may represent a shape, as long as it conforms to AthensShape protocol, which also means, if you look at it, it has #paintFillsUsing:on: , which implies, that it actually should know how to draw itself. And of course, since it knows what areas it covers it has insights about own geometry.. but such details are not exposed to outside, since it would be very hard to encode all possible ways to represent shape(s) by some kind of common data, like paths.��

Are you talking about Bloc shapes? Then it is indeed a pity, if such statement are correct in terms of Bloc. Because then it introducing another kind of shapes in addition to existing kind of shapes introduced by Athens.. something different and not really compatible. Which serves as a source of confusion.

I am not arguing, maybe such thing was necessary, but i would, at least then call it different to avoid potential confusion.

Do you agree with that and also that in most cases we want to change them all together just sending one message? :)

Cheers
Alex

On Apr 3, 2016 12:20 PM, "Denis Kudriashov" <dionisiydk@gmail.com> wrote:
Hi

2016-04-03 11:08 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
If you want to change clicking behaviour you need to override one single method.

Everything you wrote with unreadable amount of characters is for nothing.
I see clearly point of Igor. And for me it feels very logical. With such design you can lively change clipping area and interaction area for any morph (element) on screen.

Best regards,
Igor Stasenko.