April 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [bloc] shape size?

by stepharo

I did not want a square with a clickable circle. I just wanted a square with a drawn circle on it and I do not understand why I should compose a new morph just for that. I did not get how draw and morph composition are working. I tried to draw the circle myself and I fall into a wrong version that I should be use story. Stef Le 3/4/16 14:28, Glenn CavarlÃ© a Ã©crit : > 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". > > 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. > >

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by stepharo

Sorry aliaksei but this is not an anwser in a discussion Le 3/4/16 11:08, Aliaksei Syrel a Ã©crit : > > 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. > > All mentioned stuff is possible. > > On Apr 3, 2016 10:30 AM, "Igor Stasenko" <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > > > On 3 April 2016 at 10:18, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi Igor, > > Thanks for this nice description :). > > Indeed, the Shape in Bloc is primarily a clipping shape that > knows how to draw the path around and to fill itself. Of > course, it also handles the interaction. > > When you want to have a composition, you are encouraged to > create multiple elements (morphs). This is a way to handle > both more complicated interaction and more complicated > drawing. Of course, you can still override the drawing method > and draw whatever you want on it, but we would rather have a > simple composition. > > The disadvantage of this design is that indeed, is that it is > not sophisticated. The advantage of this design is that it is > not sophisticated :) and you get only one tree of compositions > for the elements without another level of composition at the > shape level. The main reason we went this route is because we > want Bloc to pose as little constraints for the things built > on top as possible without losing power. > > Does this make sense for you? > > > It makes sense, sure thing. > But it does not solves the problem. > As i explained before, a single shape cannot serve as both > clipping, UI handling and drawing all together. Because it is > three separate roles, which is good if they coincide, but causing > a lot of problems, when they are not. > It is not matters how you compose or decompose shapes.. there is > simply no composition which can turn rectangle into, lets say circle. > it simply impossible to construct required clipping shape, or UI > shape from set of drawing shapes, in case when they are completely > different from each other. > > For instance if i want morph with rectangular appearance > (rectangle shape) to respond on clicks only within circular > subregion inside that rectangle, i will be forced to create a > submorph and then rewire event handling back to its parent. And > that happens every time i need a different shape for mouse clicks > than shape for drawing. Now add clipping here... and you will get > a nightmare of bells and whistles, composing and whatsnot. > > As for 'sophisticated'.. let see: > so, in my proposition, i do: > - draw rectangle and circle inside > - define that circle as UI shape > - define that rectangle as clipping shape > done. > In your design, i have to: > - make a morph with rectangular shape > - create submorph with circular shape > - wire clicking of a submorph to propagate event to its parent > > or think about some kind of composition.. composing what with what? > does it union of circle and rectangle? or intersection? depending > the way how you composing those two shapes you receive one or > another outcome.. > and that event wiring is extra work.. > So, it may look that what i proposing is more sophisticated.. > But i just wanna see a separate roles taking own places, nothing else. > I do not inventing new concepts, that wasn't there before: > - you need clipping, > - you need drawing > - you need UI handling > > You see, it is not a framework, that forcing you to be > 'sophisticated' .. it is domain itself. It draws a clear border > between things that are optional and things that are absolutely > necessary, since they are separate concepts and roles. > > You simply cannot represent an infinite dimension of drawing > compositions by a composition of UI elements. Only the simplest > cases.. > It is big mistake to imply that anything that you drawing on > screen must be a full-blown UI element (which is morph is) or > their composition. > It makes you quite limited in terms of what you can draw and what not. > Morph is UI building brick.. but it is not graphical building > brick.. making such parallel gives more troubles than it solves. > > To me concept where morph==shape==clipping shape==ui shape is just: > - you can have bike of any color, as long as it's black. > > Can you enlighten me, what composition of black bikes can result > in a green one? > > > Cheers, > Doru > > > > On Apr 3, 2016, at 6:38 AM, Igor Stasenko > <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > > > Oh, yeah.. i missed one more kind of shape, you may want to > introduce: > > - clipping shape. > > > > For optimizing drawing operations, you may want to define a > region, which guarantees, that anything you paint, nothing > outside defined region will affect the screen. Because else, > you will allow morph to render anywhere and therefore, it is > really hard for UI subsystem to account damage on the screen. > > But once you define such shape, then you can clearly tell, > which portion of the screen may or may not be damaged and > therefore act accordingly. > > > > So, overall when we talking about shapes, we need to talk > about three different kinds of them: > > > > - UI interaction shape > > - clipping shape > > - shape(s) used to draw > > > > those three may or may not coincide into single one, > depending on complexity and what you wanna do.. > > But they can be completely different from each other and in > order to avoid confusion and frustration, i would really > introduce them in such manner, that users have clear vision on > what happens with their morphs and how to achieve what they want. > > > > Clearly, a single #shape: is not enough, if you want a > non-conflicting representation of these concepts in UI. > > > > > > On 3 April 2016 at 07:15, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > > > > > On 2 April 2016 at 20:59, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > > > Le 2/4/16 17:31, Aliaksei Syrel a Ã©crit : > >> You don't want to draw a shape, you configure it. Shape can > not be drawn, it is not an AthensPath. > >> > >> cell shape: (BlShape new > >> path: BlCirclePath new; > >> strokePaint: (BlStrokePaint new > >> paint: Color blue; > >> width: 1)). > >> cell extent: 50@50. > >> > > > > But this is not what I want! As I mentioned in a mail that > was sent but never arrived. > > I want a square and this is why I did > > > > BlCell>>initialize > > super initialize. > > self > > shape: > > (BlShape new > > fillPaint: (BlColorPaint new color: (Color > yellow)); > > path: BlRectanglePath new); > > extent: self extent > > > > > > then I want to draw something extra this is why I overrode > drawOnAthensCanvas: aCanvas > > > > Now I stop but I find bloc too complex. > > > > Sorry but I cannot lose time like that and just get > frustrated at the end. > > I will use the athens canvas directly and stay in morph for now. > > > > > > I think there's a bit of misconception. > > In Athens, shape representing any area you wanna fill with > paint. Period. > > It can be of any complexity, self-intersecting yadda yadda.. > the main point is that it defines a region(s), that going to > be filled with chosen paint during draw operation. > > From perspective of morphs, as UI elements, most of them > require some shape(s) to represent themselves on the screen. > But there are morphs, that while still taking part in UI, > don't need any shapes since they never drawn on the screen. > > Another point is that nowhere said that morph can be > represented by a one and only one shape period. Because as in > your case, you want to, say, draw rectangle with paint A, and > circle with paint B, then you basically need two different > shapes (overlapping or not - not really matters) to represent > morph on the screen. > > > > So, the first point in misconception comes from 'self shape:'.. > > It is wrong from that perspective, because it is all fine, > when morph using only single shape to represent itself.. but > when you need multiple shapes, you are in trouble. It at least > misleading, because provoking you to think that there can be > only one. > > > > Then you need to invent a 'composite shape' that basically a > collection of shapes for a single morph, that will represent > it on the screen. > > > > A tangent to that, is that since most of morphs has mostly > static geometry/topology and changing it very rarely and much > less often comparing to drawing same shape(s) over and over > again, it is right thing to define and initialize shape(s) and > reuse them later in #draw method. Since you don't change > shape(s), you don't have to generate new object(s). > > From that perspective, this is nice, resource saving, approach. > > But let us not forget, that this is just a 'statistical > observation' and hence good to be a default setup. But it > should not dictate you the rule(s). > > You should still be able to define shape(s) on the fly or > change it on the fly, dynamically. > > > > Another problematic is that you may want to use different > shapes for > > a) painting morph on screen > > b) defining geometry of the morph for UI interactions. > > As an example, let say, you want a rectangle with circle in > centre on the screen, but also want morph to react on mouse > over/clicks only if mouse cursor is inside a circle, but not > when it's over an area covered by rectangle. > > > > What it means, that from UI perspective, you want from morph > to define its shape, lets call it 'UI interaction shape'.. and > from that perspective 'self shape:' is a good choice. But as > example says, it has nothing to do with 'drawing shape(s)', > which may or may not coincide with shape you using for UI > interaction(s). > > > > Because it defines an area, where UI stuff could happen. And > indeed, you really need one, and only one. You don't need > multiple shapes there, since it serves to answer a simple > question: 'are my mouse in interesting region or not'?. > > Like in your case, when you having box with circle inside , > which is two shapes, but only one shape that can define an > interesting region, it could be: > > - intersection of > > - union > > - subtraction > > > > And that could be completely different from shape(s) you may > need to draw it on the screen. > > > > Stef > > > >> On Apr 2, 2016 4:57 PM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > >> Hi > >> > >> I want a square morph with a circle or a line at 45 degree > inside > >> Now I do not get it. > >> > >> I thought that I needed to specialize drawOnAthensCanvas: > so I did > >> > >> BlCell >> drawOnAthensCanvas: aCanvas > >> > >> super drawOnAthensCanvas: aCanvas. > >> aCanvas > >> drawShape: (BlShape new > >> strokePaint: > >> (BlStrokePaint new > >> paint: (BlColorPaint new color: (Color blue)); > >> width: 15); > >> path: BlCirclePath new). > >> > >> Now I do not know how I can specify a shape size > >> > >> So I will use another API than drawShape: > >> > >> Stef > >> > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Reasonable is what we are accustomed with." > > > > > > -- > Best regards, > Igor Stasenko. >

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Aliaksei Syrel

> > 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? .. 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? :) Cheers, Alex On Sun, Apr 3, 2016 at 3:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 3 April 2016 at 16:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> On 3 April 2016 at 15:28, Glenn CavarlÃ© <glenn(a)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. >

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 16:20, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 3 April 2016 at 15:28, Glenn CavarlÃ© <glenn(a)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.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 15:28, Glenn CavarlÃ© <glenn(a)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? :) > > 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.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Glenn CavarlÃ©

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

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Denis Kudriashov

2016-04-03 14:23 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I agree. But Igor shows trivial example: label with rectangle background. I remember in PharoDays you show text with different background shapes. It was composition of elements?

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Denis Kudriashov

2016-04-03 12:27 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > 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). > > Do you agree with that and also that in most cases we want to change them > all together just sending one message? :) > I agree. But Igor shows trivial example: label with rectangle background.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 14:37, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > I completely agree with you now, Igor :) > > The idea that I *proposed* during Pharo days is to make BlShape > polymorphic with what athens have. I did not implement it yet I work on it > just right now. > > I suppose that I explained me wrong to Stef and he started thinking that > it is *already* implemented. On my road back from Pharo days I started > working on what Stef wanted to do yesterday. > > I my example I just wanted to show Stef how he can solve his problem just > right now, without saying "Oh, Stef, you know, please wait one more week". > > Also that was the idea why I started implementing own implementation of > Athens Api and named it Sparta. Specifically to remove amount of > shapes/pathes/paints used in Bloc. I was planning to finish it before I > send an announcement email to pharo mailing list saying officially that > bloc is released to alpha. > Can you shed more light on this? I need your motivation/reasoning behind it. I tried in Athens to keep a minimal set of protocol(s), so that there's no need to learn numerous methods to start using it. The shapes/paints thing is central in Athens.. so, if you see how it can be made even simpler, i am all ears to hear details. In any case, what i can tell from your statement above is to remove unnecessary bloat.. which is always welcome. But why that requires changes in Athens API, instead of changes in Bloc? > > I discussed it on Pharo days and we agreed to wait until announcement. > And now I'm frustrated that people don't listen to me and try to use > product before official release just in the middle of refactoring. > > No, i am not using it, yet.. The only 'people' was Stef himself :) > What you are stating in this discussion will be implemented early or later. > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 14:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 3 April 2016 at 13:18, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hi >> >> 2016-04-03 11:08 GMT+02:00 Aliaksei Syrel <alex.syrel(a)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. >> >> > In short, i see only two cases where indeed, morph requires a nothing of > s/nothing/notion > shapes to define: > - clipping region(s) > - ui interaction region(s) > > but for drawing? nooooo... really? who cares what you draw there? > draw anything, in any possible way you see fit.. compose, decompose, > recombine, blend and mix.. that's the whole purpose of drawing and be > artistic and be able to express yourself in any possible way you want :) > Why nailing and formalizing things that are tend to be hardly formalizable > and more than that, unnecessary. > That's my main concern about current design. > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

April 3, 2016