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