Le 3/4/16 18:23, Aliaksei Syrel a écrit :
This means that any abstraction/wrapper around athens will fail.
What if we would remove drawingShape and by default leave drawOn:
method to be empty. That way we would not put any constraints on
rendering part. user just gets athens canvas and can do whatever she
wants.
Instead we would have only clipping shape and event area shape.
What do you think? :)
I have the impression that this is a good solution.
Cheers,
Alex
On Sun, Apr 3, 2016 at 6:04 PM, Igor Stasenko <siguc...@gmail.com
<mailto:siguc...@gmail.com>> wrote:
On 3 April 2016 at 17:58, Aliaksei Syrel <alex.sy...@gmail.com
<mailto:alex.sy...@gmail.com>> wrote:
And you lost me here.. That is complete nonsense.. from
any perspective.
Can i unsee this code, please? :)
If I would say that we have defaultShape method and it can be
overridden as:
defaultShape
^ BlShape new
fillPaint: (BlColorPaint new color: (Color yellow));
path: BlRectanglePath new
would it make you happy?
Nope. (see bottom of reply why)
.. to me it feels like: okay, what we need to do, to
prevent overrides of our beloved default #drawOn: method.
You are wrong concerning preventing to override drawOn :)
Don't forget that there was a customer
*requirement* concerning bloc:
Can we change how morph looks on fly? Can we create a
rectangle morph and change it's shape from rectangle to
circle? Because it can nicely show while presenting that
*Pharo is live system*. I'm pretty sure Stef said it once ago.
Do you see how bloc story can nicely be told:
We have basic UI elements and each element has shape that
can be easily changed live. Shape is defined by a path
which can be filled or stroked using a paint. Complex
elements can be created as composition of elements with
basic shapes (rectangle, circle).
Isn't it beautiful? :)
Nope. Because it would be beautiful, if your statements would be
reflected in
reality and by reality.
In your example #defaultShape method, you simply isolating some
behavior into a separate method. It does not changes anything.
You want to achieve to be able to change shapes on the fly. Good.
A honourable goal. And welcoming. No objections here.
But can we achieve it without losing being able to change the
color of shape on the fly. Please? :)
The way you introducing it goes straightly into conflict with: i
want to be able to draw anything, the way i feel and like.
You proposing a bad trade: oh yeah, you wanted to change shapes on
the fly.. good.. but at cost of unable to draw anything else than
simple rectangles in simple order..
Well.. i am not buying such trade. Can you sweeten a deal?
The point is, that shape is not the only thing you need to put
into equation in order to get thing on the screen.. You also need
paint. And that's the reason why you have
fillPaint: (BlColorPaint new color: (Color yellow));
(lets put aside the hardcoding of color in unrelated place
(defaultShape).. for the sake of example)
but does that fully covers all and any possible ways and needs of
drawing?
Nope! Again not..
And voila, say welcome to composite "shapes" or "elements" or call
it as you like it.
But does that fully covers all and any possible ways you can draw
something with Athens?
Nope, it is not. Again. Sorry. You can achieve that only if you
completely encode all possible operations and features provided by
Athens using some kind of command pattern and put them in
'element' or 'compositeElement' or
'compositeOfCompositeElementsComposition' whatever.
For instance, how you going to encode AthensPaintMode into your
elements?
I guess you will offer to kill it with your 'it is not used so
often' knife.
Can't you see that you basically creating a wrapper for all Athens
feature set.
I can tell you that you wasting effort: you cannot get anything
extra by doing it. Except from extra complexity.
And for what? Something that already there and can be used out of
the box.
If you don't like Athens API - go on, and change it. Make it
better and more convenient to use. But encapsulating all possible
combinations of all possible drawing operations? Good luck with that.
Cheers,
Alex
On Sun, Apr 3, 2016 at 3:37 PM, Igor Stasenko
<siguc...@gmail.com <mailto:siguc...@gmail.com>> wrote:
On 3 April 2016 at 16:20, Igor Stasenko
<siguc...@gmail.com <mailto:siguc...@gmail.com>> wrote:
On 3 April 2016 at 15:28, Glenn Cavarlé
<gl...@cavarle.fr <mailto:gl...@cavarle.fr>> wrote:
Hi,
Aliaksei Syrel wrote
> 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).
It is the same for desktop UI (Qt, JavaFx,...).
I think the misunderstanding come from "shape", so
let us forget BlShape and
concentrate on BlElement.
In fact, using Bloc now, If we want a Rectangle
with an clickable inner
Circle, we have to defined 2 elements, the
Rectangle one and the Circle one
(subclass of BlElement or using script style).
The CircleElement must be the child of the
RectangleElement but we don't
have to override any method or to rewire
CircleElement events back to its
parent, we just need to add an event listener to
the CircleElement from
where we want.
It is the same with a Text in a Rectangle, we need
a BlElement for the Text
and another for the Rectangle in order to compose
them and to position the
Text in the Rectangle.
For me its like defining a CircleButton in a
RectanglePanel with any other
ui libraries, i can do that by subclassing Panel
or by using script style.
But i have to manipulate 2 elements and it makes
sense for me.
Bloc does not provide user-friendly high-level
abstractions at BlShape or
BlElement level like BlCircleShape or BlCircleElement.
I don't know if it is the right place to add them
but it is clearly a point
of misunderstanding when people uses Bloc.
It seems to me that Bloc is not made to be used
direclty as a graphical
framework but it is a librarie to build more
user-friendly graphical
framework.
Shape, Path, ... are implementations stuff, most
of users should not care
about that using a "framework".
Thanks for explanation..
Now i have a hard time understanding, what is the
purpose of so-called 'element'. Element of what? What
its role?
What its interaction between morphs and shapes, and
what you see & feel on the screen?
>From your description, what i can tell is that it is
completely unnecessary.
You have morphs to define hierarchy/composition.
And you can use shapes to define geometry for UI/clipping.
As for drawing - there's no need to put any
constraints, you don't have to even mention that there
are shapes involved. It is indeed, an implementation
detail from that perspective, since you drawing things
using Athens, and it uses shapes to define affected
regions. But that completely orthogonal to what
happens at UI level.
Thus, it is very surprising to me see following code
snippet:
BlCell>>initialize
super initialize.
self
shape:
(BlShape new
fillPaint: (BlColorPaint new color: (Color yellow));
path: BlRectanglePath new);
extent: self extent
because it is really seems like encapsulation of what
you gonna draw..
and putting it into #initialize method in some form?
And you lost me here.. That is complete nonsense..
from any perspective.
Can i unsee this code, please? :)
<acid mode on>
.. to me it feels like: okay, what we need to do, to
prevent overrides of our beloved default #drawOn: method.
And you talking about 'sophistication' after that?
</acid mode off>
PS: @Alex, what are the planned refactoring? I'm
lost in the new intentions
and in the roadmap of Bloc...
Regards,
Glenn.
-----
Glenn Cavarlé
--
View this message in context:
http://forum.world.st/bloc-shape-size-tp4887929p4888039.html
Sent from the Pharo Smalltalk Developers mailing
list archive at Nabble.com.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
