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 <dionisi...@gmail.com> wrote: > > Hi Aliaksei > > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.sy...@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 <s...@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."
