glamorous toolkit: v0.4.0

>> These days are particularly slow in Colombia, but I will post advances
>> as soon as I have something.
> Thank you.
>
> Btw, I looked at Grafoscopio and it is interesting you had been looking
> or using tools like Leo editor, Pollen - I also considered Skribilo
> (Guile) - since I am also searching some toolchain to improve web
> publishing (paper output is not problem with LateX or ConTeXt) , but
> still haven't decided what to use/learn since learning Racket/Pharo
> requires some extra time until it can pay off (I want to stay focused
> on my writing and studying and not turn myself into programmer)...for
> now I'm still using Emacs/markdown-mode although in the past I spent
> time with both Aѕciidoc(tor) and rst markups.

> On Jan 1, 2019, at 8:01 PM, Konrad Hinsen <[hidden email]> wrote:
>
> Hi Offray and Doru,
>
> allow me to chirp in on a topic that I have been thinking about for a
> while:
>
>>> Interesting observation. The linked tools as all other notebook
>>> technologies I saw rely on two distinct modes for edit and view that
>>> reside in two distinct widgets (editor and viewer). They do that
>>> because they simply cannot have it in one. Because of the design of
>>> Bloc we are not constrained to that. Instead, we build a seamless
>>> interface that is both optimized for viewing, and for editing with
>>> live preview that does not rely on an explicit render button. This
>>> approach enables direct manipulation without friction, and we think
>>> this is a significant advancement in this space.
>
>> I don't think is only because other editors can't do it, but because
>> some (most) times you don't want "to conflate two tasks that are
>> /conceptually/ distinct and that, to ensure that people's time is used
>> most effectively and that the final communication is most effective,
>> ought also to be kept /practically/ distinct"[1] which are Composition
>> and typesetting.
>
> Two remarks.
>
> First, this is a special case of the more general issue of having
> multiple views and even multiple editors for a single object. No matter
> what you believe to be the best approach to editing text with markup, in
> many other situations it is clearly desirable to have multiple
> views/editors side by side, and I have regretted more than once that
> this doesn't seem to be possible in Pharo's inspector.
>
> For multiple editors the need to have them side by side is probably more
> obvious than for mere views, so it may be useful to look at practical
> examples and see how one would realize them in Pharo and/or in GT. One
> of my favorite applications is graphics that are generated by program
> code but can also be edited graphically, as implemented in
> Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/).
> You definitely want the two panes, code and graphics, side by side.
>
> Second, the example of editing text with markup also illustrates that it
> matters if views are complete (i.e. show all the available data) or
> partial, and if they are invertible, i.e. if a change in an editable
> view can be translated unambiguously into a change in the underlying
> data. Markup with comments, as mentioned by Offray, is a case in which
> the rendered view is partial but nevertheless invertible, so it makes
> sense to have two types of editors, one for the raw markup text and one
> for the rendered version. Some people may want both side by side,
> whereas others may prefer a single one with the possibility to switch,
> depending on how important the non-rendered information is.
>
> Scientific data visualization provides plenty of interesting examples by
> the way, often with the additional challenge of significant
> computational cost in rendering.
>
> Konrad.
>