A good trick to get the same is to have self inspect in the buttons or widgets you are developing/using.
Stef On Sun, Nov 12, 2017 at 6:42 PM, Todd Blanchard <tblanch...@mac.com> wrote: > 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> 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." >> >> >> >> >> > >
