I realize it's a fast-moving work in progress, but what's the best way to try to understand the system? For example, I saw class comments, some of which seem to be out of date, and I no longer see many of the examples I remember from last year - maybe I have to load them separately? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Documentation-tp4876448.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system? On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
I realize it's a fast-moving work in progress, but what's the best way to try to understand the system?
For example, I saw class comments, some of which seem to be out of date, and I no longer see many of the examples I remember from last year - maybe I have to load them separately?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Documentation-tp4876448.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 09 Feb 2016, at 09:15, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system?
mmm⦠thatâs a bad question because I would answer âall of themâ, but I understand you want to do a step to make easy for us to understand so my answer has to be âthe important onesâ, but since there is no documentation/class comments/examples I just cannot know which them, so is up to you (and people doing bloc) to tell us which are âthe important onesâ⦠by adding class comments and examples! :D Esteban
On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote: I realize it's a fast-moving work in progress, but what's the best way to try to understand the system?
For example, I saw class comments, some of which seem to be out of date, and I no longer see many of the examples I remember from last year - maybe I have to load them separately?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Documentation-tp4876448.html <http://forum.world.st/Bloc-Documentation-tp4876448.html> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Tue, Feb 9, 2016 at 11:39 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
mmm⦠thatâs a bad question because I would answer âall of themâ, but I understand you want to do a step to make easy for us to understand so my answer has to be âthe important onesâ, but since there is no documentation/class comments/examples I just cannot know which them, so is up to you (and people doing bloc) to tell us which are âthe important onesâ⦠by adding class comments and examples! :D
It depends :) There are a lot of obvious places in Bloc that do not necessarily need documentation to understand them. For example events. BlLostMouseFocusEvent does not need any "serious" documentation in first place. If you want to find out when it is being sent it is much faster to do cmd+n then read long class doc. I don't want to say that we don't need documentation.. I just want to say that with amount of available man-power we can't instantly add documentation to everything in bloc. So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey. Cheers, Alex
formerOwner: anElementOrNil "Set my former or remove property of argument is nil" anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ] I'd prefer to see a #setProperty:toValueOrRemove: there, as that pattern is used a lot. Stephan
formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v) Basically it should be removed after reimplementation of drag&drop mechanism. Current one was copied from morphic to support compatibility. We will need to find better solution. Drag&drop is not so easy to do right. Help from community is appreciated :) Cheers, Alex On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont <stephan@stack.nl> wrote:
formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I'd prefer to see a #setProperty:toValueOrRemove: there, as that pattern is used a lot.
Stephan
Please add a comment in the method stating it. People are not reading your mind. Stef Le 9/2/16 13:25, Aliaksei Syrel a écrit :
formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v) Basically it should be removed after reimplementation of drag&drop mechanism. Current one was copied from morphic to support compatibility. We will need to find better solution. Drag&drop is not so easy to do right. Help from community is appreciated :)
Cheers, Alex
On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote:
formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I'd prefer to see a #setProperty:toValueOrRemove: there, as that pattern is used a lot.
Stephan
Please add a comment in the method stating it. People are not reading your mind.
I know :) I'm arguing that some classes/method could wait. We need to concentrate on most important ones. And then come to the rest. On Tue, Feb 9, 2016 at 1:52 PM, stepharo <stepharo@free.fr> wrote:
Please add a comment in the method stating it. People are not reading your mind.
Stef
Le 9/2/16 13:25, Aliaksei Syrel a écrit :
formerOwner: anElementOrNil
"Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v) Basically it should be removed after reimplementation of drag&drop mechanism. Current one was copied from morphic to support compatibility. We will need to find better solution. Drag&drop is not so easy to do right. Help from community is appreciated :)
Cheers, Alex
On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont < <stephan@stack.nl> stephan@stack.nl> wrote:
formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I'd prefer to see a #setProperty:toValueOrRemove: there, as that pattern is used a lot.
Stephan
Hello, yes, #formerOwner: and #formerPosition: are here for compatibility with Morphic. and it will be like that for a while :) The bloc drag&drop mechanism is implemented differently with the help of events. Cheers Alain
On 9 févr. 2016, at 13:25, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v) Basically it should be removed after reimplementation of drag&drop mechanism. Current one was copied from morphic to support compatibility. We will need to find better solution. Drag&drop is not so easy to do right. Help from community is appreciated :)
Cheers, Alex
On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont <stephan@stack.nl> wrote: formerOwner: anElementOrNil "Set my former or remove property of argument is nil"
anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ]
I'd prefer to see a #setProperty:toValueOrRemove: there, as that pattern is used a lot.
Stephan
On 09/02/16 11:53, Aliaksei Syrel wrote:
So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey.
A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again? Stephan
A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again?
Exactly! :) We just physically can't do everything so fast. It will come! Patience, patience :) Nevertheless pointing to issues is very helpful, keep doing it Cheers, Alex On Tue, Feb 9, 2016 at 1:24 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 09/02/16 11:53, Aliaksei Syrel wrote:
So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey.
A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again?
Stephan
On 9 févr. 2016, at 13:24, Stephan Eggermont <stephan@stack.nl> wrote:
On 09/02/16 11:53, Aliaksei Syrel wrote:
So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey.
A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again?
yes, it should be easy to adapt it to the current Bloc implementation. I will reimplement examples. And you will see that things are nearly the same regarding Bloc user point of view. Cheers Alain
Stephan
and please, do not ask too much to Alex. Alex is doing a pass (great job), and (I guess) he is doing it alone. I will come back to Pharo and Bloc in two weeks, reimplement examples and adapt the first Bloc documentation that we did with Stephane. Then it will be easier for the community to help. Cheers Alain
On 9 févr. 2016, at 14:26, Alain Plantec <alain.plantec@yahoo.com> wrote:
On 9 févr. 2016, at 13:24, Stephan Eggermont <stephan@stack.nl> wrote:
On 09/02/16 11:53, Aliaksei Syrel wrote:
So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey.
A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again?
yes, it should be easy to adapt it to the current Bloc implementation. I will reimplement examples. And you will see that things are nearly the same regarding Bloc user point of view. Cheers Alain
Stephan
Le 9/2/16 11:53, Aliaksei Syrel a écrit :
On Tue, Feb 9, 2016 at 11:39 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
mmm⦠thatâs a bad question because I would answer âall of themâ, but I understand you want to do a step to make easy for us to understand so my answer has to be âthe important onesâ, but since there is no documentation/class comments/examples I just cannot know which them, so is up to you (and people doing bloc) to tell us which are âthe important onesâ⦠by adding class comments and examples! :D
It depends :) There are a lot of obvious places in Bloc that do not necessarily need documentation to understand them. For example events. BlLostMouseFocusEvent does not need any "serious" documentation in first place. If you want to find out when it is being sent it is much faster to do cmd+n then read long class doc. I don't want to say that we don't need documentation.. I just want to say that with amount of available man-power we can't instantly add documentation to everything in bloc.
Sorry but if the class has an example and a comment stating. If you want to react to LostMouseFocus do it like that self eventListener: #LostMouseFocus Then this is just great. So a comment is not only about what the class does but how to use it. Stef
So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey.
Cheers, Alex
On Tue, Feb 9, 2016 at 4:15 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system?
On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
I realize it's a fast-moving work in progress, but what's the best way to try to understand the system?
For example, I saw class comments, some of which seem to be out of date, and I no longer see many of the examples I remember from last year - maybe I have to load them separately?
Maybe... How about starting with some old fashioned hand sketches, scanned, with maybe some audio attached to the static image describing the architecture would give people the quickest start. Just like you were introducing someone new who was sitting next to you -- but for those of us aroudn the world who can't make there ;). Or maybe (??) do an adhoc whiteboard presentation to a few people locally that you video. It doesn't need to be nicely edited. These might be quicker than sitting down to write class comments - and maybe others can assist by extracting class comments from this material. cheers -ben
On 09-02-16 09:15, Aliaksei Syrel wrote:
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system?
I'm looking at the examples of BlElement for upgrading Bloc-DragPanels. I'd expect BlElement to have a default eventlistener that allows moving the morphs around? Stephan
On 09-02-16 09:15, Aliaksei Syrel wrote:
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system?
In BlElement class>exampleAdvancedClipping there is twice addEventListener: (BlPluggableEventListener new whenMouseMoveDo: [ :event | event resumeBubbling ]); I'm not sure why the second one is needed. If this is needed a lot, I'd prefer #propagateEvent: #mouseMove or something like that. Stephan
I'm looking at the examples of BlElement for upgrading Bloc-DragPanels. I'd expect BlElement to have a default eventlistener that allows moving the morphs around?
There is a bug and I disabled this behaviour. If you want to enable it uncomment line in BlPasteUpEventListener>>startSlide: or just add BlDraggingEventListener that implements dragging without adding to the hand. In BlElement class>exampleAdvancedClipping there is twice
addEventListener: (BlPluggableEventListener new whenMouseMoveDo: [ :event | event resumeBubbling ]);
It is a bug. If element has children mouse move event is not fired P.S. thanks for bug reports on tracker :) On Wed, Feb 10, 2016 at 3:06 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 09-02-16 09:15, Aliaksei Syrel wrote:
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system?
In BlElement class>exampleAdvancedClipping there is twice
addEventListener: (BlPluggableEventListener new whenMouseMoveDo: [ :event | event resumeBubbling ]);
I'm not sure why the second one is needed. If this is needed a lot, I'd prefer #propagateEvent: #mouseMove or something like that.
Stephan
Aliaksei Syrel wrote
Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system?
I think for me the most important thing would be to have a short description of the overall design, especially if it included the rationale. One thing I think that doomed Morphic is that, because there was no evidence as to why things were done a certain way, one was terrified to change anything lest it be vitally important and misunderstood. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Documentation-tp4876448p4876965.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (7)
-
Alain Plantec -
Aliaksei Syrel -
Ben Coman -
Esteban Lorenzano -
Sean P. DeNigris -
Stephan Eggermont -
stepharo