Thanks Stef!

Doru



> On Aug 10, 2017, at 11:52 AM, Stephane Ducasse <stepharo.s...@gmail.com> 
> wrote:
> 
> Hi alex
> 
> I added 
> https://pharo.fogbugz.com/f/cases/20298/Check-and-remove-Athens-dependency-from-OSWindow
> 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.sy...@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.s...@gmail.com> wrote:
> 
> 
> On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.sy...@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 <dionisi...@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 <tu...@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."





Reply via email to