March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

Jannik I'm doing it because this is exactly done like that in menuMorph: everything falls down to addToggle: aString target: anObject selector: aSymbol getStateSelector: stateSymbol enablementSelector: enableSymbol argumentList: argList "Append a menu item with the given label. If the item is selected, it will send the given selector to the target object." |item| item := ToggleMenuItemMorph new contents: aString; target: anObject; selector: aSymbol; arguments: argList; getStateSelector: stateSymbol; enablementSelector: enableSymbol. ^ self addMenuItem: item. :) On Mar 11, 2013, at 9:36 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Thanks Jannik. > I was thinking that > - we could have a different MenuItem class: ValuedMenuItem > - that a add:value: in MenuMorph could create an instance of this ValuedMenuItem > > Like that we can integrate both nicely. > > What do you think? > > Stef > > On Mar 11, 2013, at 9:33 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: > >> <MenuMorphNG.st> > >

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by stephane ducasse

Thanks Jannik. I was thinking that - we could have a different MenuItem class: ValuedMenuItem - that a add:value: in MenuMorph could create an instance of this ValuedMenuItem Like that we can integrate both nicely. What do you think? Stef On Mar 11, 2013, at 9:33 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: > <MenuMorphNG.st>

March 11, 2013

Re: [Pharo-project] Help with MenuMorph

by jannik.laval

On Mar 11, 2013, at 5:41 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Mar 11, 2013, at 2:10 PM, jannik laval <jannik.laval(a)gmail.com> wrote: > >> Hi Stef, >> >> I am searching to do that too. >> For now, I am using something else... And I plan to create new Menu more usable. >> >> Here is what I use, for your case, just adapt it when trying: >> >> === >> | aMenu sz on | >> on := soundInput isRecording. >> self stop. >> aMenu := MenuMorph new title: ('FFT size (currently {1})' translated format:{fft n}). >> ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [:r | >> aMenu add: r printString >> target: FFT >> selector: #new >> argument: r >> ]. >> >> aMenu popUpInWorld. >> >> self resetDisplay. >> on ifTrue: [self start]. >> === > > the problem is that we are missing a way to have menu that simply return a value (without resorting to a method execution and selector). Yes, I know :) Try this small class. I named it MenuMorphNG. You can use it like that: === menu := MenuMorphNG new defaultTarget: menu. menu add: 'test1' value: #testForPharo. menu addLine. menu add: 'test2' value: 2.0. menu localize; invokeModal. menu selectedValue === Jannik > > Stef >> >> Jannik >> >> >> 2013/3/11 stephane ducasse <stephane.ducasse(a)free.fr> >> In fact I see that the problem is more into >> >> how can I specify a menu item which returns a value that I specify without passing a symbol >> >> ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [:r | aMenu add: r printString action: r]. >> >> >> On Mar 11, 2013, at 1:28 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> >> > HI guys >> > >> > I'm trying to fix all the sound interface for 2.0 and I got trapped into MenuMorph. How do I schedule a menu and get its selected value? >> > I have to convert code like the following one. >> > >> > >> > >> > | aMenu sz on | >> > aMenu := MenuMorph new title: ('FFT size (currently {1})' translated format:{fft n}). >> > ((7 to: 10) collect: [:n | 2 raisedTo: n]) do: [:r | aMenu add: r printString action: r]. >> > >> > sz := aMenu popUpInWorld. >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > how can I get the selected value? >> > >> > >> > sz ifNil: [^ self]. >> > on := soundInput isRecording. >> > self stop. >> > fft := FFT new: sz. >> > self resetDisplay. >> > on ifTrue: [self start]. >> > >> > >> >> >> >> >> >> -- >> ~~Dr. Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> >

March 11, 2013

Re: [Pharo-project] building traits programmatically

by Igor Stasenko

On 9 March 2013 18:58, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > > On Sat, Mar 9, 2013 at 4:00 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> how to create trait programmatically? >> >> Here you go: >> >> trait := Trait named: #MyProgrammaticallyCreatedTrait. >> >> >> You can also do the same trick with classes, btw: >> >> newclass := Object subclass: #MyNewClass. >> >> ;) >> >> cool... ;) > +igor > > but then why do we need changes and change classes ? > > but yeah I asked a stupid question [?]... the DNU is still there though > that belongs to RB.. not Trait's problems. file a bug entry :) > -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > -- Best regards, Igor Stasenko.

March 11, 2013

Re: [Pharo-project] Code review tools?

by Igor Stasenko

On 11 March 2013 19:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 11 March 2013 17:54, Igor Stasenko <siguctua(a)gmail.com> wrote: >> pff... really people... i am thinking how to streamline our existing >> development process.. >> and instead i hear once again about git. > > Camillo needs to hit you around the head with a command line. You > haven't used it. You've heard several people who have used both > Monticello and git extensively say that git beats the crap out of > Monticello. Go and learn git properly. THEN come back and maybe we can > have a conversation. > I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image). >> okay, lets throw away MC & stuff, migrate everything on file-based >> file-per-method git repository >> and then navigate diffs on github, and trying to find senders or >> implementors of selector using web browser . > > I do believe you ought to take a moment and go read the archives. > Also, I happen to nearly violently disagree with the file-per-method > approach, but that's an entirely different kettle of fish. > > But you know what, just forget it. It's not your problem, other people > are already solving the problem, and one day hopefully you'll forget > all about this while quietly your tools happily use git under the > hood, where you neither know nor care. > I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient. > frank > -- Best regards, Igor Stasenko.

March 11, 2013

Re: [Pharo-project] Code review tools?

by Igor Stasenko

Let me clarify: - i am 10000% not against git i am for it. - what i am against is treating a source as a bunch of static files.. like github does. so, if you telling me that we should not reinvent the wheel and use github code review features, i would encourage you to explain me how you see that process, staring at web page and having no ability to navigate the code in a way how you navigating smalltalk code in image. And think, how good the quality of your reviews will be is you will be crippled by "static source code" approach. For me git as a backend is a way to go. But it looks like people misunderstood my original proposal, because git is orthogonal to what i want: i want more integration with issue tracker but more than that, i would love to have a tool which could create a reviews so i can send them to author or to bug tracker... and for creating a review i just need two versions of code.. and it is completely unimportant where those two versions come from: git, .cs, or .mcz files. -- Best regards, Igor Stasenko.

March 11, 2013

Re: [Pharo-project] Code review tools?

by Camillo Bruni

On 2013-03-11, at 18:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > pff... really people... i am thinking how to streamline our existing > development process.. > and instead i hear once again about git. > > okay, lets throw away MC & stuff, migrate everything on file-based > file-per-method git repository I can repeat this slowly for you, because even if you sit 1m away from me you seem to not hear me: 1. git for smalltalk is mostly going to be a backend 2. if we migrate to git it is going to be a fluent step by step process 3. you don't like file based?? what the heck does monticello store? right, zips, with what inside? right some strangely serialized data that is highly inefficient for parsing. 4. If smalltalk want's to be visible and every play along with other people we have to get out of the image, that implies file-based sources. 5. I don't care about git particularly, but it is what I know best, any other distributed versioning system does the trick here. > and then navigate diffs on github, and trying to find senders or > implementors of selector using web browser . tricky counter question: have you ever tried a diff of two mczs? without a running pharo image? right, doesn't work. So even with monticello you need decent image-based tools to accomplish things. So why not using something else than our highly exotic versioning backend. so no igor, most of your arguments are very invalid here.

March 11, 2013

Re: [Pharo-project] Code review tools?

by stephane ducasse

On Mar 11, 2013, at 7:06 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 11 March 2013 17:54, Igor Stasenko <siguctua(a)gmail.com> wrote: >> pff... really people... i am thinking how to streamline our existing >> development process.. >> and instead i hear once again about git. > > Camillo needs to hit you around the head with a command line. But if igor would concentrate on the command line I would hit him with something else :) > You > haven't used it. You've heard several people who have used both > Monticello and git extensively say that git beats the crap out of > Monticello. Go and learn git properly. THEN come back and maybe we can > have a conversation. Frank, do not say that because you do not know that igor would love to use git to manage the VM code. So do not generalise, life is complex. >> okay, lets throw away MC & stuff, migrate everything on file-based >> file-per-method git repository >> and then navigate diffs on github, and trying to find senders or >> implementors of selector using web browser . > > I do believe you ought to take a moment and go read the archives. > Also, I happen to nearly violently disagree with the file-per-method > approach, but that's an entirely different kettle of fish. > > But you know what, just forget it. It's not your problem, other people > are already solving the problem, and one day hopefully you'll forget > all about this while quietly your tools happily use git under the > hood, where you neither know nor care. I'm waiting for this day :)

March 11, 2013

Re: [Pharo-project] Code review tools?

by Frank Shearar

On 11 March 2013 17:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > pff... really people... i am thinking how to streamline our existing > development process.. > and instead i hear once again about git. Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation. > okay, lets throw away MC & stuff, migrate everything on file-based > file-per-method git repository > and then navigate diffs on github, and trying to find senders or > implementors of selector using web browser . I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish. But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care. frank

March 11, 2013

Re: [Pharo-project] Code review tools?

by stephane ducasse

On Mar 11, 2013, at 6:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> i am very happy that github exists.. and its features available only if you >>>> put code there.. >>>> but if code is not on github, then what you will do? >>> >>> To rephrase the question: what do we still need to do before we can >>> integrate (something like) github into a standard Smalltalk workflow? >> >> how many man month engineer time do you have free for that? >> Personally I prefer that >> FFI >> VM >> vector graphics >> â¦ >> get pushed. >> >> So git integration will come but on people free time. > > So I see, your git allergies haven't stopped yet No I'm not allergic. Get it working and I will use it. Now when I think about synectique or other projects I prefer to focus on offering something that work on important areas. Where is a decent FFI simple to use? Can we get a stable VM? Why do I have to spend hour trying to understand menusâ¦. Where is a decent UIBuilder? So my priority are into making the minimum works well. Stef

March 11, 2013