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

Re: [Pharo-dev] [ANN]: Tiny Dev Tools for SimplePersistence and STON

by Sean P. DeNigris

stepharo wrote > can you show an example? Sure... https://youtu.be/VyuuIthp93k ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Tiny-Dev-Tools-for-SimplePersistence-and-STON-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 2, 2015

Re: [Pharo-dev] Are these changes good enough

by stepharo

No stef style. I burned days because of the problem of squeak license: never again. Sergio you can send a pdf. Stef Le 2/5/15 09:55, Esteban Lorenzano a Ã©crit : > INRIA style. > sounds like super bureaucracy, but let me tell you, without going into > details, that at least once it has proven useful :) > > Esteban > >> On 02 May 2015, at 01:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com >> <mailto:i.uhnak@gmail.com>> wrote: >> >> On Fri, May 1, 2015 at 7:44 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Could you send the license agreement and send it to us? >> >> Ha! I completely forgot about doing this. >> I'm just surprised that legally having somewhere written something >> like "by contributing to blablabla you agree with license blablabla" >> is not enough. >> >> Peter >

May 2, 2015

Re: [Pharo-dev] [ANN]: Tiny Dev Tools for SimplePersistence and STON

by stepharo

can you show an example? Stef Le 2/5/15 04:52, Sean P. DeNigris a Ã©crit : > I often find myself writing the same boilerplate over and over for my basic > persistence needs. My usual pattern is to serialize/materialize a class-side > instance variable with accessors of the same name. > > Some time ago, I added the following to SimplePersistence (IIRC it gets > loaded by default): > aClass persist: #fieldName > which adds the necessary code automatically. > > Since I've been playing with STON a bit, I created the same in STON-Tools > and uploaded to http://smalltalkhub.com/#!/~SeanDeNigris/SeansOutbox. There > is even a test ;) > > Enjoy... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-Tiny-Dev-Tools-for-SimplePersistence-and-STON-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 2, 2015

Re: [Pharo-dev] TextMorph right-click?

by Ben Coman

On Sat, May 2, 2015 at 5:31 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > TextMorph new contents: 'Text'; openInWorld I don't know anything about this area, but thought it would be interesting to dig... There is only one implementor of #editView which is TextMorphEditView, a subclass of TextMorph. But... TextMorphEditView new contents: 'Text'; openInWorld right-click gives... "MessageNotUnderstood: receiver of "model" is nil" in TextMorphEditView>>handleInteraction: in this code... self editor model: editView model. "For evaluateSelection, etc" where /editView/ ivar is nil. Only TextMorphEditView>>setEditView: stores into this, and this has only one sender: PluggableTextMorph>>configureTextMorph: Then I notice method "PluggableTextMorph class >> on: text: accept:", so creating the following with usual accessors with Transcript tracing in them... Object subclass: #MyData instanceVariableNames: 'text' classVariableNames: '' category: 'MyPlay' The following lets me edit and save... (PluggableTextMorph on: (MyData new text: 'hello') text: #text accept: #text:) openInWorld Though saving doesn't clear the yellow triangle and I don't yet know how to restrict it to one line without a scroll bar (if you needed that?) cheers -ben

May 2, 2015

TextMorph right-click?

by Stephan Eggermont

How am I supposed to use TextMorph? It pops a debugger on right-click when doing a TextMorph new contents: 'Text'; openInWorld TextMorph(Object)>>doesNotUnderstand: #editView. Stephan

May 2, 2015

Re: [Pharo-dev] [QUESTION] For Dark Theme users

by Esteban Lorenzano

> On 02 May 2015, at 04:10, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > This is maybe a little 'too' dark. > Maybe we can do a setting to choose if we want it more or less dark. yes, but we also need a good default, because most people will not tune their system until they are used to it :) So, I think we need to restore the âpreference theme settingsâ options (another brick in the wallâ¦ I mean another todo entry in my list) And in the mean time I will chose something between current and my proposal (because Iâm convinced current one does not offer good contrast). Esteban > > An other think that would be good with the dark theme is to change the color of the Test Runner because the fluo green attack the eyes when we're on the dark theme x_x. > > Since we talk about the dark theme, is that normal than the background of the RubScrolledTextMorph stay white ? Or should I use an other Rub text morph ? > > On 1 May 2015 at 13:52, phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>> wrote: > Dawn Theme is lighter actually. > > As long as it is not black ... > > Phil > > Le 1 mai 2015 12:34, "Esteban Lorenzano" <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : > I suppose "Down Themeâ users (cough, cough, Phil) too. > > I want to change the background color for something even darker: > > <Screen Shot 2015-05-01 at 12.33.48.png> > > > > I think it look betterâ¦ what do you think? > > (Alsoâ¦ I need to refactor this theme thingyâ¦ is really ugly :P) > > Esteban > > > > -- > Cheers > Cyril Ferlicot

May 2, 2015

Re: [Pharo-dev] [QUESTION] For Dark Theme users

by Esteban Lorenzano

> On 02 May 2015, at 04:10, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > This is maybe a little 'too' dark. > Maybe we can do a setting to choose if we want it more or less dark. > > An other think that would be good with the dark theme is to change the color of the Test Runner because the fluo green attack the eyes when we're on the dark theme x_x. > > Since we talk about the dark theme, is that normal than the background of the RubScrolledTextMorph stay white ? Or should I use an other Rub text morph ? is a bug in Rubric. you have to explicitly tell him the backgroundColor or it will default white (instead default to the theme background color, who would be the good fix). Esteban > > On 1 May 2015 at 13:52, phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>> wrote: > Dawn Theme is lighter actually. > > As long as it is not black ... > > Phil > > Le 1 mai 2015 12:34, "Esteban Lorenzano" <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : > I suppose "Down Themeâ users (cough, cough, Phil) too. > > I want to change the background color for something even darker: > > <Screen Shot 2015-05-01 at 12.33.48.png> > > > > I think it look betterâ¦ what do you think? > > (Alsoâ¦ I need to refactor this theme thingyâ¦ is really ugly :P) > > Esteban > > > > -- > Cheers > Cyril Ferlicot

May 2, 2015

Re: [Pharo-dev] sometimes Shout changes the selection during styling

by stepharo

Le 27/4/15 14:41, Andrei Chis a Ã©crit : > Hi, > > In the glamour debugger that we use in moose we are now having the > following problem: > - the selection of a PluggableTextMorph is, quite randomly , changed > during styling. > > If I revert the fix for issue 15240 > <https://pharo.fogbugz.com/f/cases/15240> then it works ok. > Also if I change in SHTextStyler>>#styleInBackgroundProcess: from > > sem waitTimeoutSeconds: 5. > view ifNotNil: [ view stylerStyledInBackground: text ] > > to: > > (sem waitTimeoutSeconds: 5) ifFalse: [ > view ifNotNil: [ view stylerStyledInBackground: text ] ] > > it works ok. In the second snippet we only do the styling if the > styler completed. > > > If I look at the senders of styleInBackgroundProcess: there is another > strange issue. > First PluggableTextMorph>>#setText: calls either style: > or styleInBackgroundProcess:, depending in the size of the text. > Then, PluggableTextMorph>>#setText: > calls PluggableTextMorph>>#setTextBasic:, which calls > PluggableTextMorph>>#hasUnacceptedEdits: which in turn > calls again styleInBackgroundProcess:. > So when you set the text if the size of the text is small Shout will > try to style the text with and without a background process. If you > call hasUnacceptedEdits: > manually when initializing the morph then three processes will be > started for doing the styling. Ouch. And I imagine that it can be a mess after. Thanks for looking at this issue. > > Removing the calls to styleInBackgroundProcess: from > PluggableTextMorph>>#hasUnacceptedEdits: and > PluggableTextMorph>>#basicHasUnacceptedEdits:. > also solves the problem with the changing selection. > > Cheers, > Andrei

May 2, 2015

Re: [Pharo-dev] Are these changes good enough

by Esteban Lorenzano

INRIA style. sounds like super bureaucracy, but let me tell you, without going into details, that at least once it has proven useful :) Esteban > On 02 May 2015, at 01:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Fri, May 1, 2015 at 7:44 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > Could you send the license agreement and send it to us? > > Ha! I completely forgot about doing this. > I'm just surprised that legally having somewhere written something like "by contributing to blablabla you agree with license blablabla" is not enough. > > Peter

May 2, 2015

Re: [Pharo-dev] PluggableTextMorph vs PluggableTextEditorMorph

by stepharo

No idea but if the difference is that small then this is clear that we should remove one. > What is the difference between (or different use cases for) > PluggableTextMorph and PluggableTextEditorMorph ? > > Do we need both? > > The only difference I see: > You can not toggle enabled/disabled a PluggableTextMorph, > whereas a PluggableTextEditorMorph can be disabled. > > > > nicolai >

May 2, 2015