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

I love the auto refactorings / deprecation.

by stepharo

So cool to see the system updating itself. Stef

Aug. 10, 2016

Marquette Camp Smalltalk September 15-18th

by Andres Valloud

Hi! Your Camp Smalltalk crew has been at it for a while, and we are very happy to announce a Camp Smalltalk at Marquette, Michigan, on September 15-18th. The event's website is at http://mqt.st. We are generously hosted by Northern Michigan University (http://www.nmu.edu) where John Sarkela teaches Smalltalk courses. Of course, NMU is also home to the Modtalk project, https://www.modtalk.org. You can help us provide a better experience for everyone by registering here: https://www.picatic.com/event14606861846650. Don't miss the date!

Aug. 10, 2016

Re: [Pharo-dev] Out of ideas...

by Bernardo Ezequiel Contreras

What about this | line matcher exps ranges negateRanges result | line := 'A polÃtica no Brasil estÃ¡ complicada #FAIL porque a corrupÃ§Ã£o impera #CRIME. De qualquer forma os #PETRALHAS, que tudo justificam, levam o paÃs ao #CAOS'. matcher := '(#\w+)' asRegex. exps := matcher matchesIn: line. "i believe you can extend the matcher to give the subexpressions and ranges at the same time" ranges := matcher matchingRangesIn: line. negateRanges := OrderedCollection new. ranges inject: 1 into: [ :start :interval | negateRanges add: (Interval from: start to: (interval first - 1)). interval last + 1 ]. result := negateRanges inject: String new into: [ :s :interval | s, (line copyFrom: interval first to: interval last). ]. Array with: exps with: ranges with: negateRanges with: result On Tue, Aug 9, 2016 at 12:53 PM, Casimiro - GMAIL < casimiro.barreto(a)gmail.com> wrote: > Em 08-08-2016 19:25, Bernardo Ezequiel Contreras escreveu: > > Hi, > > have you try with (World>>Help>>Help Browser>>Regular Expressions > Framework>>Usage) > > SUBEXPRESSION MATCHES > > After a successful match attempt, you can query the specifics of which > part of the original string has matched which part of the whole > expression. > > (...) > > Thanks, but thing is: my need is little more complex than finding > sequences. I'm looking for expressions in natural language text. The > expressions must be extracted without ambiguities so I have cases for > occurrences in the beginning of line (aka '^(#\w+)([\s.,;\:!?]*)') in the > middle of the line (aka '([\s.,;\:!?]+)(#\w+)([\s.,;\:!?]+)') or at the > end (which may be simplified to the second case...). So, if I find several > hashtags in a text like: > > 'A polÃtica no Brasil estÃ¡ complicada #FAIL porque a corrupÃ§Ã£o impera > #CRIME. De qualquer forma os #PETRALHAS, que tudo justificam, levam o paÃs > ao #CAOS' > > I want two things: > > 1st and obvious: #( '#FAIL' '#CRIME' '#PETRALHAS' '#CAOS') > 2nd: the line minus hashtags: 'A polÃtica no Brasil estÃ¡ complicada porque > a corrupÃ§Ã£o impera. De qualquer forma os, que tudo justificam, levam o paÃs > ao' > > When I use regexps to process the line, for instance: > > bfr := line copyWithRegex: '#\w+' matchesReplacedUsing [ :e | '' ]. > > I can have trouble because it will extract things like #ANOTAÃÃO# which is > not a hashtag but will match. > > And I'm trying to avoid doing the Lex/Yacc thing here :D > > Best regards, > > CdAB > > -- > The information contained in this message is confidential and intended to > the recipients specified in the headers. If you received this message by > error, notify the sender immediately. The unauthorized use, disclosure, > copy or alteration of this message are strictly forbidden and subjected to > civil and criminal sanctions. > > == > > This email may be signed using PGP key *ID: 0x4134A417* > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Aug. 9, 2016

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

by Nicolai Hess

2016-08-09 23:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > 2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > 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? > > > > > > > > > consistens on all platforms may not be the expectation for all users. > Some users only working on a windows platform may want to have consistent > behavior for all tools (applications). > > > > Well, you wanted a decision :). > > > > > > > On top of that, we will externalize all GTSpotter shortcuts through > settings: > > > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts- > should-be-externalized-as-settings > > > > > > I really don't know why that. > > > > Because we do not have a generic KMDispatcher mechanism :). > > > > yes and it does not make much sense as not all shortcuts are handled by > the kmdispatcher, thats why cleaning this > > up and I think it would be better to do this instead of implementing yet > another only-for-this-tool solution. > > Ok. What should I do? > > > > > We don't need a way to make Spotter shortcuts configurable, but *all* > shortcuts. > > > That is why I try to move all shortcut definitions to the > kmdispatcher, but it yet again took 2 month just to discuss what shortcut > to use for cursor movement. > > > > I am not sure I understand. Was this me that stalled the discussion? If > yes, it was not intentional. Is there anything I can do about this subject? > > > > The whole discussion, the me: "hey, what shortcut to use?" you:"hey we > have a great idea, just let us add some new layers" :( > > I think I miss something because I do not see how the layers have anything > to do with the cursor movement. Or do you mean for diving in Spotter? I > still think that the layers idea is a relevant one and does not conflict > with anything we talked about here. > Ok once again. ctrl+arrow and meta+arrow both do cursor movements in rubrik, but it is registered on the action/cmd-map (RubTextEditor>>defaultCommandKeymapping) ctrl+arrow do dive-in/dive-out in spotter, this is registered on spotters window, and this takes precedence over rubrics crtrl+Arrow handling because : 1. kmdispatcher looks in rubrics editor kmregistry -> no action 2. kmdispatcher looks in rubrics morph kmregistry -> no action .... up the morphs owner chain until it reaches spotter x. kmdispatcher looks in spotters window morph kmregistry -> Action! Dive-in / Dive-out Now! If I move ctrl+Arrow shortcut registration for cursor movement from rubrics action/-cmd-map to its kmdispatcher registration, the following happens 1. kmdispatcher looks in rubrics editor kmregistry -> Action ! move the cursor -> no spotter dive-in/dive-out anymore :-( two solutions: use a different shortcut for cursor movement (that is what I aksed in this thread, and why I opened issue 18432 <https://pharo.fogbugz.com/f/cases/18432/Add-a-RubTextFieldEditor>) use a different shortcut for spotter (this is why I started this thread and asked why this was changed at all) overwrite spotters shortcut registration (just like now, but not on spotters window, but on the text field (I opened now a fogbugz issue 18900)) anyway, you said, you want to wait with changing spotters shortcut registration until we have the new layers, therefore I can only wait until that happens. > > In any case, I did not mean to confuse anyone. Please take the lead > concerning the KMDispatcher and I can review if you want. > > Doru > > > > > Cheers, > > Doru > > > > > > > > > > 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." > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "One cannot do more than one can do." > > -- > www.tudorgirba.com > www.feenk.com > > "When people care, great things can happen." > > > > > >

Aug. 9, 2016

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

by Tudor Girba

Hi, > On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > 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? > > > > > > consistens on all platforms may not be the expectation for all users. Some users only working on a windows platform may want to have consistent behavior for all tools (applications). > > Well, you wanted a decision :). > > > > On top of that, we will externalize all GTSpotter shortcuts through settings: > > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externa… > > > > I really don't know why that. > > Because we do not have a generic KMDispatcher mechanism :). > > yes and it does not make much sense as not all shortcuts are handled by the kmdispatcher, thats why cleaning this > up and I think it would be better to do this instead of implementing yet another only-for-this-tool solution. Ok. What should I do? > > We don't need a way to make Spotter shortcuts configurable, but *all* shortcuts. > > That is why I try to move all shortcut definitions to the kmdispatcher, but it yet again took 2 month just to discuss what shortcut to use for cursor movement. > > I am not sure I understand. Was this me that stalled the discussion? If yes, it was not intentional. Is there anything I can do about this subject? > > The whole discussion, the me: "hey, what shortcut to use?" you:"hey we have a great idea, just let us add some new layers" :( I think I miss something because I do not see how the layers have anything to do with the cursor movement. Or do you mean for diving in Spotter? I still think that the layers idea is a relevant one and does not conflict with anything we talked about here. In any case, I did not mean to confuse anyone. Please take the lead concerning the KMDispatcher and I can review if you want. Doru > Cheers, > Doru > > > > > > 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." > > -- > www.tudorgirba.com > www.feenk.com > > "One cannot do more than one can do." -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

Aug. 9, 2016

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

by Nicolai Hess

2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > 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? > > > > > > consistens on all platforms may not be the expectation for all users. > Some users only working on a windows platform may want to have consistent > behavior for all tools (applications). > > Well, you wanted a decision :). > > > > On top of that, we will externalize all GTSpotter shortcuts through > settings: > > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts- > should-be-externalized-as-settings > > > > I really don't know why that. > > Because we do not have a generic KMDispatcher mechanism :). > yes and it does not make much sense as not all shortcuts are handled by the kmdispatcher, thats why cleaning this up and I think it would be better to do this instead of implementing yet another only-for-this-tool solution. > > > > We don't need a way to make Spotter shortcuts configurable, but *all* > shortcuts. > > That is why I try to move all shortcut definitions to the kmdispatcher, > but it yet again took 2 month just to discuss what shortcut to use for > cursor movement. > > I am not sure I understand. Was this me that stalled the discussion? If > yes, it was not intentional. Is there anything I can do about this subject? > The whole discussion, the me: "hey, what shortcut to use?" you:"hey we have a great idea, just let us add some new layers" :( > > Cheers, > Doru > > > > > > 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." > > -- > www.tudorgirba.com > www.feenk.com > > "One cannot do more than one can do." > > > > > >

Aug. 9, 2016

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

by Tudor Girba

Hi, > On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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? > > > consistens on all platforms may not be the expectation for all users. Some users only working on a windows platform may want to have consistent behavior for all tools (applications). Well, you wanted a decision :). > On top of that, we will externalize all GTSpotter shortcuts through settings: > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-externa… > > I really don't know why that. Because we do not have a generic KMDispatcher mechanism :). > We don't need a way to make Spotter shortcuts configurable, but *all* shortcuts. > That is why I try to move all shortcut definitions to the kmdispatcher, but it yet again took 2 month just to discuss what shortcut to use for cursor movement. I am not sure I understand. Was this me that stalled the discussion? If yes, it was not intentional. Is there anything I can do about this subject? Cheers, Doru > > 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." -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

Aug. 9, 2016

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

by Nicolai Hess

2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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? > > consistens on all platforms may not be the expectation for all users. Some users only working on a windows platform may want to have consistent behavior for all tools (applications). > On top of that, we will externalize all GTSpotter shortcuts through > settings: > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts- > should-be-externalized-as-settings I really don't know why that. We don't need a way to make Spotter shortcuts configurable, but *all* shortcuts. That is why I try to move all shortcut definitions to the kmdispatcher, but it yet again took 2 month just to discuss what shortcut to use for cursor movement. > > > 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

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

by Tudor Girba

Hi, We would definitely benefit from a Palette. One interesting concepts in Bloc2 is that the concrete values are injected in the widget, instead of having the widget ask for it. This is quite powerful because it enables a CSS mechanism (or another one), but we also have to see how it works with the requirement of changing these values dynamically. This will certainly be a next step after the core is stable. Cheers, Doru > On Aug 9, 2016, at 3:03 PM, 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> 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 >> www.feenk.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

Aug. 9, 2016

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

by Tudor Girba

Hi, In which presentation are you? As Sven said, you can browse by clicking on the top right icon of the next pane. You can also browse right in place with the Meta presentation from the next pane. Also, if you are in the Raw view, you get the browse menu for an instance variable. However, this menu is hardcoded and for other presentations, this menu is indeed not available. I think this is a missing feature. In fact, we already have that in Moose and it works quite well: an omni-present object menu. The idea is that once we declare object actions (those available on the top right of an object pane), we could also offer them as a menu, and add them throughout the interface. Would this address your issue? Cheers, Doru > On Aug 9, 2016, at 7:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > You can already do that: click the icon at the top right of the window 'Browse': > > <Screen Shot 2016-08-09 at 19.43.10.png> >> 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 >> >> > -- 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