Seems really interesting.
I think there is a lot of possibility in such new interfaces
powered by GT Tools, but exploring them is a lonely path. mostly
if you want to create end user tools.
Cheers,
Offray
On 14/01/18 16:54, Tudor Girba 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.
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
Locked
