[Pharo-dev] feenk log

Stephane Ducasse stepharo.self at gmail.com
Sun Nov 12 13:41:21 EST 2017


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 <tblanchard at 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 <btc at 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 <tudor at 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 <dionisiydk at gmail.com>
>> > wrote:
>> >
>> > Hi Aliaksei
>> >
>> > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel <alex.syrel at 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 <sean at 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."
>>
>>
>>
>>
>>
>
>




More information about the Pharo-dev mailing list