[Pharo-dev] feenk log

[Tudor Girba]

Hi,

We again got carried away and forgot to update the world about what is up in 
our corner. Here is a summary:

--
Bloc & Brick
--

- Text editor stability has been significantly improved
- Improved support for selection in the text editor
- Support for typical editing keybindings (copy, cut, paste)
- Text editor debuggability:
https://twitter.com/feenkcom/status/1024680215379959808
https://twitter.com/feenkcom/status/1020768298017992704
- The text editor can handle emojis:
https://twitter.com/feenkcom/status/1021872214151507968

--
GT
--

- Inspector
We now have an initial version of a working inspector with resizable panes:
https://twitter.com/feenkcom/status/1030091849795612672
https://twitter.com/feenkcom/status/1030314856736538624
It shows a display string for the current object:
https://twitter.com/feenkcom/status/1024564065870512129
It can handle errors in the definition of views gracefully:
https://twitter.com/feenkcom/status/1009174937217720320
We now have multiple extensions expressed in the new Inspector:
https://twitter.com/feenkcom/status/1024321868566814720
https://twitter.com/feenkcom/status/1022393383850008576

- Documenter saw multiple enhancements.
We can now resize various previews live:
https://twitter.com/feenkcom/status/1002851190475026432
https://twitter.com/feenkcom/status/1001407762285375490
https://twitter.com/feenkcom/status/1001152789874167808
It now relies on the annotation mechanism from Pillar:
https://twitter.com/feenkcom/status/1006508725409079298
We can now link classes and expand their definition:
https://twitter.com/feenkcom/status/1014609460520775681
https://twitter.com/feenkcom/status/1029085603948843008
The preview of examples can handle errors gracefully:
https://twitter.com/feenkcom/status/1022123808524836864
We can run examples in place, enabling a smoother tutorial experience:
https://twitter.com/feenkcom/status/1028390957023223809
We have new documentation expressed in it:
https://twitter.com/feenkcom/status/100700881420672



Have fun,
The feenk team

--
www.feenk.com

"Presenting is storytelling."

Re: [Pharo-dev] feenk log

[Norbert Hartl]

Very impressive!! Hope Bloc and Brick move along to be included in pharo soon!!

Norbert

> Am 25.05.2018 um 13:30 schrieb Tudor Girba :
> 
> Hi,
> 
> We were a bit silent the last couple of months. Quite a bit happened in the 
> meantime, so here is a summary (for more fine grained announcements, you can 
> follow us on Twitter):
> 
> 
> Bloc
> 
> 
> - Scrolling. We finally have a good scrolling support:
> https://twitter.com/feenkcom/status/991690465224331264
> This might sound like a trivial feature, but it turns out it is not. We had a 
> bug that forced us to rethink the support quite deeply in order to be able to 
> debug it. To do this, we now can simulate time in Bloc, which is really cool:
> https://twitter.com/feenkcom/status/989797367523233797
> https://twitter.com/feenkcom/status/988753142299938817
> (as a side note, the bug we fought with was the last 
> 
> - Pannable element is a combination of a scrollable element with a scalable 
> element, and it offers the possibility either to zoom in/out + scroll, or to 
> fit screen and resize when the parent resizes.
> 
> - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support):
> https://twitter.com/feenkcom/status/976580153802358786
> https://twitter.com/feenkcom/status/976578060429484032
> 
> - Better curve support:
> https://twitter.com/feenkcom/status/990967109193781249
> https://twitter.com/feenkcom/status/990971530615107584
> 
> - Better debugging support for understanding bounds:
> https://twitter.com/feenkcom/status/989138457288167424
> 
> 
> Brick
> 
> 
> - We now have simple list and columned list widgets. The list is both fast 
> and scalable and supports rows of variable heights:
> https://twitter.com/feenkcom/status/984744251920658432
> https://twitter.com/feenkcom/status/984143821192744961
> 
> - Basic tab widget:
> https://twitter.com/feenkcom/status/974420432240685062
> 
> - Looks: a mechanism for specifying element-specific composition and 
> interaction.
> 
> 
> GT
> 
> 
> - Documenter saw some major improvements. Just a reminder, Documenter is the 
> tool that enables live programming and previews directly within Pillar 
> documents.
> We now have a capability similar to notebooks like Jupyter:
> https://twitter.com/feenkcom/status/996310432225820672
> We use it extensively to document our code. For example, here is a tutorial 
> about playing with looks in Bloc:
> https://twitter.com/feenkcom/status/973899862482866176
> And we can also express whole tutorials based on Epicea:
> https://twitter.com/feenkcom/status/75333972541440
> 
> - Diagrammer. We now have better editing support for detailed things such as 
> arrow head:
> https://twitter.com/feenkcom/status/976341449267531776
> While Diagrammer is apparently a tool for diagrams, it has a rather generic 
> design that can be utilized for all sorts of use cases. For example, one side 
> effect is that now all elements can be visually edited:
> https://twitter.com/feenkcom/status/982656456968241152
> 
> - Mondrian: Using the new pannable element, we can now zoom in/out and 
> scroll, and we can also set element to fit screen. We can also drag elements 
> around.
> 
> - Inspector: we now have an initial support for multiple views associated 
> with an object. The support is similar to the one from the current inspector. 
> 
> 
> Have fun,
> The feenk team
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "What is more important: To be happy, or to make happy?"
> 
> 

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

Hi Tudor.

Very impressive progress.
I have one question about scrolling support. How it works or is it works
with elements which are based on infinite layout like mentioned grid
widget?
Does grid implemented with PannableElement too?



2018-05-25 14:30 GMT+03:00 Tudor Girba :

> Hi,
>
> We were a bit silent the last couple of months. Quite a bit happened in
> the meantime, so here is a summary (for more fine grained announcements,
> you can follow us on Twitter):
>
> 
> Bloc
> 
>
> - Scrolling. We finally have a good scrolling support:
> https://twitter.com/feenkcom/status/991690465224331264
> This might sound like a trivial feature, but it turns out it is not. We
> had a bug that forced us to rethink the support quite deeply in order to be
> able to debug it. To do this, we now can simulate time in Bloc, which is
> really cool:
> https://twitter.com/feenkcom/status/989797367523233797
> https://twitter.com/feenkcom/status/988753142299938817
> (as a side note, the bug we fought with was the last
>
> - Pannable element is a combination of a scrollable element with a
> scalable element, and it offers the possibility either to zoom in/out +
> scroll, or to fit screen and resize when the parent resizes.
>
> - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support):
> https://twitter.com/feenkcom/status/976580153802358786
> https://twitter.com/feenkcom/status/976578060429484032
>
> - Better curve support:
> https://twitter.com/feenkcom/status/990967109193781249
> https://twitter.com/feenkcom/status/990971530615107584
>
> - Better debugging support for understanding bounds:
> https://twitter.com/feenkcom/status/989138457288167424
>
> 
> Brick
> 
>
> - We now have simple list and columned list widgets. The list is both fast
> and scalable and supports rows of variable heights:
> https://twitter.com/feenkcom/status/984744251920658432
> https://twitter.com/feenkcom/status/984143821192744961
>
> - Basic tab widget:
> https://twitter.com/feenkcom/status/974420432240685062
>
> - Looks: a mechanism for specifying element-specific composition and
> interaction.
>
> 
> GT
> 
>
> - Documenter saw some major improvements. Just a reminder, Documenter is
> the tool that enables live programming and previews directly within Pillar
> documents.
> We now have a capability similar to notebooks like Jupyter:
> https://twitter.com/feenkcom/status/996310432225820672
> We use it extensively to document our code. For example, here is a
> tutorial about playing with looks in Bloc:
> https://twitter.com/feenkcom/status/973899862482866176
> And we can also express whole tutorials based on Epicea:
> https://twitter.com/feenkcom/status/75333972541440
>
> - Diagrammer. We now have better editing support for detailed things such
> as arrow head:
> https://twitter.com/feenkcom/status/976341449267531776
> While Diagrammer is apparently a tool for diagrams, it has a rather
> generic design that can be utilized for all sorts of use cases. For
> example, one side effect is that now all elements can be visually edited:
> https://twitter.com/feenkcom/status/982656456968241152
>
> - Mondrian: Using the new pannable element, we can now zoom in/out and
> scroll, and we can also set element to fit screen. We can also drag
> elements around.
>
> - Inspector: we now have an initial support for multiple views associated
> with an object. The support is similar to the one from the current
> inspector.
>
>
> Have fun,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What is more important: To be happy, or to make happy?"
>
>
>

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

We were a bit silent the last couple of months. Quite a bit happened in the 
meantime, so here is a summary (for more fine grained announcements, you can 
follow us on Twitter):


Bloc


- Scrolling. We finally have a good scrolling support:
https://twitter.com/feenkcom/status/991690465224331264
This might sound like a trivial feature, but it turns out it is not. We had a 
bug that forced us to rethink the support quite deeply in order to be able to 
debug it. To do this, we now can simulate time in Bloc, which is really cool:
https://twitter.com/feenkcom/status/989797367523233797
https://twitter.com/feenkcom/status/988753142299938817
(as a side note, the bug we fought with was the last 

- Pannable element is a combination of a scrollable element with a scalable 
element, and it offers the possibility either to zoom in/out + scroll, or to 
fit screen and resize when the parent resizes.

- PDF, SVG, PNG, JPG export (based on the underlying Moz2D support):
https://twitter.com/feenkcom/status/976580153802358786
https://twitter.com/feenkcom/status/976578060429484032

- Better curve support:
https://twitter.com/feenkcom/status/990967109193781249
https://twitter.com/feenkcom/status/990971530615107584

- Better debugging support for understanding bounds:
https://twitter.com/feenkcom/status/989138457288167424


Brick


- We now have simple list and columned list widgets. The list is both fast and 
scalable and supports rows of variable heights:
https://twitter.com/feenkcom/status/984744251920658432
https://twitter.com/feenkcom/status/984143821192744961

- Basic tab widget:
https://twitter.com/feenkcom/status/974420432240685062

- Looks: a mechanism for specifying element-specific composition and 
interaction.


GT


- Documenter saw some major improvements. Just a reminder, Documenter is the 
tool that enables live programming and previews directly within Pillar 
documents.
We now have a capability similar to notebooks like Jupyter:
https://twitter.com/feenkcom/status/996310432225820672
We use it extensively to document our code. For example, here is a tutorial 
about playing with looks in Bloc:
https://twitter.com/feenkcom/status/973899862482866176
And we can also express whole tutorials based on Epicea:
https://twitter.com/feenkcom/status/75333972541440

- Diagrammer. We now have better editing support for detailed things such as 
arrow head:
https://twitter.com/feenkcom/status/976341449267531776
While Diagrammer is apparently a tool for diagrams, it has a rather generic 
design that can be utilized for all sorts of use cases. For example, one side 
effect is that now all elements can be visually edited:
https://twitter.com/feenkcom/status/982656456968241152

- Mondrian: Using the new pannable element, we can now zoom in/out and scroll, 
and we can also set element to fit screen. We can also drag elements around.

- Inspector: we now have an initial support for multiple views associated with 
an object. The support is similar to the one from the current inspector. 


Have fun,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"What is more important: To be happy, or to make happy?"

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

Here is an update of the work on Bloc, Brick and GT. As always, please do let 
us know what you think.

Bloc:
- Improved the deletion in the text editor and covered the scenarios with 
examples
- Worked on the text selection. Still work needed for selection to be 
production ready:
https://twitter.com/feenkcom/status/969183393547259905
- Balanced rope structure for even better performance of the editor. Overall, 
the performance of the text editor improved 2x.
https://twitter.com/feenkcom/status/971009488789516288
- Selectable curves:
https://twitter.com/feenkcom/status/967690664589910016

Brick:
- Resizer overlay. The tweet below also shows how we can now easily script 
dragging behavior in examples:
https://twitter.com/feenkcom/status/971990195011690496

GToolkit:
- Diagrammer is a new engine for drawing diagrams based on Bloc. This is the 
first version, and we will continue working on it in the following weeks, so 
stay tuned for more news. This is also one of the first Bloc applications:
https://twitter.com/feenkcom/status/972243179599794180
- Andrei put together a beautiful description of a scenario in which an 
application is molded interactively in the Playground & Inspector. The subject 
is face recognition, and the resulting code is both functional and explainable. 
This is intended as a tutorial material that shows what moldable development 
means and how it changes the way we program:
https://twitter.com/feenkcom/status/972907051448979458

Have fun,
The feenk team
www.feenk.com









--
www.tudorgirba.com
www.feenk.com

"To utilize feedback, you first have to acquire it."

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

Here is an update of the work on Bloc and GT. As always, please do let us know 
what you think.

Bloc:
- Eventing saw a deep overhaul. They are now dispatched using the Announcements 
engine. The previous mechanism is still in place in order to help people 
compare the impact. In the process, we also cleaned the propagation of events, 
and we made them debuggable through inspector extensions:
https://twitter.com/feenkcom/status/955086133519618048
https://twitter.com/feenkcom/status/946482609680539649
- Embedding Bloc elements in Morphic is even easier now:
https://twitter.com/feenkcom/status/946676667002556416
- We continued the work towards an interactive creation of a graphical scene:
https://twitter.com/feenkcom/status/948492946541858816
- Theme experiment

GT:
- The documentation of Mondrian is available when you download the code and can 
be viewed using GT Documenter:
https://twitter.com/feenkcom/status/939394586115563520
- The Mondrian extensions of BlElement are now extracted in a more general 
package that enables Bloc elements to be used in graph scenes.

Have fun,
The feenk team


--
www.tudorgirba.com
www.feenk.com

"Obvious things are difficult to teach."

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

Here is an update of the work on Bloc and GT:

Bloc:
- Bezier curves (cubic and quadratic).
https://twitter.com/feenkcom/status/93476564021504
https://twitter.com/feenkcom/status/934856909001252865

- Dragging is now possible through a BlDragHandler that can be attached to any 
element.

- Pixel accurate line heads and tails
https://twitter.com/feenkcom/status/936704646290305025

- More flexible scalable element.
https://twitter.com/feenkcom/status/934003681539907585

- Improved scalability of the rendering. For example, on Mac, we are on par 
with the speed of Firefox.
https://twitter.com/feenkcom/status/931462535861108736

- Sparta is now able to load custom fonts.
https://twitter.com/feenkcom/status/930919637214285824

- Text insertion works now much better. Deletion and Selection still require 
more work.

- The rope data structure can now be better inspected.
https://twitter.com/feenkcom/status/937298739584172032

- Sparta/Moz2D has a visual loader that also provides more specific details in 
case of errors.
https://twitter.com/feenkcom/status/936501909581688832

- Moz2D is now installed by default on Linux 64b.


GT:

- The GT Visualizer sub-project now contains two tools:

-- GT Mondrian is a graph visualization engine that is both performant and 
shows how Bloc works well for visualizations. More details in a follow up post.
https://twitter.com/feenkcom/status/937682660704563202

-- GT Connector is a new tool for browsing connected examples. More details 
about it in a follow up post.
https://twitter.com/feenkcom/status/936109463462965248


Enjoy,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant, 
it probably isn't."

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

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  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  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  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  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 
>> > wrote:
>> >
>> > Hi Aliaksei
>> >
>> > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
>> > 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'):
>> >

Re: [Pharo-dev] feenk log

[Todd Blanchard]

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  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  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  > 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  > > wrote:
> >
> > Hi Aliaksei
> >
> > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel  > >:
> > 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,

Re: [Pharo-dev] feenk log

[Ben Coman]

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  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  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 
> wrote:
> >
> > Hi Aliaksei
> >
> > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
> > 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 
> 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."
>
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

2017-11-12 16:10 GMT+01:00 Tudor Girba :

>
> > On Nov 12, 2017, at 4:00 PM, Denis Kudriashov 
> wrote:
> >
> > 2017-11-11 22:39 GMT+01:00 Tudor Girba :
> > 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 
> wrote:
> > >
> > > Hi Aliaksei
> > >
> > > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
> > > 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 
> wrote:
> > > Tudor Girba-2 wrote
> > > > - support for programatic testing of bloc mouse events:
> > > > https://twitter.com/feenkcom/status/925672206763511808
> > >
> > > Why not `anElement simulateClick`?
> > >
> > >
> > >
> > > -
> > > 

Re: [Pharo-dev] feenk log

[Tudor Girba]

> On Nov 12, 2017, at 4:00 PM, Denis Kudriashov  wrote:
> 
> 2017-11-11 22:39 GMT+01:00 Tudor Girba :
> 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?

Doru

> 
> Cheers,
> Doru
> 
> 
> > On Nov 11, 2017, at 11:35 AM, Denis Kudriashov  wrote:
> >
> > Hi Aliaksei
> >
> > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
> > 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  
> > 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."

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

2017-11-11 22:39 GMT+01:00 Tudor Girba :

> 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 
> wrote:
> >
> > Hi Aliaksei
> >
> > 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
> > 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 
> 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."
>
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

BTW doru
Class comments are important
Look at the comment of BlSpace. I did not know that it was limited to a window.



On Sat, Nov 11, 2017 at 10:39 PM, Tudor Girba  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  wrote:
>>
>> Hi Aliaksei
>>
>> 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
>> 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  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."
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Tudor Girba]

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  wrote:
> 
> Hi Aliaksei
> 
> 2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :
> 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  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."

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Nice explanation.
Aliaksei do you add it to the BLSpace class comment?

Stef

On Fri, Nov 10, 2017 at 10:36 PM, Aliaksei Syrel  wrote:
> 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.
>
> 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 
> 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
>>
>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Thanks Doru this is cool to see this happening.

Stef

On Fri, Nov 10, 2017 at 7:47 PM, Tudor Girba  wrote:
> Hi,
>
> Over the past couple of weeks Alex worked on stabilizing a first beta01 
> version for Pharo 6.1:
> https://twitter.com/feenkcom/status/929031849879461889
>
> This is available as a beta01 tag in the pharo61 branch here:
> https://github.com/pharo-graphics/Bloc/tree/beta01
>
> The main readme was updated with instructions and links:
> https://github.com/pharo-graphics/Bloc
>
> An overview of the improvements:
> - improved animations support that also works for scaling
> https://twitter.com/feenkcom/status/927617393194610693
> - improved debugging support for transformations
> https://twitter.com/feenkcom/status/926040946130612224
> - support for programatic testing of bloc mouse events:
> https://twitter.com/feenkcom/status/925672206763511808
> - updated MemoryGame tutorial:
> http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf
> https://github.com/pharo-graphics/Tutorials
> - extended examples that offer a 52% coverage
> - new Bloc world menu for easily accessing Bloc examples and reseting the 
> Universe
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "The coherence of a trip is given by the clearness of the goal."
>
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

Hi Aliaksei

2017-11-10 22:36 GMT+01:00 Aliaksei Syrel :

> 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 
> 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
>>
>>
>

Re: [Pharo-dev] feenk log

[stephan]

On 10-11-17 22:36, Aliaksei Syrel wrote:
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.


The adding of BlElements to the space, and setting up their 
responsibilities (to e.g. registering to send announcements to domain 
model objects, and receive them) is normally the responsibility of an 
object outside the space, I assume. Also, the creation of temporary 
instances of itself raises the question of exactly what to copy. Please 
elaborate a bit on the consequences of this for application and test design.


Cheers,
  Stephan

Re: [Pharo-dev] feenk log

[Aliaksei Syrel]

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.

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 
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
>
>

Re: [Pharo-dev] feenk log

[Sean P. DeNigris]

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

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

Over the past couple of weeks Alex worked on stabilizing a first beta01 version 
for Pharo 6.1:
https://twitter.com/feenkcom/status/929031849879461889

This is available as a beta01 tag in the pharo61 branch here:
https://github.com/pharo-graphics/Bloc/tree/beta01

The main readme was updated with instructions and links:
https://github.com/pharo-graphics/Bloc

An overview of the improvements:
- improved animations support that also works for scaling
https://twitter.com/feenkcom/status/927617393194610693
- improved debugging support for transformations
https://twitter.com/feenkcom/status/926040946130612224
- support for programatic testing of bloc mouse events:
https://twitter.com/feenkcom/status/925672206763511808
- updated MemoryGame tutorial:
http://files.pharo.org/books-pdfs/booklet-Bloc/2017-11-09-memorygame.pdf
https://github.com/pharo-graphics/Tutorials
- extended examples that offer a 52% coverage
- new Bloc world menu for easily accessing Bloc examples and reseting the 
Universe

Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi,

The BlScalableElement is a utility element that zooms the elements inside. 
Indeed, all elements can be transformed, but this is a low level ability. The 
ScalableElement allows us to think in terms of elements, and strategies of 
zooming.

The mouse wheel is an event issue that can be added on top.

Cheers,
Doru



> On Oct 27, 2017, at 4:50 AM, Ben Coman  wrote:
> 
> 
> 
> On Thu, Oct 26, 2017 at 4:00 AM, Tudor Girba  wrote:
> Hi,
> 
> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris  wrote:
> >
> > Denis Kudriashov wrote
> >> Good initiative.
> >
> > +1 :)
> >
> >
> > Denis Kudriashov wrote
> >> Here is my twitter questions:…
> >
> > Mine are:
> > 1. Is it possible/easy/smooth to zoom in/out?
> 
> We now have BlScalableElement which handles the zooming. The next thing is to 
> attach animations to it.
> 
> and...and...and...  can it zoom via the mouse-wheel? Or is support for this 
> planned / what are the issues?
> 
> cheers -ben

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

I think that testing more SDL and using it will help there.

On Fri, Oct 27, 2017 at 4:50 AM, Ben Coman  wrote:
>
>
> On Thu, Oct 26, 2017 at 4:00 AM, Tudor Girba  wrote:
>>
>> Hi,
>>
>> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris 
>> > wrote:
>> >
>> > Denis Kudriashov wrote
>> >> Good initiative.
>> >
>> > +1 :)
>> >
>> >
>> > Denis Kudriashov wrote
>> >> Here is my twitter questions:…
>> >
>> > Mine are:
>> > 1. Is it possible/easy/smooth to zoom in/out?
>>
>> We now have BlScalableElement which handles the zooming. The next thing is
>> to attach animations to it.
>
>
> and...and...and...  can it zoom via the mouse-wheel? Or is support for this
> planned / what are the issues?
>
> cheers -ben

Re: [Pharo-dev] feenk log

[Ben Coman]

On Thu, Oct 26, 2017 at 4:00 AM, Tudor Girba  wrote:

> Hi,
>
> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris 
> wrote:
> >
> > Denis Kudriashov wrote
> >> Good initiative.
> >
> > +1 :)
> >
> >
> > Denis Kudriashov wrote
> >> Here is my twitter questions:…
> >
> > Mine are:
> > 1. Is it possible/easy/smooth to zoom in/out?
>
> We now have BlScalableElement which handles the zooming. The next thing is
> to attach animations to it.
>

and...and...and...  can it zoom via the mouse-wheel? Or is support for this
planned / what are the issues?

cheers -ben

Re: [Pharo-dev] feenk log

[Ben Coman]

On Thu, Oct 26, 2017 at 2:15 PM, Clément Bera 
wrote:

> Hi,
>
> Good work,
>
> In PolyMaths/SciSmalltalk vectors and matrix are already implemented
> efficiently. I would recommend to share the same implementation.
>

By this, you mean move the "base" vector/matrix objects from there into
Pharo?  This makes a lot of sense.  These are applicable to a lot of
applications, and having them in-Image obviously helps focus efforts and
reuse.  These could just have the minimal methods required by Bloc, with
PolyMaths/SciSmalltalk extending them with more exotic operations.


> In the next few years, I think we will improve the performance of those
> vectors/matrix library using the processor vector instructions, and it
> would be nice if we have to improve one but not two libraries of vectors
> and matrix (This is the polite way of saying I am going to improve one
> library and the others will have to do it themselves).
>
> Regards,
>
> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>
>> Hi,
>>
>> Our team is working on a couple of projects that are relevant for the
>> core of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several
>> people, and Stef in particular, to make the progress on these projects more
>> transparent. To this end, we will start two streams of signals:
>> - fine grained info bits on out Twitter account (several times a week):
>> https://twitter.com/feenkcom
>> - a less often but regular (probably every 2 weeks) activity log message
>> sent to this mailing list
>>
>> Please let us know if you see an issue with this.
>>
>
Good initiative, and already getting to useful collaboration.

btw, I know sharing opens up to nit picking that can be discouraging, as
we've seen other tools you've introduced in the past get a bit of a beating
at the transition stage - but your vision and good work has borne through
and now these are tools we now can't live without!   So keep up the good
work.

cheers -ben


>
>> In the meantime, let’s start.
>>
>> Bloc:
>> - Over the past couple of weeks Alex worked on transformations and
>> measurements in the core system. It turns out that there was room for quite
>> a number of performance optimizations and for making the system more
>> debuggable.
>> - At the low level, this involved adding matrix and vector support.
>> https://twitter.com/feenkcom/status/923123870537863168
>> https://twitter.com/feenkcom/status/916300180848349185
>> - At a higher level, it implies keeping track of measurements
>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>> - And of transformations:
>> https://twitter.com/feenkcom/status/919603739656417281
>> https://twitter.com/feenkcom/status/917116164484096001
>> - The BlScalableElement is now working properly
>>
>> GT Examples:
>> - The current repository with unary-based examples is at:
>> https://github.com/feenkcom/gtoolkit-examples
>> - We now have a runner in the inspector that allows us to both see the
>> source code and run and play with the resulting object:
>> https://twitter.com/feenkcom/status/923210686204989442
>> - Andrei made the “after” behavior to work with unary examples.
>>
>> Cheers,
>> The feenk team
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Being happy is a matter of choice."
>>
> +1

Re: [Pharo-dev] feenk log

[werner kassens]

Hi Doru,
you say BLVector is implemented as having instance vars x,y instead of
using an Array (like polymath), i guess perhaps because of speed
considerations? but i wonder why you then dont use FloatArrays for
vectors, their precision, although generally bad, is sufficient for
graphics and they are faster for vector operations?
werner

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi Clément,

I did not know that you had an interest in optimizing vector and matrix 
operations. Awesome!

We definitely want to take a look at synergies. These low level things are 
needed for Bloc, but they definitely do not have to be in Bloc.

Doru


> On Oct 26, 2017, at 8:15 AM, Clément Bera  wrote:
> 
> Hi,
> 
> Good work,
> 
> In PolyMaths/SciSmalltalk vectors and matrix are already implemented 
> efficiently. I would recommend to share the same implementation. In the next 
> few years, I think we will improve the performance of those vectors/matrix 
> library using the processor vector instructions, and it would be nice if we 
> have to improve one but not two libraries of vectors and matrix (This is the 
> polie way of saying I am going to improve one library and the others will 
> have to do it themselves).
> 
> Regards,
> 
> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
> Hi,
> 
> Our team is working on a couple of projects that are relevant for the core of 
> Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, and 
> Stef in particular, to make the progress on these projects more transparent. 
> To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week): 
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message sent 
> to this mailing list
> 
> Please let us know if you see an issue with this.
> 
> In the meantime, let’s start.
> 
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and 
> measurements in the core system. It turns out that there was room for quite a 
> number of performance optimizations and for making the system more debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
> 
> GT Examples:
> - The current repository with unary-based examples is at: 
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the source 
> code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
> 
> Cheers,
> The feenk team
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Being happy is a matter of choice."
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

--
www.tudorgirba.com
www.feenk.com

"To lead is not to demand things, it is to make them happen."

Re: [Pharo-dev] feenk log

[Clément Bera]

Hi,

Good work,

In PolyMaths/SciSmalltalk vectors and matrix are already implemented
efficiently. I would recommend to share the same implementation. In the
next few years, I think we will improve the performance of those
vectors/matrix library using the processor vector instructions, and it
would be nice if we have to improve one but not two libraries of vectors
and matrix (This is the polie way of saying I am going to improve one
library and the others will have to do it themselves).

Regards,

On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:

> Hi,
>
> Our team is working on a couple of projects that are relevant for the core
> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several
> people, and Stef in particular, to make the progress on these projects more
> transparent. To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week):
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message
> sent to this mailing list
>
> Please let us know if you see an issue with this.
>
> In the meantime, let’s start.
>
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and
> measurements in the core system. It turns out that there was room for quite
> a number of performance optimizations and for making the system more
> debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
>
> GT Examples:
> - The current repository with unary-based examples is at:
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the
> source code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] feenk log

[Sean P. DeNigris]

Tudor Girba-2 wrote
> We now have BlScalableElement which handles the zooming

Gotcha. So an entire "World" (I'm assuming that's a Bloc Space?) can be
zoomed in and out?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

On Wed, Oct 25, 2017 at 7:04 PM, Aliaksei Syrel  wrote:
> Hi Stef,
>
> In this email I will enumerate what features are missing that we are aware
> of. The problem is that we discover what we need spontaneously during
> experiments and not beforehand :)

Yes for the extras problems but you always have an idea of the base.

>
> Missing / broken
>  - error handling library. If there is an exception during event handling or
> rendering, Bloc's UI thread stops and we have to reset the universe.

I was wondering if the use of on:fork: would not help there.

> Sometimes errors cause "infinite" spawn of debuggers.
>  - transformations (scale, translate, rotate) animations don't work now,
> because I still need to finish interpolation of matrix decomposition.
>  - there is a bug with drawing invalidation when element has rotation
> transformation.
>  - gradient backgrounds can only have fixed size (origin/corner) and can not
> scale according to element's size.
>  - event propagation mechanism should be implemented on top of Announcer and
> not using our custom one (there was a discussion about this on dev mailing
> list)
Ok you mean what glenn did. Ok sounds good. For me I would like to
have less concepts or similar libraries.

>  - Sparta/Cairo backend has not implemented fill path with image pattern API
> method
>  - FFI Callbacks crash VM on windows (I have my own FFI-only tests that
> fail)
>  - FFI external array can not handle booleans:
>
> array := FFIExternalArray externalNewType: 'bool' size: 1. array at: 1 put:
> true. array at: 1 "false"
>
> More minor issues can be found on Bloc's github page
> https://github.com/pharo-graphics/Bloc/issues
>
> That is all from my side :)

Ok so this is reasonable.
I would add for version 1.0
Nice class comments


> Cheers,
> Alex
>
> On 25 October 2017 at 18:48, Aliaksei Syrel  wrote:
>>
>> Hi Denis,
>>
>> The reason for BlVector2D is that we also have BlVector3D.
>> In case of translation a Point (x@y) should be converted to (x,y,0). For
>> scale it is converted as (x,y,1). You see, the same Point object has
>> different meanings when it comes to different transformations.
>>
>> Additionally, Point does not represent the intent correctly because all
>> affine transformations involve vectors. Of course, we made Vectors
>> polymorphic with points, so users can write:
>> element translateBy: (20@20) instead of element translateBy: (BlVector x:
>> 20 y: 20).
>>
>>> - How often this vector will be constructed by hands in user code? It is
>>> related to my question about comma message: is it really needed?
>>
>>
>> In lineare algebra vectors are represented as (x, y, z).  Beautiful!
>>
>> Cheers,
>> Alex
>
>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Ok :)

Stef

On Wed, Oct 25, 2017 at 7:58 PM, Tudor Girba  wrote:
> Hi Stef,
>
> The log is not a replacement of the roadmap. It is only to help people see 
> what we do live.
>
> The roadmap and documentation are coming as well, but these are separate.
>
> Cheers,
> Doru
>
>
>> On Oct 25, 2017, at 6:45 PM, Stephane Ducasse  
>> wrote:
>>
>> Doru having a few tweets is nice but I do not think that you
>> communicate well around bloc.
>>
>> What I would like to get is a roadmap for Bloc V1.0.
>> - Here are the missing features (documentation),
>> - Here are where we are.
>> Because else it feels like Bloc will never ends.
>> You will argue and tell me that you experiments. But without a feature
>> list then
>> people cannot join and do not know when you get a 1.0.
>>
>> Not measuring is the best way to arrive to a point where you did not wanted.
>>
>> You see for Brick we need
>>Button
>>CheckBox
>>DropList
>>List
>>Table
>>Pane
>>InputField
>>Text
>>Scrollbar
>>Menu
>> And with that we can get a first Widget set.
>> But again without a roadmap I have some doubts.
>>
>> Stef
>>
>>
>> Stef
>>
>>
>> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>>  wrote:
>>> Doru using comma for creating vectors is not really because it will
>>> just make the life of type inferencers more difficult.
>>>
>>>
>>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
 Hi,

 Our team is working on a couple of projects that are relevant for the core 
 of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
 people, and Stef in particular, to make the progress on these projects 
 more transparent. To this end, we will start two streams of signals:
 - fine grained info bits on out Twitter account (several times a week): 
 https://twitter.com/feenkcom
 - a less often but regular (probably every 2 weeks) activity log message 
 sent to this mailing list

 Please let us know if you see an issue with this.

 In the meantime, let’s start.

 Bloc:
 - Over the past couple of weeks Alex worked on transformations and 
 measurements in the core system. It turns out that there was room for 
 quite a number of performance optimizations and for making the system more 
 debuggable.
 - At the low level, this involved adding matrix and vector support.
 https://twitter.com/feenkcom/status/923123870537863168
 https://twitter.com/feenkcom/status/916300180848349185
 - At a higher level, it implies keeping track of measurements
 https://twitter.com/AliakseiSyrel/status/915203525931622400
 - And of transformations:
 https://twitter.com/feenkcom/status/919603739656417281
 https://twitter.com/feenkcom/status/917116164484096001
 - The BlScalableElement is now working properly

 GT Examples:
 - The current repository with unary-based examples is at: 
 https://github.com/feenkcom/gtoolkit-examples
 - We now have a runner in the inspector that allows us to both see the 
 source code and run and play with the resulting object:
 https://twitter.com/feenkcom/status/923210686204989442
 - Andrei made the “after” behavior to work with unary examples.

 Cheers,
 The feenk team

 --
 www.tudorgirba.com
 www.feenk.com

 "Being happy is a matter of choice."





>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What we can governs what we wish."
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

2017-10-25 22:00 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris 
> wrote:
> >
> > Denis Kudriashov wrote
> >> Good initiative.
> >
> > +1 :)
> >
> >
> > Denis Kudriashov wrote
> >> Here is my twitter questions:…
> >
> > Mine are:
> > 1. Is it possible/easy/smooth to zoom in/out?
>
> We now have BlScalableElement which handles the zooming. The next thing is
> to attach animations to it.
>

I expected that any element can be scalable because transformation is part
of it. Am I wrong?.
Then what the purpose of this subclass? Is it for convenience or there is
some important logic inside?


>
> > 2. Is there an equivalent to Morphic-stepping?
>
> Yes, but this is achieved by attaching an animation to the element.
>
> However, right now, due to changes in transformations, animations are not
> working. They should be back soon.
>
> Cheers,
> Doru
>
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Reasonable is what we are accustomed with."
>
>
>

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi,

> On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris  wrote:
> 
> Denis Kudriashov wrote
>> Good initiative.
> 
> +1 :)
> 
> 
> Denis Kudriashov wrote
>> Here is my twitter questions:…
> 
> Mine are:
> 1. Is it possible/easy/smooth to zoom in/out?

We now have BlScalableElement which handles the zooming. The next thing is to 
attach animations to it.

> 2. Is there an equivalent to Morphic-stepping?

Yes, but this is achieved by attaching an animation to the element.

However, right now, due to changes in transformations, animations are not 
working. They should be back soon.

Cheers,
Doru

> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."

Re: [Pharo-dev] feenk log

[Sean P. DeNigris]

Denis Kudriashov wrote
> Good initiative.

+1 :)


Denis Kudriashov wrote
> Here is my twitter questions:…

Mine are:
1. Is it possible/easy/smooth to zoom in/out?
2. Is there an equivalent to Morphic-stepping?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi,

That is the point of making fine grained things explicit: to have the chance to 
disagree and discuss :).

I will spawn a separate thread.

Doru


> On Oct 25, 2017, at 7:42 PM, Alexandre Bergel  wrote:
> 
>> Personally (10, 20) for a vector is not really nice and I would really
>> like to have a discussion before.
> 
> +1 
> 
> The Pharo syntax should remain an asset, not become a trap.
> 
> Alexandre
> 
>> 
>> 
>> On Wed, Oct 25, 2017 at 6:45 PM, Stephane Ducasse
>>  wrote:
>>> Doru having a few tweets is nice but I do not think that you
>>> communicate well around bloc.
>>> 
>>> What I would like to get is a roadmap for Bloc V1.0.
>>> - Here are the missing features (documentation),
>>> - Here are where we are.
>>> Because else it feels like Bloc will never ends.
>>> You will argue and tell me that you experiments. But without a feature
>>> list then
>>> people cannot join and do not know when you get a 1.0.
>>> 
>>> Not measuring is the best way to arrive to a point where you did not wanted.
>>> 
>>> You see for Brick we need
>>>   Button
>>>   CheckBox
>>>   DropList
>>>   List
>>>   Table
>>>   Pane
>>>   InputField
>>>   Text
>>>   Scrollbar
>>>   Menu
>>> And with that we can get a first Widget set.
>>> But again without a roadmap I have some doubts.
>>> 
>>> Stef
>>> 
>>> 
>>> Stef
>>> 
>>> 
>>> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>>>  wrote:
 Doru using comma for creating vectors is not really because it will
 just make the life of type inferencers more difficult.
 
 
 On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
> Hi,
> 
> Our team is working on a couple of projects that are relevant for the 
> core of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
> people, and Stef in particular, to make the progress on these projects 
> more transparent. To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week): 
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message 
> sent to this mailing list
> 
> Please let us know if you see an issue with this.
> 
> In the meantime, let’s start.
> 
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and 
> measurements in the core system. It turns out that there was room for 
> quite a number of performance optimizations and for making the system 
> more debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
> 
> GT Examples:
> - The current repository with unary-based examples is at: 
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the 
> source code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
> 
> Cheers,
> The feenk team
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Being happy is a matter of choice."
> 
> 
> 
> 
> 
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Don't give to get. Just give."

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi Stef,

The log is not a replacement of the roadmap. It is only to help people see what 
we do live.

The roadmap and documentation are coming as well, but these are separate.

Cheers,
Doru


> On Oct 25, 2017, at 6:45 PM, Stephane Ducasse  wrote:
> 
> Doru having a few tweets is nice but I do not think that you
> communicate well around bloc.
> 
> What I would like to get is a roadmap for Bloc V1.0.
> - Here are the missing features (documentation),
> - Here are where we are.
> Because else it feels like Bloc will never ends.
> You will argue and tell me that you experiments. But without a feature
> list then
> people cannot join and do not know when you get a 1.0.
> 
> Not measuring is the best way to arrive to a point where you did not wanted.
> 
> You see for Brick we need
>Button
>CheckBox
>DropList
>List
>Table
>Pane
>InputField
>Text
>Scrollbar
>Menu
> And with that we can get a first Widget set.
> But again without a roadmap I have some doubts.
> 
> Stef
> 
> 
> Stef
> 
> 
> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>  wrote:
>> Doru using comma for creating vectors is not really because it will
>> just make the life of type inferencers more difficult.
>> 
>> 
>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>>> Hi,
>>> 
>>> Our team is working on a couple of projects that are relevant for the core 
>>> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
>>> people, and Stef in particular, to make the progress on these projects more 
>>> transparent. To this end, we will start two streams of signals:
>>> - fine grained info bits on out Twitter account (several times a week): 
>>> https://twitter.com/feenkcom
>>> - a less often but regular (probably every 2 weeks) activity log message 
>>> sent to this mailing list
>>> 
>>> Please let us know if you see an issue with this.
>>> 
>>> In the meantime, let’s start.
>>> 
>>> Bloc:
>>> - Over the past couple of weeks Alex worked on transformations and 
>>> measurements in the core system. It turns out that there was room for quite 
>>> a number of performance optimizations and for making the system more 
>>> debuggable.
>>> - At the low level, this involved adding matrix and vector support.
>>> https://twitter.com/feenkcom/status/923123870537863168
>>> https://twitter.com/feenkcom/status/916300180848349185
>>> - At a higher level, it implies keeping track of measurements
>>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>>> - And of transformations:
>>> https://twitter.com/feenkcom/status/919603739656417281
>>> https://twitter.com/feenkcom/status/917116164484096001
>>> - The BlScalableElement is now working properly
>>> 
>>> GT Examples:
>>> - The current repository with unary-based examples is at: 
>>> https://github.com/feenkcom/gtoolkit-examples
>>> - We now have a runner in the inspector that allows us to both see the 
>>> source code and run and play with the resulting object:
>>> https://twitter.com/feenkcom/status/923210686204989442
>>> - Andrei made the “after” behavior to work with unary examples.
>>> 
>>> Cheers,
>>> The feenk team
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "Being happy is a matter of choice."
>>> 
>>> 
>>> 
>>> 
>>> 
> 

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-dev] feenk log

[Alexandre Bergel]

> Personally (10, 20) for a vector is not really nice and I would really
> like to have a discussion before.

+1 

The Pharo syntax should remain an asset, not become a trap.

Alexandre

> 
> 
> On Wed, Oct 25, 2017 at 6:45 PM, Stephane Ducasse
>  wrote:
>> Doru having a few tweets is nice but I do not think that you
>> communicate well around bloc.
>> 
>> What I would like to get is a roadmap for Bloc V1.0.
>> - Here are the missing features (documentation),
>> - Here are where we are.
>> Because else it feels like Bloc will never ends.
>> You will argue and tell me that you experiments. But without a feature
>> list then
>> people cannot join and do not know when you get a 1.0.
>> 
>> Not measuring is the best way to arrive to a point where you did not wanted.
>> 
>> You see for Brick we need
>>Button
>>CheckBox
>>DropList
>>List
>>Table
>>Pane
>>InputField
>>Text
>>Scrollbar
>>Menu
>> And with that we can get a first Widget set.
>> But again without a roadmap I have some doubts.
>> 
>> Stef
>> 
>> 
>> Stef
>> 
>> 
>> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>>  wrote:
>>> Doru using comma for creating vectors is not really because it will
>>> just make the life of type inferencers more difficult.
>>> 
>>> 
>>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
 Hi,
 
 Our team is working on a couple of projects that are relevant for the core 
 of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
 people, and Stef in particular, to make the progress on these projects 
 more transparent. To this end, we will start two streams of signals:
 - fine grained info bits on out Twitter account (several times a week): 
 https://twitter.com/feenkcom
 - a less often but regular (probably every 2 weeks) activity log message 
 sent to this mailing list
 
 Please let us know if you see an issue with this.
 
 In the meantime, let’s start.
 
 Bloc:
 - Over the past couple of weeks Alex worked on transformations and 
 measurements in the core system. It turns out that there was room for 
 quite a number of performance optimizations and for making the system more 
 debuggable.
 - At the low level, this involved adding matrix and vector support.
 https://twitter.com/feenkcom/status/923123870537863168
 https://twitter.com/feenkcom/status/916300180848349185
 - At a higher level, it implies keeping track of measurements
 https://twitter.com/AliakseiSyrel/status/915203525931622400
 - And of transformations:
 https://twitter.com/feenkcom/status/919603739656417281
 https://twitter.com/feenkcom/status/917116164484096001
 - The BlScalableElement is now working properly
 
 GT Examples:
 - The current repository with unary-based examples is at: 
 https://github.com/feenkcom/gtoolkit-examples
 - We now have a runner in the inspector that allows us to both see the 
 source code and run and play with the resulting object:
 https://twitter.com/feenkcom/status/923210686204989442
 - Andrei made the “after” behavior to work with unary examples.
 
 Cheers,
 The feenk team
 
 --
 www.tudorgirba.com
 www.feenk.com
 
 "Being happy is a matter of choice."
 
 
 
 
 
> 

Re: [Pharo-dev] feenk log

[Aliaksei Syrel]

Hi Stef,

In this email I will enumerate what features are missing that we are aware
of. The problem is that we discover what we need spontaneously during
experiments and not beforehand :)

Missing / broken
 - error handling library. If there is an exception during event handling
or rendering, Bloc's UI thread stops and we have to reset the universe.
Sometimes errors cause "infinite" spawn of debuggers.
 - transformations (scale, translate, rotate) animations don't work now,
because I still need to finish interpolation of matrix decomposition.
 - there is a bug with drawing invalidation when element has rotation
transformation.
 - gradient backgrounds can only have fixed size (origin/corner) and can
not scale according to element's size.
 - event propagation mechanism should be implemented on top of Announcer
and not using our custom one (there was a discussion about this on dev
mailing list)
 - Sparta/Cairo backend has not implemented fill path with image pattern
API method
 - FFI Callbacks crash VM on windows (I have my own FFI-only tests that
fail)
 - FFI external array can not handle booleans:

array := FFIExternalArray externalNewType: 'bool' size: 1. array at: 1 put:
true. array at: 1 "false"

More minor issues can be found on Bloc's github page
https://github.com/pharo-graphics/Bloc/issues

That is all from my side :)

Cheers,
Alex

On 25 October 2017 at 18:48, Aliaksei Syrel  wrote:

> Hi Denis,
>
> The reason for BlVector2D is that we also have BlVector*3*D.
> In case of translation a Point (x@y) should be converted to (x,y,0). For
> scale it is converted as (x,y,1). You see, the same Point object has
> different meanings when it comes to different transformations.
>
> Additionally, Point does not represent the intent correctly because all
> affine transformations involve vectors. Of course, we made Vectors
> polymorphic with points, so users can write:
> element translateBy: (20@20) instead of element translateBy: (BlVector x:
> 20 y: 20).
>
> - How often this vector will be constructed by hands in user code? It is
>> related to my question about comma message: is it really needed?
>
>
> In lineare algebra vectors are represented as (x, y, z).  Beautiful!
>
> Cheers,
> Alex
>

Re: [Pharo-dev] feenk log

[Aliaksei Syrel]

Hi Denis,

The reason for BlVector2D is that we also have BlVector*3*D.
In case of translation a Point (x@y) should be converted to (x,y,0). For
scale it is converted as (x,y,1). You see, the same Point object has
different meanings when it comes to different transformations.

Additionally, Point does not represent the intent correctly because all
affine transformations involve vectors. Of course, we made Vectors
polymorphic with points, so users can write:
element translateBy: (20@20) instead of element translateBy: (BlVector x:
20 y: 20).

- How often this vector will be constructed by hands in user code? It is
> related to my question about comma message: is it really needed?


In lineare algebra vectors are represented as (x, y, z).  Beautiful!

Cheers,
Alex

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Personally (10, 20) for a vector is not really nice and I would really
like to have a discussion before.


On Wed, Oct 25, 2017 at 6:45 PM, Stephane Ducasse
 wrote:
> Doru having a few tweets is nice but I do not think that you
> communicate well around bloc.
>
> What I would like to get is a roadmap for Bloc V1.0.
> - Here are the missing features (documentation),
> - Here are where we are.
> Because else it feels like Bloc will never ends.
> You will argue and tell me that you experiments. But without a feature
> list then
> people cannot join and do not know when you get a 1.0.
>
> Not measuring is the best way to arrive to a point where you did not wanted.
>
> You see for Brick we need
> Button
> CheckBox
> DropList
> List
> Table
> Pane
> InputField
> Text
> Scrollbar
> Menu
> And with that we can get a first Widget set.
> But again without a roadmap I have some doubts.
>
> Stef
>
>
> Stef
>
>
> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>  wrote:
>> Doru using comma for creating vectors is not really because it will
>> just make the life of type inferencers more difficult.
>>
>>
>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>>> Hi,
>>>
>>> Our team is working on a couple of projects that are relevant for the core 
>>> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
>>> people, and Stef in particular, to make the progress on these projects more 
>>> transparent. To this end, we will start two streams of signals:
>>> - fine grained info bits on out Twitter account (several times a week): 
>>> https://twitter.com/feenkcom
>>> - a less often but regular (probably every 2 weeks) activity log message 
>>> sent to this mailing list
>>>
>>> Please let us know if you see an issue with this.
>>>
>>> In the meantime, let’s start.
>>>
>>> Bloc:
>>> - Over the past couple of weeks Alex worked on transformations and 
>>> measurements in the core system. It turns out that there was room for quite 
>>> a number of performance optimizations and for making the system more 
>>> debuggable.
>>> - At the low level, this involved adding matrix and vector support.
>>> https://twitter.com/feenkcom/status/923123870537863168
>>> https://twitter.com/feenkcom/status/916300180848349185
>>> - At a higher level, it implies keeping track of measurements
>>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>>> - And of transformations:
>>> https://twitter.com/feenkcom/status/919603739656417281
>>> https://twitter.com/feenkcom/status/917116164484096001
>>> - The BlScalableElement is now working properly
>>>
>>> GT Examples:
>>> - The current repository with unary-based examples is at: 
>>> https://github.com/feenkcom/gtoolkit-examples
>>> - We now have a runner in the inspector that allows us to both see the 
>>> source code and run and play with the resulting object:
>>> https://twitter.com/feenkcom/status/923210686204989442
>>> - Andrei made the “after” behavior to work with unary examples.
>>>
>>> Cheers,
>>> The feenk team
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Being happy is a matter of choice."
>>>
>>>
>>>
>>>
>>>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Doru having a few tweets is nice but I do not think that you
communicate well around bloc.

What I would like to get is a roadmap for Bloc V1.0.
- Here are the missing features (documentation),
- Here are where we are.
Because else it feels like Bloc will never ends.
You will argue and tell me that you experiments. But without a feature
list then
people cannot join and do not know when you get a 1.0.

Not measuring is the best way to arrive to a point where you did not wanted.

You see for Brick we need
Button
CheckBox
DropList
List
Table
Pane
InputField
Text
Scrollbar
Menu
And with that we can get a first Widget set.
But again without a roadmap I have some doubts.

Stef


Stef


On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
 wrote:
> Doru using comma for creating vectors is not really because it will
> just make the life of type inferencers more difficult.
>
>
> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>> Hi,
>>
>> Our team is working on a couple of projects that are relevant for the core 
>> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, 
>> and Stef in particular, to make the progress on these projects more 
>> transparent. To this end, we will start two streams of signals:
>> - fine grained info bits on out Twitter account (several times a week): 
>> https://twitter.com/feenkcom
>> - a less often but regular (probably every 2 weeks) activity log message 
>> sent to this mailing list
>>
>> Please let us know if you see an issue with this.
>>
>> In the meantime, let’s start.
>>
>> Bloc:
>> - Over the past couple of weeks Alex worked on transformations and 
>> measurements in the core system. It turns out that there was room for quite 
>> a number of performance optimizations and for making the system more 
>> debuggable.
>> - At the low level, this involved adding matrix and vector support.
>> https://twitter.com/feenkcom/status/923123870537863168
>> https://twitter.com/feenkcom/status/916300180848349185
>> - At a higher level, it implies keeping track of measurements
>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>> - And of transformations:
>> https://twitter.com/feenkcom/status/919603739656417281
>> https://twitter.com/feenkcom/status/917116164484096001
>> - The BlScalableElement is now working properly
>>
>> GT Examples:
>> - The current repository with unary-based examples is at: 
>> https://github.com/feenkcom/gtoolkit-examples
>> - We now have a runner in the inspector that allows us to both see the 
>> source code and run and play with the resulting object:
>> https://twitter.com/feenkcom/status/923210686204989442
>> - Andrei made the “after” behavior to work with unary examples.
>>
>> Cheers,
>> The feenk team
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>>
>>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Doru using comma for creating vectors is not really because it will
just make the life of type inferencers more difficult.


On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
> Hi,
>
> Our team is working on a couple of projects that are relevant for the core of 
> Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, and 
> Stef in particular, to make the progress on these projects more transparent. 
> To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week): 
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message sent 
> to this mailing list
>
> Please let us know if you see an issue with this.
>
> In the meantime, let’s start.
>
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and 
> measurements in the core system. It turns out that there was room for quite a 
> number of performance optimizations and for making the system more debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
>
> GT Examples:
> - The current repository with unary-based examples is at: 
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the source 
> code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

Hi.
Good initiative.

Here is my twitter questions:
- What the reason to introduce BlVector2D instead of using existing Point?
- How often this vector will be constructed by hands in user code? It is
related to my question about comma message: is it really needed?
Now you can evaluate (10*,* 20)  to get vector instance. And if it is only
to simplify scripting and examples then why not use Point for this? As you
said point can be converted to vector.

Best regards,
Denis


2017-10-25 17:53 GMT+02:00 Tudor Girba :

> Hi,
>
> Our team is working on a couple of projects that are relevant for the core
> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several
> people, and Stef in particular, to make the progress on these projects more
> transparent. To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week):
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message
> sent to this mailing list
>
> Please let us know if you see an issue with this.
>
> In the meantime, let’s start.
>
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and
> measurements in the core system. It turns out that there was room for quite
> a number of performance optimizations and for making the system more
> debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
>
> GT Examples:
> - The current repository with unary-based examples is at:
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the
> source code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

Our team is working on a couple of projects that are relevant for the core of 
Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, and 
Stef in particular, to make the progress on these projects more transparent. To 
this end, we will start two streams of signals:
- fine grained info bits on out Twitter account (several times a week): 
https://twitter.com/feenkcom
- a less often but regular (probably every 2 weeks) activity log message sent 
to this mailing list

Please let us know if you see an issue with this.

In the meantime, let’s start.

Bloc:
- Over the past couple of weeks Alex worked on transformations and measurements 
in the core system. It turns out that there was room for quite a number of 
performance optimizations and for making the system more debuggable.
- At the low level, this involved adding matrix and vector support.
https://twitter.com/feenkcom/status/923123870537863168
https://twitter.com/feenkcom/status/916300180848349185
- At a higher level, it implies keeping track of measurements 
https://twitter.com/AliakseiSyrel/status/915203525931622400
- And of transformations:
https://twitter.com/feenkcom/status/919603739656417281
https://twitter.com/feenkcom/status/917116164484096001
- The BlScalableElement is now working properly

GT Examples:
- The current repository with unary-based examples is at: 
https://github.com/feenkcom/gtoolkit-examples
- We now have a runner in the inspector that allows us to both see the source 
code and run and play with the resulting object:
https://twitter.com/feenkcom/status/923210686204989442
- Andrei made the “after” behavior to work with unary examples.

Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."