2017-11-12 16:10 GMT+01:00 Tudor Girba <tu...@tudorgirba.com>: > > > On Nov 12, 2017, at 4:00 PM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > > > > 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. > > 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 <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." > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Be rather willing to give than demanding to get." > > > > > >
