Smalltalk › Frameworks & Tools › Moose

[ann] gt connector

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Tudor Girba-2

[ann] gt connector

Hi,

Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.

It looks like this:

You can see it in action here:
https://twitter.com/feenkcom/status/936109463462965248

In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.

There are a couple of things that are worth noting:

• The editor works live, and the connection points appear and disappear as you type.

• The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).

• The editor works live, so adding new elements to the scene properly rearranges the scene.

• But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.

All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.

To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.

Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.

The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.

Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.

Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:

Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.

We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf

Please let us know what you think.

Cheers,
The feenk team

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

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Nicolas Cellier

Re: [Pharo-dev] [ann] gt connector

It sounds great!

Le 14 janv. 2018 10:55 PM, "Tudor Girba" <[hidden email]> a écrit :

Hi,

Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.

It looks like this:

You can see it in action here:
https://twitter.com/feenkcom/status/936109463462965248

In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.

There are a couple of things that are worth noting:
• The editor works live, and the connection points appear and disappear as you type.
• The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).
• The editor works live, so adding new elements to the scene properly rearranges the scene.
• But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.

All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.

To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.

Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.

The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.

Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.

Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:

Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.

We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf

Please let us know what you think.

Cheers,
The feenk team

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

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Sven Van Caekenberghe-2

Re: [ann] gt connector

In reply to this post by Tudor Girba-2

> On 14 Jan 2018, at 22:54, Tudor Girba <[hidden email]> wrote:
>
> Hi,
>
> Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.
>
> It looks like this:
> <connector2.jpeg>
>
> You can see it in action here:
> https://twitter.com/feenkcom/status/936109463462965248

Incredible stuff !

Keep on pushing the boundaries.

> In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.
>
> There are a couple of things that are worth noting:
> • The editor works live, and the connection points appear and disappear as you type.
> • The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).
> • The editor works live, so adding new elements to the scene properly rearranges the scene.
> • But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.
>
> All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.
>
> To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.
>
> Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.
>
> The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.
>
> Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.
>
> Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:
>
> <editor.jpg>
>
>
> Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.
>
> We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
> http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf
>
> Please let us know what you think.
>
> Cheers,
> The feenk team
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What is more important: To be happy, or to make happy?"
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Kjell Godo

Re: [ann] gt connector

very nice

On Mon, Jan 15, 2018 at 02:20 Sven Van Caekenberghe <[hidden email]> wrote:

> On 14 Jan 2018, at 22:54, Tudor Girba <[hidden email]> wrote:
>
> Hi,
>
> Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.
>
> It looks like this:
> <connector2.jpeg>
>
> You can see it in action here:
> https://twitter.com/feenkcom/status/936109463462965248

Incredible stuff !

Keep on pushing the boundaries.

> In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.
>
> There are a couple of things that are worth noting:
> • The editor works live, and the connection points appear and disappear as you type.
> • The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).
> • The editor works live, so adding new elements to the scene properly rearranges the scene.
> • But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.
>
> All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.
>
> To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.
>
> Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.
>
> The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.
>
> Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.
>
> Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:
>
> <editor.jpg>
>
>
> Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.
>
> We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
> http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf
>
> Please let us know what you think.
>
> Cheers,
> The feenk team
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What is more important: To be happy, or to make happy?"
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Kjell Godo

Re: [ann] gt connector

In reply to this post by Tudor Girba-2

i want to use it

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

abergel

Re: [ann] gt connector

In reply to this post by Tudor Girba-2

Impressive!!

Would be used for a visual implementer/sender browser

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Jan 14, 2018, at 6:54 PM, Tudor Girba <[hidden email]> wrote:

Hi,

Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.

It looks like this:
<connector2.jpeg>

You can see it in action here:
https://twitter.com/feenkcom/status/936109463462965248

In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.

There are a couple of things that are worth noting:
• The editor works live, and the connection points appear and disappear as you type.
• The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).
• The editor works live, so adding new elements to the scene properly rearranges the scene.
• But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.

All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.

To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.

Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.

The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.

Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.

Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:

<editor.jpg>

Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.

We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf

Please let us know what you think.

Cheers,
The feenk team

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

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Ben Coman

Re: [ann] gt connector

In reply to this post by Tudor Girba-2

On 15 January 2018 at 05:54, Tudor Girba <[hidden email]> wrote:

Hi,

Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc.

It looks like this:

You can see it in action here:
https://twitter.com/feenkcom/status/936109463462965248

In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects.

There are a couple of things that are worth noting:
• The editor works live, and the connection points appear and disappear as you type.
• The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements).
• The editor works live, so adding new elements to the scene properly rearranges the scene.
• But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element.

All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works.

To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at.

Thanks for this review. Its good to get a peek behind the curtain to understand what has been learnt (wrong and right) that feeds into the design.

Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it.

The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model.

Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow.

Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor:

Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc.

This is fantastic. I dreamed a little of such an interface. Another good example would be a deep expansion of "super initialize".

I guess this works easiest with "self" and "super" since there is only one method to expand.

For message chains or where messages are sent to variables and multiple implementors need to be considered,

it might not be completely practical but still a cool demonstration to have horizontally scrolling of multiple methods - similar to GTInspector panes scroll horizontally.

cheers -ben

We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015:
http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.pdf

Please let us know what you think.

Cheers,
The feenk team

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Sean P. DeNigris

Re: [ann] gt connector

Administrator

In reply to this post by Tudor Girba-2

Tudor Girba-2 wrote
> It looks like this:

Cool!

Is the "world" in which the example elements live (ideally infinitely)
scrollable and zoomable? Otherwise, the visualization might quickly become
unmanageable as the traced path becomes longer…

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Moose-f1310756.html
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Cheers,
Sean