[Pharo-dev] TxText model

Thierry Goubier thierry.goubier at gmail.com
Mon Apr 4 10:47:03 EDT 2016


2016-04-04 16:14 GMT+02:00 Igor Stasenko <siguctua at gmail.com>:

>
>
> On 4 April 2016 at 17:03, Thierry Goubier <thierry.goubier at gmail.com>
> wrote:
>
>>
>>
>> 2016-04-04 15:49 GMT+02:00 Igor Stasenko <siguctua at gmail.com>:
>>
>>>
>>>
>>> On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> 2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua at gmail.com>:
>>>>
>>>>>
>>>>>
>>>>>> Analogies don't work. Right :) I never used Pillar and have remote
>>>>> ideas about what it does or requires. From that perspective you appeal to
>>>>> wrong person. On your place i would be asking a guy who knows Pillar
>>>>> innards about it.
>>>>> Forgive my ignorance.. but i am not omniscient.
>>>>>
>>>>
>>>> False humility doesn't work there, Igor :)
>>>>
>>>
>>> But i don't know what Pillar is. Never used it. I'm not lying here. I
>>> seen people doing something with it time to time.. but never got my eyes on
>>> it.
>>> Or would you prefer that i would pretend that i know something and can
>>> continue discussion about things related to it? Waving hands, pointing to
>>> milestones, drawing diagrams? :)
>>>
>>
>> Yes, diagrams :) Ok, I don't know that much Pillar in details myself;
>> except as one of those things where some of your characters in the text are
>> used to build a layout on a target.
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> Second is: Pharo (and all smalltalks) is the place where supposedly
>>>>>> impossible stuff can be developed, simply because it takes far less lines
>>>>>> than anywhere else. No guarantees, but, at the rate we're dropping projects
>>>>>> by the side of the road (and reinventing stuff multiple times over), we
>>>>>> have manpower to spare :)
>>>>>>
>>>>>> But that is orthogonal. It is possible to do anything on
>>>>> turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do
>>>>> such statements alone can bring us anywhere closer to grand goals and grand
>>>>> projects?
>>>>> Nope. Only hard day to day work could bring us there.. Not talks about
>>>>> how cool we are.
>>>>>
>>>>
>>>> Hard day to day work, yes. But if you make it that uninteresting, yes,
>>>> I'm sure we will never get there :)
>>>>
>>>> Okay, let me elaborate what was the whole point behind TxText project.
>>> It was part of work we were doing to migrate from old Canvas & BitBlt
>>> Morphic rendering towards vector-based rendering using Athens. Basically in
>>> a nutshell TxText is a model and rendering engine for text rendering.
>>>
>>
>> I'd say it is more: it is an interactive model for text editing and
>> rendering. How much of it is "interactive" by opposition to pure rendering?
>> Can they be easily separated?
>>
>
> Well, there is a model, TxModel, which is domain-based. Means it is
> abstract and agnostic from any kind of rendering engine or UI.
> It represents an object that contains text and allows certain operation on
> it, like selection, deletion, insertion etc.
> And rendering engine bridges that model with morphic and athens.
> It cannot be separated, since it implies using such model for computing
> layout, and implies to use Athens for rendering.. And implies to exist in
> Morphic (or some other kind of UI environment) for UI interaction, to be
> represented as a widget on screen and receive events and mouse/keyboard
> input etc.
> So, what kind of separation you trying to see there?
>

I was trying to evaluate how much of it was tied to an underlying text
model, and a specific interaction approach / global high level view of the
UI.

A short look through the layout part of it and I saw it has support for
arbitrary object spans. It also supposes a certain API from it's model
(interacting back to indicate where lines should be ended). A text is a
list of spans, isn't it? And spans are flat (no span inside span). One
could imagine extending attributes for spans / type of spans and get
customized rendering / handling for those.

For now, external objects can't extend below the baseline.

Position inside spans can be ambiguous: last position of a span and first
position of the next span are the same position.

Thierry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160404/773c959c/attachment.html>


More information about the Pharo-dev mailing list