Hi, Over the past couple of weeks Alex worked on stabilizing a first beta01 version for Pharo 6.1: https://twitter.com/feenkcom/status/929031849879461889 This is available as a beta01 tag in the pharo61 branch here: https://github.com/pharo-graphics/Bloc/tree/beta01 The main readme was updated with instructions and links: https://github.com/pharo-graphics/Bloc An overview of the improvements: - improved animations support that also works for scaling https://twitter.com/feenkcom/status/927617393194610693 - improved debugging support for transformations https://twitter.com/feenkcom/status/926040946130612224 - support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808 - updated MemoryGame tutorial: http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf https://github.com/pharo-graphics/Tutorials - extended examples that offer a 52% coverage - new Bloc world menu for easily accessing Bloc examples and reseting the Universe Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."
Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Sean, Why not `anElement simulateClick`? Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that. First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue. Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space *class* to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this: BlSpace simulateClickOn: element. In english it is quite nice: "dear space class, could you, please, simulate a click event on a given element?" *It is a space who simulates event, not an element.* P.S. Users can still send a BlClickEvent directly (informs 'click'): element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new Cheers, Alex On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 10-11-17 22:36, Aliaksei Syrel wrote:
To wrap up, we decided that it should be a responsibility of the Space _class_ to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
The adding of BlElements to the space, and setting up their responsibilities (to e.g. registering to send announcements to domain model objects, and receive them) is normally the responsibility of an object outside the space, I assume. Also, the creation of temporary instances of itself raises the question of exactly what to copy. Please elaborate a bit on the consequences of this for application and test design. Cheers, Stephan
Hi Aliaksei 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space *class* to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" *It is a space who simulates event, not an element.*
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Denis, It is not a global function. It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one. The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements. Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."
BTW doru Class comments are important Look at the comment of BlSpace. I did not know that it was limited to a window. On Sat, Nov 11, 2017 at 10:39 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
2017-11-11 22:39 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Ok. Thank's for explanation. But still when I see such class side methods I have some bad feeling.
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. html
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
On Nov 12, 2017, at 4:00 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-11-11 22:39 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Ok. Thank's for explanation. But still when I see such class side methods I have some bad feeling.
Do you see another solution in this case? Doru
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
-- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."
2017-11-12 16:10 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
On Nov 12, 2017, at 4:00 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-11-11 22:39 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Ok. Thank's for explanation. But still when I see such class side methods I have some bad feeling.
Do you see another solution in this case?
Sean suggest to ask element for this: element simulateClick But Alex explained why it is done differently. Maybe simulation logic can be extracted to another object. So it can be like: element simulate click where #simulate returns simulator which incapsulates decision what space should be used. It can be even two kind of simulators: existing space simulator and temp space simulator. Also with this approach BlSpace class will be not polluted by all kind of event simulations.
From the other side I don't know the internals. So I can imaging that current solution is more suitable for now.
Doru
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com>
wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >>
#simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally
simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too...
That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. html
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
-- www.tudorgirba.com www.feenk.com
"Be rather willing to give than demanding to get."
A feature I believe would be useful is to help a user to dig into the application code behind a button (e.g. Hierarchy button). This would help discoverability of the system. I learnt a lot using Halos>Debug but it's a bit tedious deciphering from the instance variables what system application code ends up beign invoked. I flirted a bit with adding a <Simulate Click> item next to Halos>Debug, but that ended up first tracing through dozens of mouse dispatch calls, which wasn't appealing for the purpose I wanted... to have a shortcut into the application code. Perhaps the way to do it would be silently tracing through the dispatch code until a particular pragma is reached - but I didn't get that far with it. I think quick access to the application code would enhance the liveness of the system. Wdyt? Cheers -ben On Sun, Nov 12, 2017 at 5:39 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. html
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
The most productive environment I have ever used was Hypercard and that was because you could cmd-opt click on any button or field or UI element and the script for that would open and you could edit it. I have always wanted that in Smalltalk.
On Nov 12, 2017, at 9:10 AM, Ben Coman <btc@openinworld.com> wrote:
A feature I believe would be useful is to help a user to dig into the application code behind a button (e.g. Hierarchy button). This would help discoverability of the system. I learnt a lot using Halos>Debug but it's a bit tedious deciphering from the instance variables what system application code ends up beign invoked.
I flirted a bit with adding a <Simulate Click> item next to Halos>Debug, but that ended up first tracing through dozens of mouse dispatch calls, which wasn't appealing for the purpose I wanted... to have a shortcut into the application code. Perhaps the way to do it would be silently tracing through the dispatch code until a particular pragma is reached - but I didn't get that far with it. I think quick access to the application code would enhance the liveness of the system. Wdyt?
Cheers -ben
On Sun, Nov 12, 2017 at 5:39 AM, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808 <https://twitter.com/feenkcom/status/925672206763511808>
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Obvious things are difficult to teach."
A good trick to get the same is to have self inspect in the buttons or widgets you are developing/using. Stef On Sun, Nov 12, 2017 at 6:42 PM, Todd Blanchard <tblanchard@mac.com> wrote:
The most productive environment I have ever used was Hypercard and that was because you could cmd-opt click on any button or field or UI element and the script for that would open and you could edit it.
I have always wanted that in Smalltalk.
On Nov 12, 2017, at 9:10 AM, Ben Coman <btc@openinworld.com> wrote:
A feature I believe would be useful is to help a user to dig into the application code behind a button (e.g. Hierarchy button). This would help discoverability of the system. I learnt a lot using Halos>Debug but it's a bit tedious deciphering from the instance variables what system application code ends up beign invoked.
I flirted a bit with adding a <Simulate Click> item next to Halos>Debug, but that ended up first tracing through dozens of mouse dispatch calls, which wasn't appealing for the purpose I wanted... to have a shortcut into the application code. Perhaps the way to do it would be silently tracing through the dispatch code until a particular pragma is reached - but I didn't get that far with it. I think quick access to the application code would enhance the liveness of the system. Wdyt?
Cheers -ben
On Sun, Nov 12, 2017 at 5:39 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Denis,
It is not a global function.
It is a class-side method because it relies on the following logic: - if the element is attached to a space, it uses that space to dispatch the event. - otherwise, it creates a temporary space and uses that one.
The use case for such simulators is needed in the case of overlapping elements. In most cases, such as in a grid layout, the elements do not overlap, so clicking on the position occupied by an element will always lead to a high level click event dispatched to that element. However, when we have overlapping elements, clicking on the position of an element might end up dispatched to another element. In fact, we introduced this testing ability exactly to write a red test involving overlapping elements.
Cheers, Doru
On Nov 11, 2017, at 11:35 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Aliaksei
2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>: Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
It looks like global function. According to your description I would expect: aSpace simulateClickOn: element
I imaging tests where I create internal space instance, open application in it and simulate events to check expected behaviour. But maybe you will explain that it should be done differently? And what is actual use case for such simulations if we can just #fireEvent: as you wrote below?
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote: Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
Nice explanation. Aliaksei do you add it to the BLSpace class comment? Stef On Fri, Nov 10, 2017 at 10:36 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Sean,
Why not `anElement simulateClick`?
Good question :) We indeed evaluated a possibility to have (BlElement >> #simulateClick) but then decided to make BlSpace class to be responsible for that.
First we should realise that when we simulate a click we do literally simulate user's action which is: mouseDown at some global coordinate in space and then mouseUp. A process of handing mouse down/up events involves some complex event processing in order to detect what should happen, for example, with currently focused element or if we need to send double-click event. It is a mouse processor who is responsible for all these actions and it belongs to Space (inst. var in space). Not to mention some weird cases of overlapped elements, elements with custom elevation (zIndex), custom mouseDown/up event listeners that do some work too... That is why it is definitely not enough just to send a plain BlClickEvent directly to the element. Instead, we should involve a space in the process and actually simulate it by pushing mouseDown and mouseUp events to the event queue.
Next what we realised it the fact that it is not nice to always create a temporary space and add our element to it in order to simulate a click. What if an element is already added to the space, what if not? To wrap up, we decided that it should be a responsibility of the Space class to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this:
BlSpace simulateClickOn: element.
In english it is quite nice:
"dear space class, could you, please, simulate a click event on a given element?" It is a space who simulates event, not an element.
P.S. Users can still send a BlClickEvent directly (informs 'click'):
element := BlElement new. element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ]. element fireEvent: BlClickEvent new
Cheers, Alex
On 10 November 2017 at 21:22, Sean P. DeNigris <sean@clipperadams.com> wrote:
Tudor Girba-2 wrote
- support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808
Why not `anElement simulateClick`?
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Thanks Doru this is cool to see this happening. Stef On Fri, Nov 10, 2017 at 7:47 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Over the past couple of weeks Alex worked on stabilizing a first beta01 version for Pharo 6.1: https://twitter.com/feenkcom/status/929031849879461889
This is available as a beta01 tag in the pharo61 branch here: https://github.com/pharo-graphics/Bloc/tree/beta01
The main readme was updated with instructions and links: https://github.com/pharo-graphics/Bloc
An overview of the improvements: - improved animations support that also works for scaling https://twitter.com/feenkcom/status/927617393194610693 - improved debugging support for transformations https://twitter.com/feenkcom/status/926040946130612224 - support for programatic testing of bloc mouse events: https://twitter.com/feenkcom/status/925672206763511808 - updated MemoryGame tutorial: http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf https://github.com/pharo-graphics/Tutorials - extended examples that offer a 52% coverage - new Bloc world menu for easily accessing Bloc examples and reseting the Universe
Cheers, The feenk team
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
participants (8)
-
Aliaksei Syrel -
Ben Coman -
Denis Kudriashov -
Sean P. DeNigris -
stephan -
Stephane Ducasse -
Todd Blanchard -
Tudor Girba