[Pharo-dev] [Pharo-users] [ann] moldable brick editor - alpha

Guillermo Polito guillermopolito at gmail.com
Thu Aug 10 03:38:28 EDT 2017


On Wed, Aug 9, 2017 at 10:17 PM, Aliaksei Syrel <alex.syrel at 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 at gmail.com>
> wrote:
>
>>
>>
>> On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel at 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_web>
>>>>>> 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170810/0de23516/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-08-06 at 20.03.11.png
Type: image/png
Size: 522445 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170810/0de23516/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AC36A55F-405C-6147-9E0F-BA1F6F1008BA.png
Type: image/png
Size: 151365 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170810/0de23516/attachment-0003.png>


More information about the Pharo-dev mailing list