[ann] moldable brick editor - alpha
Hi, We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors. Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters. The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor. Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area. The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice. We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector. This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable. We will continue the work on this over the next period and we expect to announce new developments soon. If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development Please let us know what you think. Cheers, Alex and Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"
This is gorgeous! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Aug 4, 2017, at 6:19 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
<AC36A55F-405C-6147-9E0F-BA1F6F1008BA.png>
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
It seems to be very snappy considering the size of the file and its amount of characters. I still don't get how Bloc and Brick plays in current Pharo, nor what this "moldability" adds to it. But performancewise it seems to be an improvement over the existing editor (Rubric?). Congratulations! Esteban A. Maringolo 2017-08-05 7:52 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
This is gorgeous!
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Aug 4, 2017, at 6:19 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/ wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
<AC36A55F-405C-6147-9E0F-BA1F6F1008BA.png>
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Awesome news. Maybe will we have a way to get vim style bindings with it. Will we? Phil On Aug 5, 2017 00:20, "Tudor Girba" <tudor@tudorgirba.com> wrote:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/ wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Good job guys. Here is my feedback: 1) Loading in Pharo 7 signal dependency error: This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar Then I proceed and it was loaded fine. And editor works like in demo. 2) Text cursor up/down is not working correctly when text is wrapped. - it jumps between real text line instead of visual wrapped lines. - it skips empty lines - sometimes it is just not moved (not found concrete case) 3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this? 4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached: 2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/ wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Hi Denis, Thanks a lot for looking into it :) See my answers for every point below: 1) Loading in Pharo 7 signal dependency error: That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though. 2) Text cursor up/down is not working correctly when text is wrapped. Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :) 3) I look a bit at text commands (TextEditorCommand) and found that current
KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;) P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this: [image: Inline images 1] 4) I thing we should try to use Commander for new UI widgets. For example
It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings). Cheers, Alex On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
I wonder how this editor compares, memory and speedwise, with the something like this: https://medium.freecodecamp.org/why-i-still-use-vim-67afd76b4db6 Regards! Esteban A. Maringolo 2017-08-06 15:07 GMT-03:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error:
That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
2) Text cursor up/down is not working correctly when text is wrapped.
Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that
current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;) P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
[image: Inline images 1]
4) I thing we should try to use Commander for new UI widgets. For example
It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error:
That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
Can you be more precise so that we can take action?
2) Text cursor up/down is not working correctly when text is wrapped.
Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that
current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;)
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
[image: Inline images 1]
4) I thing we should try to use Commander for new UI widgets. For example
It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Hi Stef, Can you be more precise so that we can take action? In ConfigurationOfOSWindow there is the following dependency: spec *with*: 'OSWindow-SDL2' with: [ spec requires: #('OSWindow-Core' 'Athens' ) ] The problem is that OSWindow-SDL2 depends on Athens which is strange, because windowing system should not know anything about rendering and Athens (or Pompeii or Sparta). In Bloc we use OSWindow to support native windows and have a corresponding dependency in BaselineOfBloc. It means that when loading Bloc monticello (or metacello) updates OSWindow which requests loading of Athens. At the same time there are some Morphic classes that were removed in Pharo 7 while Athens adds extension methods to those classes. So we should either update Athens to remove those extensions method and (which is better) make OSWindow independent from Athens. Just remember that we will not add new things in Pharo if we do not remove
the equivalent already in the system. I'm fed up to have three different half working mechanisms.
Key class exists in Pharo by default and is already used by morphic: KeyboardEvent>>#key. We just reuse existing stuff :) Cheers, Alex On 9 August 2017 at 20:17, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error:
That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
Can you be more precise so that we can take action?
2) Text cursor up/down is not working correctly when text is wrapped.
Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that
current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;)
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
[image: Inline images 1]
4) I thing we should try to use Commander for new UI widgets. For example
It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
On Wed, Aug 9, 2017 at 10:17 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Stef,
Can you be more precise so that we can take action?
In ConfigurationOfOSWindow there is the following dependency:
spec *with*: 'OSWindow-SDL2' with: [ spec requires: #('OSWindow-Core' 'Athens' ) ]
The problem is that OSWindow-SDL2 depends on Athens which is strange, because windowing system should not know anything about rendering and Athens (or Pompeii or Sparta). In Bloc we use OSWindow to support native windows and have a corresponding dependency in BaselineOfBloc. It means that when loading Bloc monticello (or metacello) updates OSWindow which requests loading of Athens. At the same time there are some Morphic classes that were removed in Pharo 7 while Athens adds extension methods to those classes. So we should either update Athens to remove those extensions method and (which is better) make OSWindow independent from Athens.
Just remember that we will not add new things in Pharo if we do not remove
the equivalent already in the system. I'm fed up to have three different half working mechanisms.
Key class exists in Pharo by default and is already used by morphic: KeyboardEvent>>#key. We just reuse existing stuff :)
Please yes, use it and propose enhancements to it :) Key was meant as a portable way to identify a key. It internally stores the platform key codes sent by the vm and maps them to a single representation so the image is agnostic of the platform. Of course this was meant for the current implementation of events in the VM. I have no idea of what should be done for it in the case of OSWindow.
Cheers, Alex
On 9 August 2017 at 20:17, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error:
That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
Can you be more precise so that we can take action?
2) Text cursor up/down is not working correctly when text is wrapped.
Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that
current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;)
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
[image: Inline images 1]
4) I thing we should try to use Commander for new UI widgets. For
example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
2017-08-09 22:17 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi Stef,
Can you be more precise so that we can take action?
In ConfigurationOfOSWindow there is the following dependency:
spec *with*: 'OSWindow-SDL2' with: [ spec requires: #('OSWindow-Core' 'Athens' ) ]
So Bloc depends on particular version of OSWindow/Athens. We should update image with new versions. Can you make push request?
The problem is that OSWindow-SDL2 depends on Athens which is strange, because windowing system should not know anything about rendering and Athens (or Pompeii or Sparta). In Bloc we use OSWindow to support native windows and have a corresponding dependency in BaselineOfBloc. It means that when loading Bloc monticello (or metacello) updates OSWindow which requests loading of Athens. At the same time there are some Morphic classes that were removed in Pharo 7 while Athens adds extension methods to those classes. So we should either update Athens to remove those extensions method and (which is better) make OSWindow independent from Athens.
Just remember that we will not add new things in Pharo if we do not remove
the equivalent already in the system. I'm fed up to have three different half working mechanisms.
Key class exists in Pharo by default and is already used by morphic: KeyboardEvent>>#key. We just reuse existing stuff :)
Cheers, Alex
On 9 August 2017 at 20:17, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error:
That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
Can you be more precise so that we can take action?
2) Text cursor up/down is not working correctly when text is wrapped.
Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that
current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;)
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
[image: Inline images 1]
4) I thing we should try to use Commander for new UI widgets. For
example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Hi alex I added https://pharo.fogbugz.com/f/cases/20298/Check-and-remove-Athens-dependency-f... But it would be better that you enter bug entry and not me because IT DOES NOT SCALE. Stef On Wed, Aug 9, 2017 at 10:17 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Stef,
Can you be more precise so that we can take action?
In ConfigurationOfOSWindow there is the following dependency:
spec *with*: 'OSWindow-SDL2' with: [ spec requires: #('OSWindow-Core' 'Athens' ) ]
The problem is that OSWindow-SDL2 depends on Athens which is strange, because windowing system should not know anything about rendering and Athens (or Pompeii or Sparta). In Bloc we use OSWindow to support native windows and have a corresponding dependency in BaselineOfBloc. It means that when loading Bloc monticello (or metacello) updates OSWindow which requests loading of Athens. At the same time there are some Morphic classes that were removed in Pharo 7 while Athens adds extension methods to those classes. So we should either update Athens to remove those extensions method and (which is better) make OSWindow independent from Athens.
Just remember that we will not add new things in Pharo if we do not remove
the equivalent already in the system. I'm fed up to have three different half working mechanisms.
Key class exists in Pharo by default and is already used by morphic: KeyboardEvent>>#key. We just reuse existing stuff :)
Cheers, Alex
On 9 August 2017 at 20:17, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error:
That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
Can you be more precise so that we can take action?
2) Text cursor up/down is not working correctly when text is wrapped.
Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive_...> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that
current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;)
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
[image: Inline images 1]
4) I thing we should try to use Commander for new UI widgets. For
example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error:
This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar
Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped.
- it jumps between real text line instead of visual wrapped lines.
- it skips empty lines
- sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
[image: Playground @ ⢠a8rEditorE1ement x Page â BrRopedText string: Emphasizing everything text : nothing' text attributes: { BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: (BrTextEdi tor new text: text) .]
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Thanks Stef! Doru
On Aug 10, 2017, at 11:52 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi alex
I added https://pharo.fogbugz.com/f/cases/20298/Check-and-remove-Athens-dependency-f... But it would be better that you enter bug entry and not me because IT DOES NOT SCALE.
Stef
On Wed, Aug 9, 2017 at 10:17 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote: Hi Stef,
Can you be more precise so that we can take action?
In ConfigurationOfOSWindow there is the following dependency:
spec
with: 'OSWindow-SDL2' with: [ spec requires: #('OSWindow-Core' 'Athens' ) ]
The problem is that OSWindow-SDL2 depends on Athens which is strange, because windowing system should not know anything about rendering and Athens (or Pompeii or Sparta). In Bloc we use OSWindow to support native windows and have a corresponding dependency in BaselineOfBloc. It means that when loading Bloc monticello (or metacello) updates OSWindow which requests loading of Athens. At the same time there are some Morphic classes that were removed in Pharo 7 while Athens adds extension methods to those classes. So we should either update Athens to remove those extensions method and (which is better) make OSWindow independent from Athens.
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
Key class exists in Pharo by default and is already used by morphic: KeyboardEvent>>#key. We just reuse existing stuff :)
Cheers, Alex
On 9 August 2017 at 20:17, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel@gmail.com> wrote: Hi Denis,
Thanks a lot for looking into it :) See my answers for every point below:
1) Loading in Pharo 7 signal dependency error: That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though.
Can you be more precise so that we can take action?
2) Text cursor up/down is not working correctly when text is wrapped. Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.movâ Bloc has support of element-independent visual focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination.
It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on Key and not on Character + modifiers while defining shortcuts. It allows us to build any key combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;)
Just remember that we will not add new things in Pharo if we do not remove the equivalent already in the system. I'm fed up to have three different half working mechanisms.
P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this:
<Screen Shot 2017-08-06 at 20.03.11.png>
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that they all are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings).
Cheers, Alex
On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote: Good job guys.
Here is my feedback:
1) Loading in Pharo 7 signal dependency error: This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar Then I proceed and it was loaded fine. And editor works like in demo.
2) Text cursor up/down is not working correctly when text is wrapped. - it jumps between real text line instead of visual wrapped lines. - it skips empty lines - sometimes it is just not moved (not found concrete case)
3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this?
4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached:
2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.
Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be
The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.
The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.
Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.
The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice.
We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.
<AC36A55F-405C-6147-9E0F-BA1F6F1008BA.png>
This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.
We will continue the work on this over the next period and we expect to announce new developments soon.
If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development
Please let us know what you think.
Cheers, Alex and Doru
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
-- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."
participants (8)
-
Alexandre Bergel -
Aliaksei Syrel -
Denis Kudriashov -
Esteban A. Maringolo -
Guillermo Polito -
philippe.back＠highoctane.be -
Stephane Ducasse -
Tudor Girba