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

Re: [Pharo-dev] fixing the tab morph

by Pavel Krivanek

I personally think that the tabs in TabGroupMorph look more like tabs :-) -- Pavel 2017-08-07 17:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > Soâ¦ summer project (to do when there is too much hot to go outside): fix > some minor things that are inside the image that annoys me since some time. > > First issue: the tab morph we have is horrible (and makes horrible > anything with it). > Iâve been working on it to fix that âchromish-but-badâ style we had and to > fix some (a lot) hardcoded colors there. > Now, for example, Calypso looks like this: > > > > > which is IMHO a lot better :) > > some remarks: > > 1) I find TabManagerMorph an ugly name. Do you think we should change it? > (I tend to think anything called *Manager, *Controller, etc. as a bad > naming chose and probably the mark of a smell). > 2) much more important: we should deprecate TabGroupMorph and > LazyTabGroupMorph familyâ¦ there should not be more than one widget to do > the same in the system. > > So well, as usual with old things: you fix a little thing and you uncover > a lot of new problems :) > > Esteban > > >

Aug. 8, 2017

FileSystem fix integration

by Stephane Ducasse

Hi alistair I will go over all the FS changes and push them in Pharo 70. I'm learning the process to integrate fixes and I attract bugs :) Stef

Aug. 8, 2017

Re: [Pharo-dev] Having green builds

by Stephane Ducasse

Yes this is great. Now I will be rerunning the pending fix and integrate the green ones. On Sun, Aug 6, 2017 at 11:00 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi all, > > As you all know, we are now building from github. Integrations are made > through pull requests. And pull requests are validated using jenkins (that > is back again, Yay!). > > In this scenario, pull requests validations in github differentiate only > between three states: Pased (green) and not passed (red). This of course > conflicts with the three-state jobs of jenkins. By default jenkins > transforms failing tests (yellow) to a red state. This means that we lose > the extra information provided by the intermediate state. > > Now, because of this, in order to really differentiate good builds from > bad builds, we need to have green builds :). Always. > > Yesterday we worked with Pablo on that and now we have a PR that fixes all > tests and is green :) > > https://github.com/pharo-project/pharo/pull/184 > > You can follow up all the things we did in the issue also: > > https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 > > As a summary, we could fix most tests by just touching some code here and > there. Some of them were portability issues, some other encoding in the > build slaves and so on. The only one we could not fix was a problem cause > by a side effect of QualityAssistant-Tests, so we skipped it. Those two > tests should be rewritten to not have side effects on other tests (In this > case, Epicea). > > Enjoy, > Guille and Pablo > > -- > > > > 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. 8, 2017

Re: [Pharo-dev] Having green builds

by Tudor Girba

Excellent work! This is the kind of work that does not get much praise, but that provides the solid foundation we all need. Thanks! Doru -- www.tudorgirba.com "Every thing has its own flow" > On 6 Aug 2017, at 13:46, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Great guys, this is the way to go. > >> On Sun, Aug 6, 2017 at 6:00 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Hi all, >> >> As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!). >> >> In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state. >> >> Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always. >> >> Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :) >> >> https://github.com/pharo-project/pharo/pull/184 >> >> You can follow up all the things we did in the issue also: >> >> https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 >> >> As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea). >> >> Enjoy, >> Guille and Pablo >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr >> >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13 >

Aug. 8, 2017

Re: [Pharo-dev] Two tables that share the same data source!?

by Elhamer

Hi Alex and thank you for your reply :)) Good to know that bloc already supports that, I am definitely moving to work on/with it after that :)) I've never encounter that scenario on a a Pharo package too, but since i was working on improving FTs, i thought why not!, besides, in apps with multiple tables, it might be handy to define a single large data source and assign columns to each table instead of defining a ds for each table, something like that: ```` |pane table1 table2 ds| ds:=FTCellSampleDataSource new:10. table1 := FTTableMorph new extent: 500@500; selectionMode: #column; addColumn: (FTColumn id: 'column1'); addColumn: (FTColumn id: 'column2'); addColumn: (FTColumn id: 'column6'); dataSource: ds; selectRowIndex: 1; showFirstRowSelection; beMultipleSelection; yourself. table2 := FTTableMorph new extent: 500@500; selectionMode: #column; addColumn: (FTColumn id: 'column3'); addColumn: (FTColumn id: 'column4'); addColumn: (FTColumn id: 'column5'); dataSource: ds; selectRowIndex: 1; showFirstRowSelection; beMultipleSelection; layoutInset: 10; yourself. pane := Morph new. pane layoutPolicy: TableLayout new. pane listDirection: #leftToRight. pane listCentering: #center. pane wrapCentering: #center. pane hResizing: #spaceFill. pane layoutInset: 10@10. pane cellInset:10@10. pane color: Color red. pane addMorph: table1. pane addMorph: table2. pane openInWindow . ``` <http://forum.world.st/file/n4959160/two_tables_single_ds.png> -- View this message in context: http://forum.world.st/Two-tables-that-share-the-same-data-source-tp4959153p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 8, 2017

Re: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names

by Ben Coman

On Mon, Aug 7, 2017 at 7:32 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> >>> On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >>>>> About tagging... It looks super ackward to me to tag EVERY commit with >>>>> "build information". >>>>> >>>> >>>> I'm not sure which comment your responding to, >>>> >>> >>> yours :P. Yes, too early, I did not want to properly quote... >>> >>> >>>> and not sure what you mean by "build information", >>>> >>> >>> In this particular case I mean build number. >>> >>> but obviously someone may do several commits before doing a pull >>>> request, as they work through developing and testing a fix for an Issue. >>>> Its only the successful builds that are uploaded to files.pharo.org >>>> that are important to tag. >>>> >>> >>> But then, why not just going through the files in files.pharo.org and >>> get the corresponding hash from there (since they have the hash they >>> correspond to)? I do not see the practical usecase. It's just redundance, >>> no? >>> >>> >>>> Building does not mean releasing... I prefer the other way around: we >>>>> tag builds with commit information. Like that we know how to reproduce the >>>>> build. >>>>> >>>>> I'm ok with tagging build artifacts by explicitly saying "this is >>>>> BUILD #X", which is ~= from "this is RELEASE #X". >>>>> >>>> >>>> I'd imagine that tagging a commit as BUILD#X would be done as part of >>>> the CI immediately before the upload to files.pharo.org. >>>> >>> >>> That's what I wanto to avoid. Why is that required? The generated file >>> already has a pointer to the git commit it was generated from. Why do we >>> need the backpointer from git to the build? >>> >> >> So should PharoLauncher attach a datestamp to each entity? >> There needs to be something visible that a human can sort by. >> I guess this is an interim solution until PharoLauncher is made to work >> with Iceberg, but we need something working until then. >> > > But PharoLauncher does not access commits. It never did. I think it gets > all information from the file server and the naming schema of files... > Yes. Which is why we need either: * the filenames on the file server to include a build number or date * PharoLauncher modified to get the date from the directory info to mix into its displayed name which is preferable? cheers -ben

Aug. 8, 2017

Re: [Pharo-dev] Two tables that share the same data source!?

by Aliaksei Syrel

Hello Elhamer, Do you have an idea when it might be useful to have two lists representing the same datasource? We have this feature in bloc (see video in attachment) but I didn't encounter a real-life use-case yet... Cheers, Alex â Bloc-TwoListsOneDataSource.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVWpYdzF5dmlIT2Ftbm9yUVBpazNMVE…> â On 8 August 2017 at 02:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hello Elhamer, > > Do you have an idea when it might be useful to have two lists representing > the same datasource? > We have this feature in bloc (see video in attachment) but I didn't > encounter a real-life use-case yet... > > Cheers, > Alex > > On 8 August 2017 at 01:36, Elhamer <abdelkhalekdev(a)gmail.com> wrote: > >> Hello everybody, >> >> How common is it for multiple tables (FastTables) to have the same >> datasource ? >> >> The FTDataSource has a instance variable to refer a table: >> >> ```` >> Object subclass: #FTDataSource >> instanceVariableNames: 'table' >> classVariableNames: '' >> package: 'Morphic-Widgets-FastTable-DataSource' >> ``` >> >> >> which makes it impossible for several tables to have the same data source. >> the code of the data source is also coupled to the ft code which also >> makes >> it harder to extend. >> >> I've tried to go down the rabbit hole and decouple the data source from >> the >> table but things went messy. So i would like to know how common it is for >> several tables to share the same ds, and does that worth going the extra >> mile ? >> >> Thanks, >> Elhamer. >> >> >> >> -- >> View this message in context: http://forum.world.st/Two-tabl >> es-that-share-the-same-data-source-tp4959153.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

Aug. 8, 2017

Two tables that share the same data source!?

by Elhamer

Hello everybody, How common is it for multiple tables (FastTables) to have the same datasource ? The FTDataSource has a instance variable to refer a table: ```` Object subclass: #FTDataSource instanceVariableNames: 'table' classVariableNames: '' package: 'Morphic-Widgets-FastTable-DataSource' ``` which makes it impossible for several tables to have the same data source. the code of the data source is also coupled to the ft code which also makes it harder to extend. I've tried to go down the rabbit hole and decouple the data source from the table but things went messy. So i would like to know how common it is for several tables to share the same ds, and does that worth going the extra mile ? Thanks, Elhamer. -- View this message in context: http://forum.world.st/Two-tables-that-share-the-same-data-source-tp4959153.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 7, 2017

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

by Esteban A. Maringolo

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(a)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(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. 7, 2017

Re: [Pharo-dev] fixing the tab morph

by Esteban A. Maringolo

I liked the original trapezoid shape more than the squared version, and if there is going to be a variable length (autosized) it should have a maximum width setting, and leave the "variable width" tab for the end. There's some "muscle memory" in any UI, and having tabs (or any UI component) that change size depending on the content can mislead you, plus it can alter the UI "harmony". It's no surprise web browsers "shrink" the width keeping a proportional width, but never go full width, even when there is screen state available. Regards, Esteban A. Maringolo 2017-08-07 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Would be nice to have autosized tabs > > 2017-08-07 19:18 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: >> >> Le 07/08/2017 Ã 17:47, Esteban Lorenzano a Ã©crit : >> > Hi, >> > >> > Soâ¦ summer project (to do when there is too much hot to go outside): fix >> > some minor things that are inside the image that annoys me since some >> > time. >> > >> > First issue: the tab morph we have is horrible (and makes horrible >> > anything with it). >> > Iâve been working on it to fix that âchromish-but-badâ style we had and >> > to fix some (a lot) hardcoded colors there. >> > Now, for example, Calypso looks like this: >> > >> > >> > >> > >> > which is IMHO a lot better :) >> > >> > some remarks: >> > >> > 1) I find TabManagerMorph an ugly name. Do you think we should change >> > it? (I tend to think anything called *Manager, *Controller, etc. as a >> > bad naming chose and probably the mark of a smell). >> > 2) much more important: we should deprecate TabGroupMorph and >> > LazyTabGroupMorph familyâ¦ there should not be more than one widget to do >> > the same in the system. >> > >> > So well, as usual with old things: you fix a little thing and you >> > uncover a lot of new problems :) >> > >> > Esteban >> > >> > >> >> Hi, >> >> I find those tabs too big. Am I the only one with this impression? >> >> But nice job, those are really better :) >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >

Aug. 7, 2017