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

Re: [Pharo-dev] some questions about bloc

by stepharo

> Are you interested in some feedback for brick, or is it in a too early > stage? please. > 2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com > <mailto:alex.syrel@gmail.com>>: > > Hi Nicolai, > > Thanks for looking into this :) Hierarchy will be optimised. > Basically EnclosedView will gone - ProtoView will be a > composition, this will remove code duplication and simplify > addition of new functionality. After that rounded rectangle and > rectangle will be merged. So in the end hierarchy will be > BlProtoView -> BlView -> BlRectangle -> BrStringView -> > BrButtonView which is simple enough. > > As Stephan said theme just provides default values and also skin > for morph. Skin provides view and different styles for states like > hovered, pressed, active, focused, disabled and others. > > Summarizing, with event listener any arbitrary morph can get > dynamic behaviour on events, with skins any arbitrary morph can be > deeply styled. > > Maybe it makes sense to move theme from BlProtoView to BlMorph. > > Cheers, > Alex > > On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > > > 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel > <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>>: > > Hi > > Thanks for your response. > > Animation was copied from other project and has nothing to > do with Bloc. However, it is still there for a moment. > BTW, example on the class side is still morphic. > > > Yes, but it only works in a bloc world > > Yes, it does not make any sense to theme CircleView and > ImageView, but it makes sense to theme their subclasses, > like BrButtonView. Theming mechanism is not integrated in > Bloc for now. > > > But why dont we put this into a BlThemeableView ? > All subclasses of BlProtoView that want to support color or > fillstyles, now have a theme property too. > Why do they need a color property if the color is theme-dependent. > > Btw. what is that strange hierarchy for BrButtonView: > BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> > BlRoundedRectangleView -> BrRectangleView -> BrStringView -> > BrButtonView > A BlRectangleView, a RoundedRectangleView and a BrRectangleView? > > I think I don't understand bloc > > > Cheers, > Alex > > On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > BlAlarmQueue > - split into two classes? > Queue : managing the add/remove/sort > Scheduler : process the Alarms > - alarm/alarmqueue both accessing and check the time > "Time now" > I would put both checks to, either the alarm OR the > queue/scheduler. > And don't use "Time now" explicit, if we put this > behind a method call, we > can easily create alarm queue mocs for unit tests. > - readding periodic alarms: shouldn't this be done by > the alarm itself - the queue should not care, whether > a alarm is periodic. > > Some alarm examples put the queue into the morphs > property dictionary. I could find out why > this is necessary. > > > Layout: > Box/Column/Row Layout and corresponding cells define a > double linked list, we already > have a DoubleLinkedList, can we use the > DoubleLinkedList instead of reimplmenting this > on the layout/cells? > > Tablelayout: is this "work in progress" or abandoned? > Currently it shares much code with > the BoxLayout, but it does not look like it is working. > > Theming: > #theme is a property of BlProtoView - isn't this to > low level for defining theming support? > How would you theme a CircleView or an ImageView? > > > Animation: > what are all these "Logics"? > animationLogic > toLogic > stepLogic and steppedLogic(!?) > ifLogic .... > > Is this a software pattern ? I have never seen this > before. > (For example we use "sortBlock" but not "sortLogic"). > How about ValueHolder or good old "Block". > > And "ifLogic" sounds like a condition, why don't we > name it. ... condition? > And putting all this "logic" into one animation class > scares me. > > > About the class comment syntax: > - is this pillar syntax? I think this is difficult to > read. Do you use that syntax, because we > want to use a pillar as comment text and build a > renderer for this or is it to share comments between > class comments and the bloc doc book, easily? > > I can help with documenting the classes but I find it > difficult to see which parts of bloc > are just tests/proof of concept or are supposed to be > in the final version. Maybe I miss the big picture? > > > nicolai > > > > > > >

Aug. 16, 2015

Re: [Pharo-dev] Mongo - find object by id

by Sabine Manaa

Ok, I see, the fix of Henrik is already in the ConfigurationOfMongoTalk but in the development version, not yet stable. I loaded stable. Great. Sorry for not checking this before writing the mail. 2015-08-16 10:30 GMT+02:00 Sabine Manaa <manaa.sabine(a)gmail.com>: > Hi, > > the problem is solved. Thanks John. (see here: > https://github.com/estebanlm/voyage/issues/6) > > 2 Points: > 1) > RKAPerson selectMany: {('_id' -> ('75b900000000000000000000')). } > asDictionary. > is wrong. I have to call e.g. > RKAPerson selectMany: {('_id' -> (OID value: 16r55CDD2B6E9A87A520F000001)). > } asDictionary. > > 2) For correct generating of OID, I use this commit > > http://smalltalkhub.com/#!/~MongoTalkTeam/mongotalk/versions/Mongo-BSON-Hen… > > Esteban, what do you think about putting this version of Henrik commit into > the ConfigurationOfMongoTalk? > > Regards > Sabine > > > > -- > View this message in context: > http://forum.world.st/Mongo-find-object-by-id-tp4842231p4843195.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 16, 2015

Re: [Pharo-dev] Mongo - find object by id

by Sabine Manaa

Hi, the problem is solved. Thanks John. (see here: https://github.com/estebanlm/voyage/issues/6) 2 Points: 1) RKAPerson selectMany: {('_id' -> ('75b900000000000000000000')). } asDictionary. is wrong. I have to call e.g. RKAPerson selectMany: {('_id' -> (OID value: 16r55CDD2B6E9A87A520F000001)). } asDictionary. 2) For correct generating of OID, I use this commit http://smalltalkhub.com/#!/~MongoTalkTeam/mongotalk/versions/Mongo-BSON-Hen… Esteban, what do you think about putting this version of Henrik commit into the ConfigurationOfMongoTalk? Regards Sabine -- View this message in context: http://forum.world.st/Mongo-find-object-by-id-tp4842231p4843195.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 16, 2015

Re: [Pharo-dev] some questions about bloc

by Nicolai Hess

Are you interested in some feedback for brick, or is it in a too early stage? 2015-08-10 12:36 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi Nicolai, > > Thanks for looking into this :) Hierarchy will be optimised. Basically > EnclosedView will gone - ProtoView will be a composition, this will remove > code duplication and simplify addition of new functionality. After that > rounded rectangle and rectangle will be merged. So in the end hierarchy > will be BlProtoView -> BlView -> BlRectangle -> BrStringView -> > BrButtonView which is simple enough. > > As Stephan said theme just provides default values and also skin for > morph. Skin provides view and different styles for states like hovered, > pressed, active, focused, disabled and others. > > Summarizing, with event listener any arbitrary morph can get dynamic > behaviour on events, with skins any arbitrary morph can be deeply styled. > > Maybe it makes sense to move theme from BlProtoView to BlMorph. > > Cheers, > Alex > On Aug 9, 2015 9:57 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: > >> >> >> 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >> >>> Hi >>> >> Thanks for your response. >> >> >>> Animation was copied from other project and has nothing to do with Bloc. >>> However, it is still there for a moment. BTW, example on the class side is >>> still morphic. >>> >> >> Yes, but it only works in a bloc world >> >> >>> Yes, it does not make any sense to theme CircleView and ImageView, but >>> it makes sense to theme their subclasses, like BrButtonView. Theming >>> mechanism is not integrated in Bloc for now. >>> >> >> But why dont we put this into a BlThemeableView ? >> All subclasses of BlProtoView that want to support color or fillstyles, >> now have a theme property too. >> Why do they need a color property if the color is theme-dependent. >> >> Btw. what is that strange hierarchy for BrButtonView: >> BlProtoView -> BlView -> BlEnclosedView -> BlRectangleView -> >> BlRoundedRectangleView -> BrRectangleView -> BrStringView -> BrButtonView >> A BlRectangleView, a RoundedRectangleView and a BrRectangleView? >> >> I think I don't understand bloc >> >> >> Cheers, >>> Alex >>> On Aug 9, 2015 7:29 PM, "Nicolai Hess" <nicolaihess(a)web.de> wrote: >>> >>>> BlAlarmQueue >>>> - split into two classes? >>>> Queue : managing the add/remove/sort >>>> Scheduler : process the Alarms >>>> - alarm/alarmqueue both accessing and check the time "Time now" >>>> I would put both checks to, either the alarm OR the queue/scheduler. >>>> And don't use "Time now" explicit, if we put this behind a method >>>> call, we >>>> can easily create alarm queue mocs for unit tests. >>>> - readding periodic alarms: shouldn't this be done by the alarm itself >>>> - the queue should not care, whether a alarm is periodic. >>>> >>>> Some alarm examples put the queue into the morphs property dictionary. >>>> I could find out why >>>> this is necessary. >>>> >>>> >>>> Layout: >>>> Box/Column/Row Layout and corresponding cells define a double linked >>>> list, we already >>>> have a DoubleLinkedList, can we use the DoubleLinkedList instead of >>>> reimplmenting this >>>> on the layout/cells? >>>> >>>> Tablelayout: is this "work in progress" or abandoned? Currently it >>>> shares much code with >>>> the BoxLayout, but it does not look like it is working. >>>> >>>> Theming: >>>> #theme is a property of BlProtoView - isn't this to low level for >>>> defining theming support? >>>> How would you theme a CircleView or an ImageView? >>>> >>>> >>>> Animation: >>>> what are all these "Logics"? >>>> animationLogic >>>> toLogic >>>> stepLogic and steppedLogic(!?) >>>> ifLogic .... >>>> >>>> Is this a software pattern ? I have never seen this before. >>>> (For example we use "sortBlock" but not "sortLogic"). >>>> How about ValueHolder or good old "Block". >>>> >>>> And "ifLogic" sounds like a condition, why don't we name it. ... >>>> condition? >>>> And putting all this "logic" into one animation class scares me. >>>> >>>> >>>> About the class comment syntax: >>>> - is this pillar syntax? I think this is difficult to read. Do you use >>>> that syntax, because we >>>> want to use a pillar as comment text and build a renderer for this or >>>> is it to share comments between class comments and the bloc doc book, >>>> easily? >>>> >>>> I can help with documenting the classes but I find it difficult to see >>>> which parts of bloc >>>> are just tests/proof of concept or are supposed to be in the final >>>> version. Maybe I miss the big picture? >>>> >>>> >>>> nicolai >>>> >>>> >>>> >>>> >>>> >>>> >>

Aug. 15, 2015

16216 Default values in NECPreferences are not initilized right

by Nicolai Hess

This is not good. Somehow this disables NEC. And resets many other NEC settings, for example if you just enables code complation again, you still don't have the smart characters (-> inserting matchin "or ) or } ...)

Aug. 15, 2015

Re: [Pharo-dev] need some testers: 15619 cleanup TextEditors shortcut definition

by Nicolai Hess

Am 15.08.2015 10:19 nachm. schrieb "stepharo" <stepharo(a)free.fr>: > > Since we did not port yet spec to use Rubric all the text pane of tools made with spec should use the textEditor. Yes,but they only use SmalltalkEditor and not TextEditor. (Regardless whether you use beForCode or beForText) > > Le 15/8/15 19:58, Nicolai Hess a Ã©crit : > >> Now I moved all (known?) shortcut definitions from >> TextEditor/SmalltalkEditor action-/cmdmap to Keymappings >> <keymap>pragma definitions >> >> slice in inbox for issue 15619 >> Postscript: KMRepository reset. >> >> need some testers. >> please report back, what editor (TextEditor/SmalltalkEditor) and your >> platform (windows/linux/mac) and the shortcut/keycombination that >> did not work (or does work but not as expected). >> >> This is only for PluggableTextMorph based TextMorphs, >> (Not Rubric -> No change for Playground or Nautilus). >> >> >> For testing: >> PluggableTextMorph with TextEditor as a editor: >> >> (Smalltalk ui theme builder newBasicTextEditorFor: Morph getText: #comment setText: nil) openInWindow. >> >> >> PluggableTextMorph with SmalltalkEditor as a editor: >> (Smalltalk ui theme builder newTextEditorFor: (Morph>>#drawOn:) getText: #sourceCode setText: nil) openInWindow. >> >> Many shortcuts should work like before. some changes: >> some short cuts actions had multiple shortcuts on windows/linux: >> alt+key from TextEditors keymap >> ctrl+key from the <keymap>-pragma >> -> only one should be working now. >> >> Ctrl+space does not work in current pharo windows vm >> escape may not work for all actions >> >> You can browse all defined shortcuts in the Keymap Browser >> (Worldmenu -> System -> Keymap Browser) >> >> thanks > >

Aug. 15, 2015

Re: [Pharo-dev] we are running dependencies breaking sprints....

by Dimitris Chloupis

ah ok thats much more clear thanks Stef will take a look at fogbugz :) On Sat, Aug 15, 2015 at 11:19 PM stepharo <stepharo(a)free.fr> wrote: > This is easy we are looking at dependencies using the dependency analyzer > (available in the catalog) > and looking at how to reduce dependencies. Often it is creating a separate > package, providing an extension hook... > Guille and Christophe started to add fogbugz entries for a first set of > problems. > > Stef > > Le 15/8/15 16:32, Dimitris Chloupis a Ã©crit : > > A "how to help with Pharo Bootstrap" article could help us help you ;) > > On Sat, Aug 15, 2015 at 4:49 PM stepharo <stepharo(a)free.fr> wrote: > >> I forgot to mention that people can help since we added a tahe >> pharo-bootstrap. >> >> Stef >> >> Le 15/8/15 10:53, Tudor Girba a Ã©crit : >> >> This is exciting. Thanks a lot for this effort! >> >> Doru >> >> On Sat, Aug 15, 2015 at 10:50 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> Hi guys >>> >>> just to let you know that we run a dependencies breaking sprint >>> yesterday and it was great. >>> We will redo one or two. >>> Our goal is to minimise the dependencies of adding Monticello to the >>> pharo bootstrap. >>> What I can tell you is that having a bootstrap is bringing an >>> ***AMAZING*** level of cleaner design. >>> I suspected it. But when we see the real cases this is obvious and >>> really important. >>> I will really open a complete new world for Pharo in terms of modularity >>> (of course it will take time >>> but this is really really cool). >>> >>> Stef >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >

Aug. 15, 2015

Re: [Pharo-dev] need some testers: 15619 cleanup TextEditors shortcut definition

by stepharo

Since we did not port yet spec to use Rubric all the text pane of tools made with spec should use the textEditor. Le 15/8/15 19:58, Nicolai Hess a Ã©crit : > Now I moved all (known?) shortcut definitions from > TextEditor/SmalltalkEditor action-/cmdmap to Keymappings > <keymap>pragma definitions > > slice in inbox for issue 15619 > Postscript: KMRepository reset. > > need some testers. > please report back, what editor (TextEditor/SmalltalkEditor) and your > platform (windows/linux/mac) and the shortcut/keycombination that > did not work (or does work but not as expected). > > This is only for PluggableTextMorph based TextMorphs, > (Not Rubric -> No change for Playground or Nautilus). > > > For testing: > PluggableTextMorph with TextEditor as a editor: > > (Smalltalk ui theme builder newBasicTextEditorFor: Morph getText: > #comment setText: nil) openInWindow. > > > PluggableTextMorph with SmalltalkEditor as a editor: > (Smalltalk ui theme builder newTextEditorFor: (Morph>>#drawOn:) > getText: #sourceCode setText: nil) openInWindow. > > Many shortcuts should work like before. some changes: > some short cuts actions had multiple shortcuts on windows/linux: > alt+key from TextEditors keymap > ctrl+key from the <keymap>-pragma > -> only one should be working now. > > Ctrl+space does not work in current pharo windows vm > escape may not work for all actions > > You can browse all defined shortcuts in the Keymap Browser > (Worldmenu -> System -> Keymap Browser) > > thanks

Aug. 15, 2015

Re: [Pharo-dev] we are running dependencies breaking sprints....

by stepharo

This is easy we are looking at dependencies using the dependency analyzer (available in the catalog) and looking at how to reduce dependencies. Often it is creating a separate package, providing an extension hook... Guille and Christophe started to add fogbugz entries for a first set of problems. Stef Le 15/8/15 16:32, Dimitris Chloupis a Ã©crit : > A "how to help with Pharo Bootstrap" article could help us help you ;) > > On Sat, Aug 15, 2015 at 4:49 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > I forgot to mention that people can help since we added a tahe > pharo-bootstrap. > > Stef > > Le 15/8/15 10:53, Tudor Girba a Ã©crit : >> This is exciting. Thanks a lot for this effort! >> >> Doru >> >> On Sat, Aug 15, 2015 at 10:50 AM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi guys >> >> just to let you know that we run a dependencies breaking >> sprint yesterday and it was great. >> We will redo one or two. >> Our goal is to minimise the dependencies of adding Monticello >> to the pharo bootstrap. >> What I can tell you is that having a bootstrap is bringing an >> ***AMAZING*** level of cleaner design. >> I suspected it. But when we see the real cases this is >> obvious and really important. >> I will really open a complete new world for Pharo in terms of >> modularity (of course it will take time >> but this is really really cool). >> >> Stef >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >

Aug. 15, 2015

Re: [Pharo-dev] FastTable in Pharo4?

by Esteban Lorenzano

yes just take the configuration from estebanlm/FastTable and load it :) Esteban > On 15 Aug 2015, at 21:05, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi, > > is it possible to load FastTable in Pharo 4? > > Uko >

Aug. 15, 2015