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