August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec menu extensibility (epicea)

by Stephane Ducasse

Since we can get the method and from the method the class I would not put the context:. On Thu, Aug 10, 2017 at 9:48 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi Stef, > > I use both a variant with an argument and without, however I have slightly modified PragmaMenuBuilder to support this. > > e.g. I have > > <opEditorToolbarMenu> which always adds entries to a particular menu. > <opEditorToolbarMenu: #OPUmlClassEditorPlugin> which adds entries only when some particular context is active (here it would mean that the items are added only when ClassEditor plugin is active) > > (The second case can be done with a local if condition, but I found this to be more practical.) > > I don't see a benefit in having 'order' as part of the pragma, because you can specify the order for the menu items themselves. > > What I am still wondering is whether it is better to have a different pragma for each menu, or have the menu name as an argument. The same goes for differentiating pragmas between different tools. > > e.g. > > <opEditorToolBarMenu: #OPUmlClassEditorPlugin> vs <menu: #EditorToolbar tool: #OP context: #OPUmlClassEditorPlugin> > > the latter seems like it's adding more complexity. > > Peter > > > On Wed, Aug 09, 2017 at 09:58:54PM +0200, Stephane Ducasse wrote: >> Hi Peter >> >> Yes I was thinking about it. >> Now from your experience what kind of pragma should we provide? >> >> <group: 'name' order: 10> >> >> Not sure that we need the argument to the group. >> >> <menusForGroup: 'name'> >> >> <menuForGroup: 'name' order: 10> >> >> Stef >> >> >> >> >> On Sun, Aug 6, 2017 at 12:09 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> > Hi Stef, >> > >> > I faced similar issue and then I've found out that PragmaMenuBuilder is compatible with Spec. >> > >> > Something like... >> > >> > builder := PragmaMenuBuilder pragmaKeyword: 'myPragma' model: self. >> > menu := MenuModel new. >> > menu fromSpec: builder menuSpec. >> > >> > Peter >> > >> > >> > On Sat, Aug 05, 2017 at 06:26:45PM +0200, Stephane Ducasse wrote: >> >> Hi guys >> >> >> >> I would like to know if there is a pattern to build extensible menu in Spec. >> >> For example, I extending Epicea to support pillar fileout so that I >> >> can turn a coding section into a pillar steps of action. >> >> >> >> I wanted to extend the epicea browser to get my menu in: >> >> But the code is like that: >> >> >> >> EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu >> >> >> >> aMenu addGroup: [ :aGroup | >> >> self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | >> >> aGroup addItem: [ :anItem | >> >> anItem >> >> name: oldStyleMenuItemArray first; >> >> description: oldStyleMenuItemArray third; >> >> icon: (self iconNamed: oldStyleMenuItemArray fourth); >> >> action: [ self perform: oldStyleMenuItemArray second ] ] ] ]. >> >> >> >> aMenu addGroup: [ :aGroup | >> >> aGroup addItem: [ :anItem | >> >> anItem >> >> name: 'Filters'; >> >> icon: (self iconNamed: #smallFindIcon); >> >> subMenu: self filtersSubMenu ] ]. >> >> >> >> aMenu addGroup: [ :aGroup | >> >> aGroup addItem: [ :anItem | >> >> anItem >> >> name: 'File Out'; >> >> description: 'Write selected entries to an Ombu file'; >> >> icon: (self iconNamed: #smallSaveAsIcon); >> >> action: [ self fileOutSelection ] ] ]. >> >> >> >> >> >> EPLogBrowserModel >> menuMorphForSelectedItems >> >> >> >> | aMenu | >> >> aMenu := MenuModel new. >> >> showEntryItemMenu ifTrue: [ self >> >> addMenuItemsForSelectedItemsIn: aMenu ]. >> >> ^ aMenu buildWithSpecAsPopup >> >> >> >> >> >> So I would like to improve Epicea but I face the problem of the limits >> >> of Spec (presumably). >> >> I'm thinking to add a <specMenu: 10> pragma to handle this case. >> >> Any thought. >> >> >> >> Stef >> >> >> > >> >

Aug. 10, 2017

Re: [Pharo-dev] [Pharo 70] build 19 / PR-168

by Stephane Ducasse

:) Yes I launch a rebuild. On Wed, Aug 9, 2017 at 10:40 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Probably you already saw it, but builds are green again. As I told you > this afternoon, there are some hiccups that cause failures from time to > time. We should chase them one by one :) > > Le mer. 9 aoÃ»t 2017 Ã 21:47, Stephane Ducasse <stepharo.self(a)gmail.com> a > Ã©crit : > >> https://pharo.fogbugz.com/f/cases/20238/Run-out-of-memory- >> the-image-hangs-without-out-of-memory-warning >> >> https://github.com/pharo-project/pharo/pull/168 >> >> Now I get message that I do not understand test failure error from >> jenkins :( >> >> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% >> 20pull%20request%20and%20branch%20Pipeline/job/development/19/ >> >> >> I can tell you that leaving the confort zone of a working but weak >> process for the >> promise of a better one is still painful. >> >> Stef >> >> -- > > > > 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 <+33%206%2052%2070%2066%2013> >

Aug. 10, 2017

[Pharo 70] Build 22 / PR 169

by Stephane Ducasse

Build 22 https://github.com/pharo-project/pharo/pull/169 https://pharo.fogbugz.com/f/cases/20249/Add-some-colors-to-the-themes

Aug. 10, 2017

Re: [Pharo-dev] Pull requests ready to be reviewed

by Serge Stinckwich

This is great to see the workflow start to emerge. I guess all PRs tagged with human-review-needed are the one to take care ? https://github.com/pharo-project/pharo/pulls?q=is%3Apr+is%3Aopen+label%3Ahu… On Wed, Aug 9, 2017 at 10:09 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > We have several pull requests validated successfully by the > infrastructure. They need to be reviewed by humans: > > https://github.com/pharo-project/pharo/pull/75 > > https://github.com/pharo-project/pharo/pull/66 > > https://github.com/pharo-project/pharo/pull/175 > > https://github.com/pharo-project/pharo/pull/172 > > https://github.com/pharo-project/pharo/pull/169 > > https://github.com/pharo-project/pharo/pull/168 > > https://github.com/pharo-project/pharo/pull/134 > > Cheers, > -- Pavel > > > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 10, 2017

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

by Denis Kudriashov

2017-08-09 22:17 GMT+02:00 Aliaksei Syrel <alex.syrel(a)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(a)gmail.com> > wrote: > >> >> >> On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel(a)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(a)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(a)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?" >>>>> >>>>> >>>> >>> >> >

Aug. 10, 2017

Re: [Pharo-dev] Spec menu extensibility (epicea)

by Peter Uhnak

Hi Stef, I use both a variant with an argument and without, however I have slightly modified PragmaMenuBuilder to support this. e.g. I have <opEditorToolbarMenu> which always adds entries to a particular menu. <opEditorToolbarMenu: #OPUmlClassEditorPlugin> which adds entries only when some particular context is active (here it would mean that the items are added only when ClassEditor plugin is active) (The second case can be done with a local if condition, but I found this to be more practical.) I don't see a benefit in having 'order' as part of the pragma, because you can specify the order for the menu items themselves. What I am still wondering is whether it is better to have a different pragma for each menu, or have the menu name as an argument. The same goes for differentiating pragmas between different tools. e.g. <opEditorToolBarMenu: #OPUmlClassEditorPlugin> vs <menu: #EditorToolbar tool: #OP context: #OPUmlClassEditorPlugin> the latter seems like it's adding more complexity. Peter On Wed, Aug 09, 2017 at 09:58:54PM +0200, Stephane Ducasse wrote: > Hi Peter > > Yes I was thinking about it. > Now from your experience what kind of pragma should we provide? > > <group: 'name' order: 10> > > Not sure that we need the argument to the group. > > <menusForGroup: 'name'> > > <menuForGroup: 'name' order: 10> > > Stef > > > > > On Sun, Aug 6, 2017 at 12:09 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi Stef, > > > > I faced similar issue and then I've found out that PragmaMenuBuilder is compatible with Spec. > > > > Something like... > > > > builder := PragmaMenuBuilder pragmaKeyword: 'myPragma' model: self. > > menu := MenuModel new. > > menu fromSpec: builder menuSpec. > > > > Peter > > > > > > On Sat, Aug 05, 2017 at 06:26:45PM +0200, Stephane Ducasse wrote: > >> Hi guys > >> > >> I would like to know if there is a pattern to build extensible menu in Spec. > >> For example, I extending Epicea to support pillar fileout so that I > >> can turn a coding section into a pillar steps of action. > >> > >> I wanted to extend the epicea browser to get my menu in: > >> But the code is like that: > >> > >> EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu > >> > >> aMenu addGroup: [ :aGroup | > >> self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | > >> aGroup addItem: [ :anItem | > >> anItem > >> name: oldStyleMenuItemArray first; > >> description: oldStyleMenuItemArray third; > >> icon: (self iconNamed: oldStyleMenuItemArray fourth); > >> action: [ self perform: oldStyleMenuItemArray second ] ] ] ]. > >> > >> aMenu addGroup: [ :aGroup | > >> aGroup addItem: [ :anItem | > >> anItem > >> name: 'Filters'; > >> icon: (self iconNamed: #smallFindIcon); > >> subMenu: self filtersSubMenu ] ]. > >> > >> aMenu addGroup: [ :aGroup | > >> aGroup addItem: [ :anItem | > >> anItem > >> name: 'File Out'; > >> description: 'Write selected entries to an Ombu file'; > >> icon: (self iconNamed: #smallSaveAsIcon); > >> action: [ self fileOutSelection ] ] ]. > >> > >> > >> EPLogBrowserModel >> menuMorphForSelectedItems > >> > >> | aMenu | > >> aMenu := MenuModel new. > >> showEntryItemMenu ifTrue: [ self > >> addMenuItemsForSelectedItemsIn: aMenu ]. > >> ^ aMenu buildWithSpecAsPopup > >> > >> > >> So I would like to improve Epicea but I face the problem of the limits > >> of Spec (presumably). > >> I'm thinking to add a <specMenu: 10> pragma to handle this case. > >> Any thought. > >> > >> Stef > >> > > >

Aug. 10, 2017

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

by Guillermo Polito

On Wed, Aug 9, 2017 at 10:17 PM, Aliaksei Syrel <alex.syrel(a)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(a)gmail.com> > wrote: > >> >> >> On Sun, Aug 6, 2017 at 8:07 PM, Aliaksei Syrel <alex.syrel(a)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(a)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(a)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

Aug. 10, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Wed, Aug 09, 2017 at 08:23:50PM +0200, Stephane Ducasse wrote: > Tx! > So that I do not make mistake: > The fix is the second solution. Now do we have somewhere the first one? Not yet. My patch also fixes some inconsistencies in path canonicalisation. I'll separate the code out in to two separate patches and post. Cheers, Alistair > On Wed, Aug 9, 2017 at 10:08 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi > > > > 2017-08-09 8:47 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > >> > >> Hi Stef, > >> > >> On Tue, Aug 08, 2017 at 07:00:04PM +0200, Stephane Ducasse wrote: > >> > Hi Alistair > >> > > >> > I'm going over the green build first. > >> > > >> > - Then also > >> > https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but… > >> > I read it but do you suggest to drop it and close it? > >> > >> I don't think this issue should be dropped, there is a regular stream of > >> questions to the mailing list from newcomers getting confused by the > >> current behaviour. > >> > >> There are basically two opposing proposals: > >> > >> 1. Modify FileReference>>/ to accept a path and parse it correctly > >> (which is what I proposed). > >> 2. Modify FileReference>>/ to explicitly reject an argument which > >> includes the path delimiter (and it should suggest using #resolve:). > >> > >> The first proposal is more "practical", and the second is more "pure", > >> keeping the to original design goals and abstractions. > >> > >> Both have had multiple people support them, and both are better than the > >> current situation, however it is subjective as to which of the two > >> proposals is better. > > > > > > I would vote for first solution > > > >> > >> > >> I'm not sure what the normal tie-breaking process is, but I'm happy to > >> defer to the Pharo Association (Esteban? / Marcus? / yourself?). > >> > >> Cheers, > >> Alistair > >> > > >

Aug. 10, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-08-09 9:33 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 8 Aug 2017, at 23:47, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> > wrote: > > Le 08/08/2017 Ã 23:40, Nicolai Hess a Ã©crit : > > Thanks for the info, cyril. > > What do you use for the ssh username in pharo setting and what username > did you use for creating the ssh-key ? > I tried both, my github-email and my github-username, I didn't get it to > work. > > > I did not use anything special. While creating the ssh key I used all > the default options and in the setting I do not change the username (see > joined screenshot). > > This is the command I probably used since I followed github tutorial[1]: > > ssh-keygen -t rsa -b 4096 -C "cyril.ferlicot(a)gmail.com" > > [1] https://help.github.com/articles/connecting-to-github-with-ssh/ > > > yes, the keys may be an issue, but the standard rsa generated key should > work. We need to do a pass in security/credentials system (and probably a > revamp of some parts), but I still didnât find the time. > about the 255 limitation, if you execute this in command line: > > git config --system core.longpaths true > > it should also fix the problem with pharo repo. > > Esteban > Now I have the same problem. I can not get the pharo repo because it can not operate on files with long path names. even with longpaths true, this does not work ... > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > <PharoScreenshot.png> > > >

Aug. 9, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-08-09 23:18 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-08-08 23:41 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > >> Le 08/08/2017 Ã 23:37, Nicolai Hess a Ã©crit : >> > >> > >> > Like I described above. >> > >> > I followed this howto ( the first mail from pavel). >> > >> > But I get this error: >> > >> > 'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned >> > error' >> > >> > >> > Now I enabled the setting for "Use custom SSH keys", followed the >> > github-doc for adding a ssh-key on windows and add this key to my >> > github-account. >> > But I still get the same error. >> > >> > >> >> To be sure this is not a ssh key problem you can try to install git bash >> and to commit on a repository with a ssh remote. If it works you'll be >> sure the ssh key is good. >> >> > yes, just tested, this seems to work. I can use the key for a ssh remote > commit from the command line. > but somehow I can not use it with pharo /iceberg.. > > Ah, I think I got it to work now. I created a new ssh key, but this time I did not set a passphrase. So maybe, ssh remotes with iceberg are only working if you don't use passphrases for you secret key! > -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >> >

Aug. 9, 2017