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.
