[Pharo-project] TextModel review and discussion
Hi, today, me, Tristan and Camillo took some overview on existing code and discussed further steps. TxAttributes 'contents' should be private (no getter/setter) because if you can directly manipulate the underlying collection, then what is the point of having separate class? Text Attributes in general: - we discussed and decided that it would be better that model will keep abstract attributes for text , like - bold - italic - font family name the view then can compute the real font to use, but model don't have to deal with real font(s). This will imply having more complex attribute(s): you will be forced to visit them all to determine all of the font properties of a final font to use. The attributes in span should behave like a set (you cannot apply same attribute once), and hence implement #= and #hash properly. Also, i think, since neither bold, nor italic attributes don't need to be represented by multiple instances of same class, we could use convenience methods (by introducing them) in TxAttribute class to get a singletons for those ones, e.g.: selection applyAttribute: TxAttribute bold Layout: - right now, when you do layout it will split spans of txmodel. Which should not happen. We discussed about it and agreed that layouts(views) should not modify anything in text model. Instead the information about where line has to be split (like when you need to wrap a text) should be kept separately by a view. We thought that it would be nicer to implement a new span type (layoutspan), which will hold an text-interval (pos1, pos2) and probably any additional information (like caching the width/height) to not recalculate this stuff if nothing changed in model. We did some cosmetic changes to configuration.. to merge Tristan's code into it and load most recent packages: Gofer it smalltalkhubUser: 'sig' project: 'TxText'; package: 'ConfigurationOfTxText'; load. (ConfigurationOfTxText project version: '0.3') load: 'Tests' -- Best regards, Igor Stasenko.
Cool :) We really need to kill this ugly monster, and make it turn into a nice butterfly for 3.0 :) Just a tiny question: Shouldn't the code belong to RMoD team instead of Igor on SmalltalkHub ? Ben On Feb 6, 2013, at 3:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, today, me, Tristan and Camillo took some overview on existing code and discussed further steps.
TxAttributes 'contents' should be private (no getter/setter)
because if you can directly manipulate the underlying collection, then what is the point of having separate class?
Text Attributes in general:
- we discussed and decided that it would be better that model will keep abstract attributes for text , like - bold - italic - font family name
the view then can compute the real font to use, but model don't have to deal with real font(s).
This will imply having more complex attribute(s): you will be forced to visit them all to determine all of the font properties of a final font to use.
The attributes in span should behave like a set (you cannot apply same attribute once), and hence implement #= and #hash properly.
Also, i think, since neither bold, nor italic attributes don't need to be represented by multiple instances of same class, we could use convenience methods (by introducing them) in TxAttribute class to get a singletons for those ones, e.g.:
selection applyAttribute: TxAttribute bold
Layout: - right now, when you do layout it will split spans of txmodel. Which should not happen.
We discussed about it and agreed that layouts(views) should not modify anything in text model. Instead the information about where line has to be split (like when you need to wrap a text) should be kept separately by a view.
We thought that it would be nicer to implement a new span type (layoutspan), which will hold an text-interval (pos1, pos2) and probably any additional information (like caching the width/height) to not recalculate this stuff if nothing changed in model.
We did some cosmetic changes to configuration.. to merge Tristan's code into it and load most recent packages:
Gofer it smalltalkhubUser: 'sig' project: 'TxText'; package: 'ConfigurationOfTxText'; load.
(ConfigurationOfTxText project version: '0.3') load: 'Tests'
-- Best regards, Igor Stasenko.
Benjamin Van Ryseghem-2 wrote
We really need to kill this ugly monster, and make it turn into a nice butterfly for 3.0 :)
YES!!! -- View this message in context: http://forum.world.st/TextModel-review-and-discussion-tp4668021p4668025.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 6 February 2013 16:05, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
Cool :)
We really need to kill this ugly monster, and make it turn into a nice butterfly for 3.0 :)
Just a tiny question: Shouldn't the code belong to RMoD team instead of Igor on SmalltalkHub ?
i am not sure about it. right now it is developed by Denis and Tristan, who are not members of rmod team. btw thanks for question: it raising interesting question about smalltalkhub functionality: it would be nice if project ownership can be transferred between groups/individuals without physically copying files.
Ben
On Feb 6, 2013, at 3:56 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, today, me, Tristan and Camillo took some overview on existing code and discussed further steps.
TxAttributes 'contents' should be private (no getter/setter)
because if you can directly manipulate the underlying collection, then what is the point of having separate class?
Text Attributes in general:
- we discussed and decided that it would be better that model will keep abstract attributes for text , like - bold - italic - font family name
the view then can compute the real font to use, but model don't have to deal with real font(s).
This will imply having more complex attribute(s): you will be forced to visit them all to determine all of the font properties of a final font to use.
The attributes in span should behave like a set (you cannot apply same attribute once), and hence implement #= and #hash properly.
Also, i think, since neither bold, nor italic attributes don't need to be represented by multiple instances of same class, we could use convenience methods (by introducing them) in TxAttribute class to get a singletons for those ones, e.g.:
selection applyAttribute: TxAttribute bold
Layout: - right now, when you do layout it will split spans of txmodel. Which should not happen.
We discussed about it and agreed that layouts(views) should not modify anything in text model. Instead the information about where line has to be split (like when you need to wrap a text) should be kept separately by a view.
We thought that it would be nicer to implement a new span type (layoutspan), which will hold an text-interval (pos1, pos2) and probably any additional information (like caching the width/height) to not recalculate this stuff if nothing changed in model.
We did some cosmetic changes to configuration.. to merge Tristan's code into it and load most recent packages:
Gofer it smalltalkhubUser: 'sig' project: 'TxText'; package: 'ConfigurationOfTxText'; load.
(ConfigurationOfTxText project version: '0.3') load: 'Tests'
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Hello. Sorry for long silence. I was at vacation without internet. So I found this mail only now. 2013/2/6 Igor Stasenko <siguctua@gmail.com>
Hi, today, me, Tristan and Camillo took some overview on existing code and discussed further steps.
TxAttributes 'contents' should be private (no getter/setter)
because if you can directly manipulate the underlying collection, then what is the point of having separate class?
I need accessors for tests and "manual debugging". You can look at TxAttributesTests to see my point. It includes separate tests for adding new attributes and for getting it by concrete attribute class. Without #contents method I can't write such tests. Adding and getting attributes are different behaviour. If you want independant unit tests for your objects you need accessors for all instance variables. By "manual debugging" I mean ability to script object state in inspectors and workspaces. I really hate situations when I can't see state of object in debugger by simple "printIt" operation on "object someState". It always force me to open another tool like inspector or browser which slow down my workflow of exploring some system behaviour. That's why I really like idea about auto accessors for any instance variables: you add new instance variable and system automatically add accessors. You know Self, Newspeak and javascript has this by language design (not sure about newspeak). If you talk about incapsulation as system design property It has no relation to accessors existence. It has relation to accessors usage. And I'm sure we all agree that code inside span class like "attributes contents at: TxFontAttribute" is very bad idea. But unit tests need this.
Text Attributes in general:
- we discussed and decided that it would be better that model will keep abstract attributes for text , like - bold - italic - font family name
the view then can compute the real font to use, but model don't have to deal with real font(s).
This will imply having more complex attribute(s): you will be forced to visit them all to determine all of the font properties of a final font to use.
I have no idea why this is better than real font. Can you explain? Because you said "This will imply having more complex attribute(s)". So why more complex attributes is better? What give us separation font to primitive properties? In any case I'm not fimiliar with font system. So I'm not know what bold, italic properties mean inside font instance. Can this properties be extracted from font instance?
The attributes in span should behave like a set (you cannot apply same attribute once), and hence implement #= and #hash properly.
Attributes accessing api guarantee it. If you add different font attributes twice only last font stay. Contents of TxAttributes is dictionary with "Attribute class->attribute" structure.
Also, i think, since neither bold, nor italic attributes don't need to be represented by multiple instances of same class, we could use convenience methods (by introducing them) in TxAttribute class to get a singletons for those ones, e.g.:
selection applyAttribute: TxAttribute bold
Interesting thing about first class attributes is how they can be used for text drawing. Current morphic implementation: TxCharactersSpan>>drawOn: aCanvas at: aPoint aCanvas drawString: characters at: aPoint font: (self getAttribute: TxFontAttribute) color: (self getAttribute: TxForeColorAttribute) But with athens it can be: TxCharactersSpan>>drawOnAthens: aCanvas attributes applyOn: aCanvas. aCanvas drawString: characters. And each attribute can change athens canvas state for drawing like: TxFontAttribute>>applyOn: aCanvas aCanvas font: value Is it possible with separated primitive font properties? Layout:
- right now, when you do layout it will split spans of txmodel. Which should not happen.
It is not happen.
We discussed about it and agreed that layouts(views) should not modify anything in text model.
Layout just creates new splitted spans without source span modification. Text model not changed.
Instead the information about where line has to be split (like when you need to wrap a text) should be kept separately by a view.
We thought that it would be nicer to implement a new span type (layoutspan), which will hold an text-interval (pos1, pos2) and probably any additional information (like caching the width/height) to not recalculate this stuff if nothing changed in model.
I think about it too. But first I want readonly text morph which works with different layout strategies. So I just reuse existed spans. I gather introduce special object (layoutspan) to implement editing stuff. And I think this layoutspan can make very simple implementation of text selection drawing. LayoutSpan can have own attributes which will override underlyng span attributes during drawing. And visual text selection will apply special font/color attributes to selected layout spans. What you think about it? Best regards, Denis
We did some cosmetic changes to configuration.. to merge Tristan's code into it and load most recent packages:
Gofer it smalltalkhubUser: 'sig' project: 'TxText'; package: 'ConfigurationOfTxText'; load.
(ConfigurationOfTxText project version: '0.3') load: 'Tests'
-- Best regards, Igor Stasenko.
participants (4)
-
Benjamin -
Denis Kudriashov -
Igor Stasenko -
Sean P. DeNigris