Oberon Community Platform Forum

Development => General => Topic started by: BohdanT on January 08, 2009, 06:48:32 PM



Title: WMTextStyleTool and WMTextTool
Post by: BohdanT on January 08, 2009, 06:48:32 PM
Revision: 1038 Author: staubesv
Quote
Use WMTextTool instead of WMTextStyleTool in Menu -> Edit -> Styles. The old text tool is based on the text attribute mechanism. For now, it makes more sense to use this since this prevents the mix-up between text attributes and character styles. In particular, the tool can handle different font sizes much better.

I believe this change has led to more chaos.
   
Perhaps I am wrong, but the mechanism that uses Styles gives great advantages.
For example, the use of color schemes.
A more orderly processing of source code, etc.

I'm upset ... Perhaps now there is no road back  :'(





Title: Re: WMTextStyleTool and WMTextTool
Post by: staubesv on January 09, 2009, 08:38:14 AM
Quote
Perhaps I am wrong, but the mechanism that uses Styles gives great advantages.
You're right, the Styles do give advantages.

Note that the WMTextStyleTool is still available.

The reason why WMTextTool is the default is that all sources are stored in the Oberon text format which does not support styles. When you load such a file and use WMTextStyleTool, this leads to an intermixing of the BBT/Oberon text formats in the internal text representation.

Quote
I'm upset ... Perhaps now there is no road back
As mentioned above, the Style mechanism is still available.


Title: Re: WMTextStyleTool and WMTextTool
Post by: BohdanT on January 09, 2009, 10:00:59 AM
Ok.
I then such a question:
Which text format main in A2?
Which text format is the most promising?


Title: Re: WMTextStyleTool and WMTextTool
Post by: staubesv on January 09, 2009, 11:45:05 AM
Background:
The reason why modules are currently stored as Oberon text is primarly efficiency and compilation speed. To load a BBT text, the XML parser first creates a DOM-Tree which is then transformed into the internal text representation (Texts.Text).
Since the Oberon text format contains all formatting information in the header, the compiler can simply skip the header and then work with plain text. Also, in general, there is no need to build an intermediate representation (as DOM-Tree) when loading an Oberon text.
I can't remember the exact numbers, but building a release with sources that are stored as Oberon text is MUCH faster than BBT.

Your questions are good but ASAIK, currently not addressed here at ETH.

My opinion: The internal text representation should be generic enough to support different text formats with one single mechanism (currently, there are two: Texts.Piece.attributes and Texts.Piece.pstyle/cstyle). The current problem is that the usage of both mechanism in a single Texts.Text does not work correctly.
With one mechanism supporting both formats (maybe use cstyle to represent attributes), we would not have problems.
If a user wants to store a text in a format that does not support all features used in the text, the user would have to be warned and the unsupported features dropped when storing.





Title: Re: WMTextStyleTool and WMTextTool
Post by: BohdanT on January 09, 2009, 01:47:43 PM
Quote
I can't remember the exact numbers, but building a release with sources that are stored as Oberon text is MUCH faster than BBT.
How Giga-Hertz should have a processor that would not have been the main argument?  ;D

Quote
Your questions are good but ASAIK, currently not addressed here at ETH.
   
This is just talk   ;D
Quote
If a user wants to store a text in a format that does not support all features used in the text, the user would have to be warned and the unsupported features dropped when storing.
Sure!
But now when I save, for example, in UTF not warn me that lost unsupported features


Title: Re: WMTextStyleTool and WMTextTool
Post by: staubesv on January 09, 2009, 01:58:04 PM
Quote
How Giga-Hertz should have a processor that would not have been the main argument?
This is something I hate about programming: Good designs are often sacrificed for better performance...

Quote
Sure! But now when I save, for example, in UTF not warn me that lost unsupported features
There is always a lot of work to do  ;D


Title: Re: WMTextStyleTool and WMTextTool
Post by: BohdanT on January 09, 2009, 02:05:06 PM
Quote
This is something I hate about programming: Good designs are often sacrificed for better performance...
http://en.wikipedia.org/wiki/Moore%27s_law (http://en.wikipedia.org/wiki/Moore%27s_law)
 ;)
Quote
There is always a lot of work to do

 ;D


Title: Re: WMTextStyleTool and WMTextTool
Post by: staubesv on January 09, 2009, 04:23:10 PM
Ok. The discussion motivated me to have a look at the text representation issue. So far, I removed all Attributes-related stuff from Texts, TextUtilities and WMTextview (but I have not yet rebooted the system...). If I don't encounter major problems, the situation improves quite soon...


Title: Re: WMTextStyleTool and WMTextTool
Post by: BohdanT on January 09, 2009, 04:30:13 PM
 :D


Title: Re: WMTextStyleTool and WMTextTool
Post by: cfbsoftware on January 10, 2009, 12:55:13 AM
Quote
This is something I hate about programming: Good designs are often sacrificed for better performance...
http://en.wikipedia.org/wiki/Moore%27s_law (http://en.wikipedia.org/wiki/Moore%27s_law)
 ;)

... but, unfortunately:

http://en.wikipedia.org/wiki/Wirth%27s_law (http://en.wikipedia.org/wiki/Wirth%27s_law)
 :(