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 <tu...@tudorgirba.com> 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 > <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 > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev
