November 2013 - Pharo-users

Re: [Pharo-users] Building a simple UI with Spec. Problem with menus.

by StÃ©phane Ducasse

> Hi, this is my first post in the Pharo group. Welcome :) > I'm developing a simple Text Editor with some nice features as a way to > understand how Spec works. It seems that Spec will be the default UI > framework from Pharo 3 onwards, I know it's changing and evolving but I'll > take the risk. Super! > The problem I'm facing is that I'm lost at trying to add a "Save as..." > option in the menu. > It seems that Spec is still using the Morphic MenuMorph>>ToggleMenuItemMorph > but it's not clear to me hoy to add this item. > On the other hand, inspecting the ComposableModel class, it seem that in the > future this will be done directly in Spec as suggested by the > ComposableModel>>addMenuItemsToWindowMenu: > But so far that method simply says "do nothing". > Any help? > Thanks in advance > Cheers > Nacho > > > > -- > View this message in context: http://forum.world.st/Building-a-simple-UI-with-Spec-Problem-with-menus-tp4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Nov. 3, 2013

Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

by StÃ©phane Ducasse

But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different? > >> no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website >> > The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code > was in the image. > > These days, what people do is to have an automatic (and well defined) process that build a fresh image on > -> base system is updated > -> Own code commit > > So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image > away. Images are transient things. > > This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a whileâ¦. > (In turn, everything we want to be sure works needs to be tested after every commit, but testing âupdating every old version to the newestâ > is not really testable, anaywayâ¦) > > When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we > support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build processâ¦ > > Marcus > >

Nov. 3, 2013

Re: [Pharo-users] Yet another "building a GUI" question

by StÃ©phane Ducasse

Excellent! I will integrate it. Now I'm back from a really cool turn into buenos aires. There are really cool places :) On Nov 3, 2013, at 11:10 PM, Benjamin Van Ryseghem <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > After a bit of research I found the beginning of the thread :) > > I integrated your code in Spec (after minor fixes). > You can see it here: https://pharo.fogbugz.com/default.asp?12066 > > Thanks :) > > Ben > > > 2013/11/3 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> > I think I missed the beginning of this thread :) > So my question is what do you want to do ? :) > > I tried your ImageSpecTest, and after a minor fix, it opens :) > But expect displaying an ImageMorph, it is not really usable :) > > Ben > > On 03 Nov 2013, at 21:37, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > >> 2013/11/3 Sergi Reyner <sergi.reyner(a)gmail.com> >> >> Something like this: >> >> initializeWidgets >> self >> instantiateModels: >> { (#listModel -> #ListComposableModel). >> (#pictureModel -> #AlphaImageModel). >> } >> >> I gave it another try, and after a few attempts I managed to put together a working example of what I meant, in Pharo 3.0. I attach the .mcz file. >> >> Cheers, >> Sergi >> <Raytests-SergiReyner.1.mcz> > >

Nov. 3, 2013

Re: [Pharo-users] Yet another "building a GUI" question

by Benjamin Van Ryseghem

After a bit of research I found the beginning of the thread :) I integrated your code in Spec (after minor fixes). You can see it here: https://pharo.fogbugz.com/default.asp?12066 Thanks :) Ben 2013/11/3 Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> > I think I missed the beginning of this thread :) > So my question is what do you want to do ? :) > > I tried your ImageSpecTest, and after a minor fix, it opens :) > But expect displaying an ImageMorph, it is not really usable :) > > Ben > > On 03 Nov 2013, at 21:37, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > > 2013/11/3 Sergi Reyner <sergi.reyner(a)gmail.com> > >> >> Something like this: >> >> initializeWidgets >> self >> instantiateModels: >> { (#listModel -> #ListComposableModel). >> (#pictureModel -> #AlphaImageModel). >> } >> > > I gave it another try, and after a few attempts I managed to put together > a working example of what I meant, in Pharo 3.0. I attach the .mcz file. > > Cheers, > Sergi > <Raytests-SergiReyner.1.mcz> > > >

Nov. 3, 2013

Re: [Pharo-users] Yet another "building a GUI" question

by Sergi Reyner

El 03/11/2013 21:45, "Benjamin" <Benjamin.VanRyseghem.Pharo(a)gmail.com> escribiÃ³: > > I think I missed the beginning of this thread :) > So my question is what do you want to do ? :) I want to have a way to get an AlphaImageMorph linked to a ValueHolder(?) holding a Form(?), and having it update automatically, for example in response to selecting an item from a list. Cheers, Sergi

Nov. 3, 2013

Re: [Pharo-users] Yet another "building a GUI" question

by Benjamin

I think I missed the beginning of this thread :) So my question is what do you want to do ? :) I tried your ImageSpecTest, and after a minor fix, it opens :) But expect displaying an ImageMorph, it is not really usable :) Ben On 03 Nov 2013, at 21:37, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > 2013/11/3 Sergi Reyner <sergi.reyner(a)gmail.com> > > Something like this: > > initializeWidgets > self > instantiateModels: > { (#listModel -> #ListComposableModel). > (#pictureModel -> #AlphaImageModel). > } > > I gave it another try, and after a few attempts I managed to put together a working example of what I meant, in Pharo 3.0. I attach the .mcz file. > > Cheers, > Sergi > <Raytests-SergiReyner.1.mcz>

Nov. 3, 2013

Re: [Pharo-users] Yet another "building a GUI" question

by Sergi Reyner

2013/11/3 Sergi Reyner <sergi.reyner(a)gmail.com> > > Something like this: > > initializeWidgets > self > instantiateModels: > { (#listModel -> #ListComposableModel). > (#pictureModel -> #AlphaImageModel). > } > I gave it another try, and after a few attempts I managed to put together a working example of what I meant, in Pharo 3.0. I attach the .mcz file. Cheers, Sergi

Nov. 3, 2013

Re: [Pharo-users] [Pharo-dev] moving moose to pharo 3.0

by Camillo Bruni

On 2013-11-03, at 21:11, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :). > > What posed problems: > - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages. > - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object>>#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose. > - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only. > - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour. > - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method. opened an issue for that: https://pharo.fogbugz.com/f/cases/12062/ensureDirectory-and-ensureFile-shou… > - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species. > - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo. > > All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 3, 2013

moving moose to pharo 3.0

by Tudor Girba

Hi, We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :). What posed problems: - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages. - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object>>#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose. - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only. - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour. - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method. - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species. - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo. All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 3, 2013

Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.

by Sven Van Caekenberghe

On 03 Nov 2013, at 20:01, phil(a)highoctane.be wrote: > Marcus, > > FWIW, you are inspiring. I am amazed on how you keep the thing going. > > Thanks for showing the high road. > > Phil Indeed.

Nov. 3, 2013