Smalltalk › Pharo › Pharo Smalltalk Developers

TxText model

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

78 messages Options

1234

Thierry Goubier

Re: TxText model

2016-04-04 17:10 GMT+02:00 Stephan Eggermont <[hidden email]>:

On 04-04-16 16:49, Thierry Goubier wrote:

Framemaker-like or web-page like? Thierry

Framemaker.

Really challenging. Did you had a look at the Doc code (of Design Pattern fame)? It has allways been freely available.

Thierry

Denis Kudriashov

Re: TxText model

In reply to this post by Igor Stasenko

2016-04-04 17:16 GMT+02:00 Igor Stasenko <[hidden email]>:

Glad to hear that you did not thrown away your project.

If you skip my announcement it here http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-November/116027.html. And look at videos.

Stephan Eggermont-3

Re: TxText model

In reply to this post by Thierry Goubier

On 04-04-16 16:47, Thierry Goubier wrote:
> 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.
Yes, a flat list of spans vs a composite structure might cause
performance problems.

Stephan

Damien Pollet

Re: TxText model

In reply to this post by Thierry Goubier

On 4 April 2016 at 17:21, Thierry Goubier <[hidden email]> wrote:

Did you had a look at the Doc code (of Design Pattern fame)? It has allways been freely available.

no, what is it? do you have a link?

Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Thierry Goubier

Re: TxText model

Le 04/04/2016 22:02, Damien Pollet a écrit :
>
> On 4 April 2016 at 17:21, Thierry Goubier <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Did you had a look at the Doc code (of Design Pattern fame)? It has
> allways been freely available.
>
>
> no, what is it? do you have a link?

It's an old WYSIWIG text editor written in C++, implementing the TeX
typesetting, and source of a bunch of patterns of the Design Patterns
book (flyweight for character glyphs).

It was a part of the InterViews toolkit (J. Vlissides et al), and was
maintained (and is still maintained) as ivtools
(http://www.ivtools.org). Somewhere in there one could find a way to
build Doc, but I can't find it anymore. Haven't built it in more than
ten years...

Thierry

Thierry Goubier

Re: TxText model

In reply to this post by Damien Pollet

Le 04/04/2016 22:02, Damien Pollet a écrit :
>
> On 4 April 2016 at 17:21, Thierry Goubier <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Did you had a look at the Doc code (of Design Pattern fame)? It has
> allways been freely available.
>
>
> no, what is it? do you have a link?

Found it: it's in the original InterViews tar file:

http://www.ivtools.org/ivtools/faq.html#whataboutdoc

And, as they say: it should built against the interviews library in ivtools.

Someone with a stackoverflow account could complement the answers :)

http://stackoverflow.com/questions/4829227/gang-of-four-lexi-editor-c-source

Regards,

Thierry

Ben Coman

Re: TxText model

In reply to this post by Igor Stasenko

On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <[hidden email]> wrote:

>
>
> On 4 April 2016 at 16:32, Thierry Goubier <[hidden email]> wrote:
>>
>>
>>
>> 2016-04-04 15:23 GMT+02:00 Igor Stasenko <[hidden email]>:
>>>
>>>
>>>>
>>> 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.

Please see...

[1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf

[2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html

Most (all?) of docs at [3] are done using Pillar...
[3] https://github.com/SquareBracketAssociates

cheers -ben

Igor Stasenko

Re: TxText model

On 5 April 2016 at 04:16, Ben Coman <[hidden email]> wrote:

On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <[hidden email]> wrote:
>
>
> On 4 April 2016 at 16:32, Thierry Goubier <[hidden email]> wrote:
>>
>>
>>
>> 2016-04-04 15:23 GMT+02:00 Igor Stasenko <[hidden email]>:
>>>
>>>
>>>>
>>> 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.

Please see...

[1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf

Okay. Now i remember.

Yeah, i can easily imagine making a transformer that renders a pillar markup text into TxText instance, by implementing an yet another exporter, like PRTxTextWriter.

Certain features would be impossible right now, but for simple docs i guess it may work just fine.

[2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html

Most (all?) of docs at [3] are done using Pillar...
[3] https://github.com/SquareBracketAssociates

cheers -ben

Best regards,
Igor Stasenko.

Sean P. DeNigris

Re: TxText model

Administrator

In reply to this post by philippe.back@highoctane.be

philippe.back@highoctane.be wrote

So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and associated editors?! This is where my vim keybindings experiment came screeching to a halt.

Cheers,
Sean

philippeback

Re: TxText model

On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <[hidden email]> wrote:

[hidden email] wrote
> So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and
associated editors?!

A damn lot, I can tell you.

This is where my vim keybindings experiment came
screeching to a halt.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nicolai Hess-3-2

Re: TxText model

2016-04-06 7:57 GMT+02:00 [hidden email] <[hidden email]>:

On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <[hidden email]> wrote:
[hidden email] wrote
> So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and
associated editors?!

A damn lot, I can tell you.

This is where my vim keybindings experiment came
screeching to a halt.

What are the main problems with Text, Paragraph, ... and other old TextComponents?

And how are these solved with TxText?

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Igor Stasenko

Re: TxText model

On 6 April 2016 at 10:07, Nicolai Hess <[hidden email]> wrote:

2016-04-06 7:57 GMT+02:00 [hidden email] <[hidden email]>:

On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <[hidden email]> wrote:
[hidden email] wrote
> So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and
associated editors?!

A damn lot, I can tell you.

This is where my vim keybindings experiment came
screeching to a halt.

What are the main problems with Text, Paragraph, ... and other old TextComponents?

1. No support for vector graphics

2. Most operations are bound to text size.

And how are these solved with TxText?

1. By implementing new view, rendered by Athens

2. By introducing new model for storing text to overcome mentioned limitations.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Best regards,
Igor Stasenko.

Nicolai Hess-3-2

Re: TxText model

2016-04-06 9:59 GMT+02:00 Igor Stasenko <[hidden email]>:

On 6 April 2016 at 10:07, Nicolai Hess <[hidden email]> wrote:

2016-04-06 7:57 GMT+02:00 [hidden email] <[hidden email]>:

On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <[hidden email]> wrote:
[hidden email] wrote
> So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and
associated editors?!

A damn lot, I can tell you.

This is where my vim keybindings experiment came
screeching to a halt.

What are the main problems with Text, Paragraph, ... and other old TextComponents?

Thanks Igor.

Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).

1. No support for vector graphics

I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment

rendering a TextMorph in Athens works:
Morph comment asText asMorph openInSceneView

I don't see where the models (Text vs. TxText) is the problem.

2. Most operations are bound to text size.

In what use cases is this a problem ? (Paragraph and DisplayScanner have good support for justified text (left / right / center), indentation

wrapping and (I don't know if this works in pharo anymore but squeak had) even filling text in arbitary shaped polygons ( that was pretty cool).

And even for text of different size and with different emphasis.

And how are these solved with TxText?

1. By implementing new view, rendered by Athens

Ok ,but this could have be done (or is done) with the old Text class as well (no?)

2. By introducing new model for storing text to overcome mentioned limitations.

But this is exactly what I don't understand. How is storing the text in TxText model better than the old Text.

Given that we don't have any (beside TxWorkspace) tools actually using this model.

I have a faint idea how TxText could be easier for building advanced tools, but I don't see that this

model is a crucial point in developing good/better tools for text editing.

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: TxText model

On 6 April 2016 at 11:36, Nicolai Hess <[hidden email]> wrote:

2016-04-06 9:59 GMT+02:00 Igor Stasenko <[hidden email]>:

On 6 April 2016 at 10:07, Nicolai Hess <[hidden email]> wrote:

2016-04-06 7:57 GMT+02:00 [hidden email] <[hidden email]>:

On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <[hidden email]> wrote:
[hidden email] wrote
> So, I ended up in ParagraphEditor, Text attributes etc.

Ugh. How many beautiful projects have died because of Paragraph and
associated editors?!

A damn lot, I can tell you.

This is where my vim keybindings experiment came
screeching to a halt.

What are the main problems with Text, Paragraph, ... and other old TextComponents?

Thanks Igor.
Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).

1. No support for vector graphics

I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment
rendering a TextMorph in Athens works:
Morph comment asText asMorph openInSceneView
I don't see where the models (Text vs. TxText) is the problem.

2. Most operations are bound to text size.

In what use cases is this a problem ? (Paragraph and DisplayScanner have good support for justified text (left / right / center), indentation
wrapping and (I don't know if this works in pharo anymore but squeak had) even filling text in arbitary shaped polygons ( that was pretty cool).
And even for text of different size and with different emphasis.

It is about text size (the total number of characters in Text).

I am aware about those features in Text and of course i feel a pity that we lost some of them in new TxText, because there was so many to make everything at once.

And how are these solved with TxText?

1. By implementing new view, rendered by Athens

Ok ,but this could have be done (or is done) with the old Text class as well (no?)

It could be done. Except that model for text scanning and layout in DisplayScanner & friends are nailed to pixel grid. (You know , all that glyph width + 1, line height - 1.. and things like that all over the place).

It is virtually impossible to turn that into vector-compliant thing.

Because it is pixel based from its very birth.. and trying to convert it to vector form, would be going against the nature of code itself and all design decisions made, centered around the fact that we dealing with pixels.

You right, that asking this question. I was attempted to approach it , because for a lazy person like me, i didn't wanted to start from scratch.. But after wasting couple weeks on that, i came to conclusion that it is hopeless.

Or maybe because i incapable to do it.. choose what you like most :)

2. By introducing new model for storing text to overcome mentioned limitations.

But this is exactly what I don't understand. How is storing the text in TxText model better than the old Text.
Given that we don't have any (beside TxWorkspace) tools actually using this model.
I have a faint idea how TxText could be easier for building advanced tools, but I don't see that this
model is a crucial point in developing good/better tools for text editing.

I giving you a hint: try opening a hundred kilobytes text in TextMorph.

Or just a method with lots of source code in it (we have a number of those in image)

Best regards,
Igor Stasenko.

Igor Stasenko

Re: TxText model

In reply to this post by Nicolai Hess-3-2

On 6 April 2016 at 11:36, Nicolai Hess <[hidden email]> wrote:

Thanks Igor.
Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).

1. No support for vector graphics

I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment
rendering a TextMorph in Athens works:
Morph comment asText asMorph openInSceneView

Sorry, missed to reply to that important point.

It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form

on Athens surface.

So, that is why it 'works' :)

Best regards,
Igor Stasenko.

Denis Kudriashov

Re: TxText model

In reply to this post by Nicolai Hess-3-2

2016-04-06 9:07 GMT+02:00 Nicolai Hess <[hidden email]>:

What are the main problems with Text, Paragraph, ... and other old TextComponents?

I don't want to write crappy words. But to understand what was wrong you can try with them:

remove blinking cursor for specific morph instance
hide selection or change it color for specific morph instance
implement validation for input when only digits are allowed
implement masked fields
try to make all this composable

It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.

Igor Stasenko

Re: TxText model

On 6 April 2016 at 11:56, Denis Kudriashov <[hidden email]> wrote:

Hi

2016-04-06 9:07 GMT+02:00 Nicolai Hess <[hidden email]>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?

I don't want to write crappy words. But to understand what was wrong you can try with them:
remove blinking cursor for specific morph instance
hide selection or change it color for specific morph instance
implement validation for input when only digits are allowed
implement masked fields
try to make all this composable
It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.

Yes, Denis, that was i did not mentioned.

But as i said my main focus was not trying to fix all of the above , but to enable vector-based rendering for text. The rest was coming as a bonus and future work.

Because else, all of it worth nothing if you cannot even render text with Athens..

Best regards,
Igor Stasenko.

Nicolai Hess-3-2

Re: TxText model

In reply to this post by Denis Kudriashov

2016-04-06 10:56 GMT+02:00 Denis Kudriashov <[hidden email]>:

Hi

2016-04-06 9:07 GMT+02:00 Nicolai Hess <[hidden email]>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?

I don't want to write crappy words. But to understand what was wrong you can try with them:
remove blinking cursor for specific morph instance
hide selection or change it color for specific morph instance
implement validation for input when only digits are allowed
implement masked fields
try to make all this composable
It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.

Thanks Denis,
yes this are good points I didn't thought about.

philippeback

Re: TxText model

In reply to this post by Igor Stasenko

On Wed, Apr 6, 2016 at 11:02 AM, Igor Stasenko <[hidden email]> wrote:

On 6 April 2016 at 11:56, Denis Kudriashov <[hidden email]> wrote:
Hi

2016-04-06 9:07 GMT+02:00 Nicolai Hess <[hidden email]>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?

I don't want to write crappy words. But to understand what was wrong you can try with them:
remove blinking cursor for specific morph instance
hide selection or change it color for specific morph instance
implement validation for input when only digits are allowed
implement masked fields
try to make all this composable
It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.

Yes, Denis, that was i did not mentioned.
But as i said my main focus was not trying to fix all of the above , but to enable vector-based rendering for text. The rest was coming as a bonus and future work.
Because else, all of it worth nothing if you cannot even render text with Athens..

I tried to do some decent hypertext and noticed that features that allowed to do this in Squeak were scrapped (for good reason, but still). And yeah, for long chunks of text... that's a big no no. Note that ParagraphEditor gets recreated all the time. And that rendering of text when there is bold text + italic + normal just didn't aligned properly on the computed text metrics (with StrikeFont at the time, I do not know if this is solved with TrueType fonts and Cairo).

Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings.

Doru did something for Pillar at one point (apparently using PetitParser and island parser).

I am also looking at Grafoscopio but need more time to understand what's in it.

Still TxText is a good thing to have.

We must have proper text management for such an OO platform.

They manage to do things in Jetbrains tools (IDEA, WebStorm...) and that's pure Java/Swing (from what I know having worked extensively in Swing at one point is that internals of Swing are also messy, but less, and in other ways)

Doable then.

Big hopes in Bloc/Brick here, will try to do my ideas again with them.

Phil

--
Best regards,
Igor Stasenko.

Stephan Eggermont-3

Re: TxText model

In reply to this post by Nicolai Hess-3-2

On 06-04-16 10:36, Nicolai Hess wrote:
> In what use cases is this a problem ? (Paragraph and DisplayScanner
> have good support for justified text (left / right / center),
> indentation wrapping and (I don't know if this works in pharo anymore
> but squeak had) even filling text in arbitary shaped polygons ( that
> was pretty cool). And even for text of different size and with
> different emphasis.

|t1 t2 ball page|
page := Morph new.
page bounds: (100@100 corner: 300@300).
page color: Color gray.
t1 := TextMorph new.
t1 autoFit:false.
t1 bounds: (105@105 corner: 195@295).
t1 backgroundColor: Color white.
t1 occlusionsOnOff.
page addMorph: t1.
t2 := TextMorph new.
t2 autoFit: false.
t2 bounds: (205@105 corner: 295@295).
t2 backgroundColor: Color white.
t2 occlusionsOnOff.
page addMorph: t2.
t1 setSuccessor: t2.
t2 setPredecessor: t1.
ball := CircleMorph new.
ball bounds: (160@160 corner: 240@240).
page addMorph: ball.
page openInWorld

Screenshot from 2016-04-06 12-18-04.png (25K) Download Attachment

1234