On 6 April 2016 at 11:36, Nicolai Hess <[email protected]> wrote:
> > > 2016-04-06 9:59 GMT+02:00 Igor Stasenko <[email protected]>: > >> >> >> On 6 April 2016 at 10:07, Nicolai Hess <[email protected]> wrote: >> >>> >>> >>> 2016-04-06 7:57 GMT+02:00 [email protected] <[email protected]>: >>> >>>> >>>> >>>> On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <[email protected] >>>> > wrote: >>>> >>>>> [email protected] 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.
