2017-11-11 22:39 GMT+01:00 Tudor Girba <tu...@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 <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." > > > > > >
