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

Re: [Pharo-dev] request for improvements in GTInspector or debugger

by Sven Van Caekenberghe

You can already do that: click the icon at the top right of the window 'Browse': > On 09 Aug 2016, at 19:23, stepharo <stepharo(a)free.fr> wrote: > > Here is my scenario. > > I have a field that contains aCZWhatever > > the inspector shows me a list > > > field aCZWhatever > > I can edit the aCZWhatever since I can click on it and get an input fiedl (or what I thought is an input field). > > I can select CZWhatever but I cannot do browse on it. So I have to use Spotter. > > > Stef > >

Aug. 9, 2016

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

by stepharo

> Ah, you can try: > > Metacello new > smalltalkhubUser: 'MartinDias' project: 'Epicea'; > configuration: 'Epicea'; > version: '7.98'; > load. > > you should be working in a Pharo 6 that has an old Epicea version. ah yes I should migrate. I took an old pillar image. I will change now. Stef > > Martin > > On Tue, Aug 9, 2016 at 11:19 AM, Martin Dias <tinchodias(a)gmail.com > <mailto:tinchodias@gmail.com>> wrote: > > Hi, > I'm looking at it. Vincent reported it a couple of weeks ago and I > fixed it (apparently not?!) > > Martin > > On Tue, Aug 9, 2016 at 8:56 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > I just tried to replay a change today in Pharo60 and I got an > error in epicea. > > EpRedoVisitor>>visitEvent: aChange > ^ self error: 'Should not be reached'. > > EpRedoVisitor>>visitCodeChange: aChange > "Default behavior for any change." > > ^ self visitEvent: aChange > > EpRedoVisitor>>visitBehaviorChange: aChange > ^ self visitCodeChange: aChange > > EpRedoVisitor>>visitProtocolChange: aProtocolAddition > ^ self visitBehaviorChange: aProtocolAddition. > > > visitProtocolAddition: aProtocolAddition > ^ self visitProtocolChange: aProtocolAddition > > > Apparently it was a > > EpProtocolAddition > > > And the RedoVisitor does not handle them. > > I do not have the time to check further - I just want to > rescue my code for now. > > > Stef > > > >

Aug. 9, 2016

Re: [Pharo-dev] Epicea redoVisitor does not handle protocol changes

by stepharo

tx martin. Stef Le 9/8/16 Ã 16:19, Martin Dias a Ã©crit : > Hi, > I'm looking at it. Vincent reported it a couple of weeks ago and I > fixed it (apparently not?!) > > Martin > > On Tue, Aug 9, 2016 at 8:56 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > I just tried to replay a change today in Pharo60 and I got an > error in epicea. > > EpRedoVisitor>>visitEvent: aChange > ^ self error: 'Should not be reached'. > > EpRedoVisitor>>visitCodeChange: aChange > "Default behavior for any change." > > ^ self visitEvent: aChange > > EpRedoVisitor>>visitBehaviorChange: aChange > ^ self visitCodeChange: aChange > > EpRedoVisitor>>visitProtocolChange: aProtocolAddition > ^ self visitBehaviorChange: aProtocolAddition. > > > visitProtocolAddition: aProtocolAddition > ^ self visitProtocolChange: aProtocolAddition > > > Apparently it was a > > EpProtocolAddition > > > And the RedoVisitor does not handle them. > > I do not have the time to check further - I just want to rescue my > code for now. > > > Stef > > >

Aug. 9, 2016

Re: [Pharo-dev] DNU with GT Debugger

by stepharo

Good! I should say that my superpowers to find bugs and glitches is hyper frustrating. Le 9/8/16 Ã 18:10, Tudor Girba a Ã©crit : > Hi, > > Thanks. I could reproduce the problem and I extracted a simpler case: > https://pharo.fogbugz.com/f/cases/18899/Raw-presentation-from-the-debugger-… > > Cheers, > Doru > > >> On Aug 9, 2016, at 2:00 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi doru >> >> >> I sent you a drop box where you just have to click to repeat the problem. >> >> Let me know if this is enough. Else I should send you more scripts and files. >> >> Stef >> >> >> Le 9/8/16 Ã 12:07, Tudor Girba a Ã©crit : >>> Hi, >>> >>> Thanks for the report. Do you happen to have an image around? >>> >>> Doru >>> >>> >>>> On Aug 9, 2016, at 11:47 AM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> While trying to debug pillar I got a DNU when clicking on the raw pane (when the items was selected) >>>> >>>> DNU: >>>> >>>> presentation rawSelection is aLinkedList and it does not understand key >>>> >>>> >>>> >>>> >>>> 'From Pharo 6.0 of 13 May 2016 [Latest update: #60173] on 9 August 2016 at 11:45:10.355092 am'! >>>> >>>> !GTRawObjectVariablesBrowser methodsFor: 'private building' stamp: 'AndreiChis 4/26/2016 10:37'! >>>> variablesIn: composite >>>> ^ composite table >>>> showOnly: 50; >>>> shouldValidate: false; >>>> allowsRecursiveSearch: false; >>>> children: [ :assoc | >>>> assoc key = 'self' >>>> ifTrue: [ #() ] >>>> ifFalse: [ self variableValuePairsFor: assoc value ] ]; >>>> icon: [ :assoc | self iconFor: assoc value ]; >>>> display: [ :anObject | >>>> self rebuildCacheFor: anObject. >>>> self variableValuePairsFor: anObject ]; >>>> column: 'Variable' >>>> evaluated: [:assoc | ' ', (GTObjectPrinter new asNonTruncatedTextFrom: assoc key) ]; >>>> column: 'Value' >>>> evaluated: [:assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ] >>>> modified: [:newValue :assoc :presentation | >>>> self updateInstanceVariable: assoc key from: presentation entity basedOn: newValue. >>>> presentation update ]; >>>> morphicSelectionAct: [:list | list selection value browse ] >>>> icon: GLMUIThemeExtraIcons glamorousBrowse >>>> on: $b >>>> entitled: 'Browse'; >>>> morphicSelectionAct: [:list | list selection value inspect ] >>>> icon: GLMUIThemeExtraIcons glamorousInspect >>>> on: $i >>>> entitled: 'Inspect'; >>>> selectionAct: [:list | >>>> ((list selection pointersToExcept: { list selection }) >>>> reject: [ :each | each pointsOnlyWeaklyTo: list selection ]) inspect ] >>>> on: $t >>>> entitled: 'Open pointers to'; >>>> dynamicActionsOnSelection: [ :presentation | >>>> (presentation entity class hasInstVarNamed: presentation rawSelection key) >>>> >>>> ^^^^^^^^ here >>>> >>>> >>>> >>>> ifTrue: [ >>>> { >>>> GLMGenericAction new >>>> action: [:list | self systemNavigation browseAllAccessesTo: list rawSelection key from: list entity class ]; >>>> title: 'List methods using this variable'. >>>> GLMGenericAction new >>>> action: [:list | self systemNavigation browseAllStoresInto: list rawSelection key from: list entity class ]; >>>> title: 'List methods storing into this variable'. >>>> } >>>> ] >>>> ifFalse: [ #() ] ]! ! >>>> >>>> <GTRawObjectVariablesBrowser-variablesIn.st> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > >

Aug. 9, 2016

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

by stepharo

:) Stef

Aug. 9, 2016

request for improvements in GTInspector or debugger

by stepharo

Here is my scenario. I have a field that contains aCZWhatever the inspector shows me a list field aCZWhatever I can edit the aCZWhatever since I can click on it and get an input fiedl (or what I thought is an input field). I can select CZWhatever but I cannot do browse on it. So I have to use Spotter. Stef

Aug. 9, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60176 Home: https://github.com/pharo-project/pharo-core

Aug. 9, 2016

[pharo-project/pharo-core] 354532: 60176

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 354532ec04aa92b596cfd5e5cd0e097b5f2de945 https://github.com/pharo-project/pharo-core/commit/354532ec04aa92b596cfd5e5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-09 (Tue, 09 Aug 2016) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60175.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60176.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60175.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60176.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Core.package/extension/VTermOutputDriver/class/printText_.st Log Message: ----------- 60176 18897 Monkey crashing with MessageNotUnderstood: VTermOutputDriver>>color256: https://pharo.fogbugz.com/f/cases/18897 http://files.pharo.org/image/60/60176.zip

Aug. 9, 2016

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

by Yuriy Tymchuk

Sorry, couldnât help putting this here. Each time I hear that there is a CSS usage outside of web I think about this mug: > On 09 Aug 2016, at 15:03, stepharo <stepharo(a)free.fr> wrote: > > Hi doru > > I think that this is particularly true (having a themer per widget) when the themer is more a skinner (it changes behavior of the widgets), else we could have addressed the problem with a solution close to setting. Two years ago I played with theming and widgets hierarchy and I came to the same conclusion (that your blog entries). > Do you know how they do it in JavaFX? > I agree also that we should extract the Palette. > Now I'm really curious to see the CSS of Glenn in Bloc2. > Stef > > Le 4/8/16 Ã 12:52, Tudor Girba a Ã©crit : >> Hi Esteban, >> >> Sorry for the delayed response. >> >> There are two parts in your mail: >> 1. the decomposition of theme to have one themer per widget >> 2. a centralized catalog of values >> >> I certainly agree with 2. In fact, when I refactored the theme colors a long time ago, I introduced a rudimentary reuse mechanism on the class side of the Theme class. So, now, we should extract those separately. >> >> About 1., I have a different opinion. The hierarchy you mention already exists in the Theme class as well, only it is hidden, and it is very hard to see what each methods impacts. >> >> Here is how I reached this conclusion. Take a look at this picture I produced before we started with Brick (the one from Morphic). The gray circles are methods in UITheme, and the red circles are typical Morphs (like TextMorph, ListMorph). The gray lines show self calls inside the UITheme, and the red lines shod calls from the morph to the UITheme methods. What you see here is a very strong clustering of the methods around the widgets, and this indicates that having a theme object per widget is appropriate. >> >> >> <Mail Attachment.png> >> >> >> A further constrain is that we want to be able to change the appearance of a widget on an instance basis (that is, overriding the default theme setting), and having a per-widget themer object, we can achieve that as well. >> >> A similar design appears in Bloc as well, and I think it is actually more scalable then the current UITheme, provided that you indeed have a way to either centralize the definitions of colors (and other properties), or inject those properties from the outside. >> >> All in all, letâs go ahead and extract the palette :). >> >> Cheers, >> Doru >> >> >>> On Aug 1, 2016, at 11:13 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> Hi, >>> >>> For one of my side-projects, I made a new theme for Pharo (still no name, I was planing to call it âDark Metalâ or something like that. Is a variation on the Dark Theme but âourâ dark theme is more brown and this one is more blue (see attached)â¦ I wanted to publish it to push it but then I arrived to an unexpected problem: For Spotter and GTTools in general, theming is not done following current theming approach. Instead, they made a full hierarchy of objects. >>> >>> IMO this is plain bad. I understand the attempt to decouple, but now that means if I want to create a new theme, I need to create my theme object with colors I want and then also I need to create an undetermined number of classes (at least one for each tool, but there is also a hierarchy of things there)â¦ anyway, this DOES NOT scale. Because each tool will have to have a âtheme classâ for each existing themeâ¦ >>> How themes (skins, bah) work in all word is to have a color palette and then tools takes them (they can âplayâ a bit with this palette, but need to always respect the palette). >>> >>> Then, I will commit a SLICE modifying the âthemerâ classes to take colors from the current theme (instead of have them hardcoded). >>> But of course, how theme work now is not good because they mix âthemeâ (how they display) and âskinâ (color palette). I will also extract the palette to where should have always been (some kind of a style sheet object)â¦ who also should have been editable in settings so people can tweak their configuration. >>> >>> I didnât wanted to touch this before, because this will supposedly change with brick, but honestly this will not be ready for Pharo 6 and this is annoying (also, I want to publish my theme and I do not want to add overrides all around :P) >>> >>> cheers, >>> Esteban >>> >>> >>> <Screen Shot 2016-08-01 at 11.00.15.png> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://www.feenk.com/> >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >

Aug. 9, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Tudor Girba

Hi, > > Hey Doru, > about what "two issues" are we talking? My only issue for now is, > what shortcut shold we use for moving the cursor forward/backward word. Even if we introduce a new layer, at some point in time you need to > define: If the user types the CTRL+LEFT -key, even if we call it differently, some action happens, dive-out or move-backward-word ? > At the moment (on windows) you can use both to move word-by-word: > ctrl+left/right and alt+left/right, because this is how it is defined in rubrics action/cmdaction map. > > If we want to clean this up and use the kmdispatcher registration, I think we don't want to use both ctr and alt again, right? > So, someone has to take the decision. > I myself would prefer > ctrl+left/right because this is what (all) many other programs are using on windows. Fine. But recently Spotter changed its > dive in / dive out shortcut to use ctrl+left/right. > Therefor I am asking you, why, and whether we want to keep it or not. If we want to keep it, we may > - just overwrite the binding for the textfield -> not good, I think, you wouldn't be able to do word-by-word movements in the textfield anymore > - overwrite the binding and use another binding for word-by-word moving, but just in spotters text field > Or we revert that change and use the old shortcuts again. > (And what to use for mac and linux?) > > but I am getting really tired of asking, and will do something else instead. The short answer: we will override the keybinding in the text morph for now. This will mean that we cannot move word by word in the text field using #control, but it will be consistent with all other platforms. Could you open an issue for this, please? On top of that, we will externalize all GTSpotter shortcuts through settings: https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externa… Long answer: As explained before, the shortcut changed in the process of making all shortcuts uniform when Guille introduced #meta instead of #command (like it was before). The thing is that currently: - #command means #alt on Win and #command on Mac, and - #meta means #control on Win and #command on Mac. But, #command should be a low level key, not a portable one. It should not have a meaning on Windows, because the key does not exist on that platform. Moving to make keybindings uniform is a good thing, but only having #meta is not enough for situation like the one you mention. That is why I am proposing to introduce a #secondaryMeta as a platform-independent modifier that would mean #alt on Win and #control on Mac. We could use that one more consistently. Is this a better explanation? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Aug. 9, 2016