Thanks Stef! Doru
> On Aug 10, 2017, at 11:52 AM, Stephane Ducasse <[email protected]> > 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 <[email protected]> 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 <[email protected]> wrote: > > > On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <[email protected]> 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 <[email protected]> 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 <[email protected]>: > 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."
