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

Slots and MethodWrappers

by phil＠highoctane.be

I wondered how these two things are related. Will slots be giving MWs facilities out of the box? When should I use both? Phil

March 24, 2015

Re: [Pharo-dev] Update question

by Sean P. DeNigris

NorbertHartl wrote > What would be better using PharoLauncher? I was a hold out, but I've finally started using it and it's really nice. For things that don't have an automated build process, it's much better than downloading from file.pharo.org by hand. You can set the folder to which the images get saved, and choose to make new images from e.g. Pharo 4, 3, 2, moose, anything on the contribution CI server, and a few others. I really like Peter's idea to act from a startup script based on the image name. That sounds like a powerful combination. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Update-question-tp4814680p4814725.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Re: [Pharo-dev] Update question

by Serge Stinckwich

PharoLauncher manage all your images and dl new images directly from the CI server. PharoLauncher is written in Pharo and can be adapted to your own needs ;-) Sent from my iPhone > On 24 mars 2015, at 12:38, Norbert Hartl <norbert(a)hartl.name> wrote: > > What would be better using PharoLauncher? > > Norbert > >> Am 24.03.2015 um 12:30 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: >> >> Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my work and I download new images every 2-3 days. >> >> Sent from my iPhone >> >>> On 24 mars 2015, at 11:13, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Today I wanted (again) to update my image and it can't find GT packages. So I'm interested how the community deals with that. Do you take fresh downloaded images regularly? Or you do not update? Is it just me? >>> >>> thanks, >>> >>> Norbert > >

March 24, 2015

Re: [Pharo-dev] Update question

by Norbert Hartl

What would be better using PharoLauncher? Norbert > Am 24.03.2015 um 12:30 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my work and I download new images every 2-3 days. > > Sent from my iPhone > >> On 24 mars 2015, at 11:13, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Today I wanted (again) to update my image and it can't find GT packages. So I'm interested how the community deals with that. Do you take fresh downloaded images regularly? Or you do not update? Is it just me? >> >> thanks, >> >> Norbert >> >> >

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Tudor Girba

Hi Nicolai, I am surprised by your conclusion that the current Brick implementation disqualifies it from being part of the Core :) Let's recap. Brick was created to support GT. We wanted GT in the image, hence Brick is in the image as part of Glamour. In the meantime, Brick has grown and it's now an almost standalone framework, but it is not yet advisable to use it apps because it will likely change more. As Alex says, we do not want to have two competing new projects running in parallel (Brick and Bloc) and fragmenting the effort even more. That is why, for Pharo 5 we want to invest in Bloc. The interesting thing is that while Bloc starts from scratch, Brick already works and has quite some high level widgets and logic built in. Brick is already going in the same direction expected by Bloc, so we will likely have the opportunity of moving Brick on top of Bloc (Alex already did an experiment in this direction). Concretely, on March 31 and April 1 (no joke :)), we have a session in Bern where Alain Plantec will join us to look into how to approach this problem concretely. All in all, you should see Brick as a pragmatic intermediary step towards removing Morph. I agree that it can be better (what cannot be), but I disagree we should discard GT because of it. Cheers, Doru On Tue, Mar 24, 2015 at 12:06 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Hi, >> >> Sorry if my reply will be too long, but I tried to summarise our >> experience with Morphic/Brick and give some useful feedback or even provide >> ideas. Who wants will read :) >> > > Hi, > thank you, this is a really great source of information, and it would be > heplful > to have this kind of write up somewhere else (not in the mailinglist). > But I did not question why we may need brick or why it is done. > My question was, what are the feature plans, is it just an experiment that > can vanish, so it is better to not use it for the core tools. Or is it > meant to be > THE new framework we should gain our focus on. > > >> >> Brick is not a thin layer anymore. >> >> It depends on what you mean under 'a thin layer' ;) Anyway, Brick was >> born out of need. Spotter is completely built using Brick and Rubric. >> > > This is something I don't understand. As we integrated GT-Tools into the > image, Rubric > slipped in as it is need by GT. I asked what is the background, what are > the feature plans > and complained about the undocumented core classes, that makes it > difficult to see > what changed compared to the old text classes. Alain said he doesn't plan > to do further > work on Rubric. > So, WHY don't we replace and migrate the existing classes now and clean it > up. It takes so > much resources to maintain both. Every theme change, every change on > shortcuts/menus/keymapping, the athens drawing, all has to be double > checked - It is so exhausting. > > > >> No morphs are used at all (except Rubric of course). >> > > Well, all Bricks ARE morphs, they share the same state and api. > > >> All Bricks in Spotter in the end are subclasses of GLMBrick, which uses >> from original Morph only Canvas (without drawing) and MorphicEvents. >> > > If so, the clean/better way would be to extract those part into a > "ProtoMorph" or a "PlainMorph". > and subclass from that once for Brick and again for Morphs. > Now we have Bricks, that are looking like a Morph, but aren't used to be > one, and probable doesn't even work if they are used as Morphs. > (Sure this is true for other Morphsubclasses as well, but that does not > means it doesn't hurt if we do more of this). > > >> Everything else was rewritten from scratch. During some period of time >> Brick was able to render itself on Athens canvas, but we dropped it because >> of Font issues in athens. >> > There are even more issues for Athens, and they don't vanish magically. > There are some issues > on fogbugz just waiting for some feedback, preferable from people > intending to use Athens. > > >> Spotter is not the only tool written using Brick, GLMPager - a pane pager >> in GT-Inspector, GT-Playground and GT-Debugger is also completely done >> using Brick. Almost all tab labels and tab selector in GT tools are Bricks. >> >> > ... > > >> >> We really would like to move all tools to Bloc as soon as possible, but >> we just need something right now that works and can be used in current >> version. >> > > But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it > is needed to push > this into the release. > > >> I think we will never (but who knows) announce Brick as separate >> project. In our minds it is just useful helper library. >> > > For me, this just disqualifies Brick from being used in the core image. > > > I see that many things in the GToolkit are better than the old one > (theming/layouting/delegate behavior in sub(classes/bricks). Great, it > makes fun to work with it,extending the inspector or Spotter search. > > But I don't understand why this is pushed that way and on top of the old > system/classes instead of cleaning that up. > > > nicolai > > >> >> Thanks for reading :) >> >> Cheers, >> Alex >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] Update question

by Serge Stinckwich

Don't update use PharoLauncher instead ! I use PharoLauncher everyday for my work and I download new images every 2-3 days. Sent from my iPhone > On 24 mars 2015, at 11:13, Norbert Hartl <norbert(a)hartl.name> wrote: > > Today I wanted (again) to update my image and it can't find GT packages. So I'm interested how the community deals with that. Do you take fresh downloaded images regularly? Or you do not update? Is it just me? > > thanks, > > Norbert > >

March 24, 2015

Re: [Pharo-dev] GLMBrick whats next?

by Nicolai Hess

2015-03-23 20:54 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi, > > Sorry if my reply will be too long, but I tried to summarise our > experience with Morphic/Brick and give some useful feedback or even provide > ideas. Who wants will read :) > Hi, thank you, this is a really great source of information, and it would be heplful to have this kind of write up somewhere else (not in the mailinglist). But I did not question why we may need brick or why it is done. My question was, what are the feature plans, is it just an experiment that can vanish, so it is better to not use it for the core tools. Or is it meant to be THE new framework we should gain our focus on. > > Brick is not a thin layer anymore. > > It depends on what you mean under 'a thin layer' ;) Anyway, Brick was born > out of need. Spotter is completely built using Brick and Rubric. > This is something I don't understand. As we integrated GT-Tools into the image, Rubric slipped in as it is need by GT. I asked what is the background, what are the feature plans and complained about the undocumented core classes, that makes it difficult to see what changed compared to the old text classes. Alain said he doesn't plan to do further work on Rubric. So, WHY don't we replace and migrate the existing classes now and clean it up. It takes so much resources to maintain both. Every theme change, every change on shortcuts/menus/keymapping, the athens drawing, all has to be double checked - It is so exhausting. > No morphs are used at all (except Rubric of course). > Well, all Bricks ARE morphs, they share the same state and api. > All Bricks in Spotter in the end are subclasses of GLMBrick, which uses > from original Morph only Canvas (without drawing) and MorphicEvents. > If so, the clean/better way would be to extract those part into a "ProtoMorph" or a "PlainMorph". and subclass from that once for Brick and again for Morphs. Now we have Bricks, that are looking like a Morph, but aren't used to be one, and probable doesn't even work if they are used as Morphs. (Sure this is true for other Morphsubclasses as well, but that does not means it doesn't hurt if we do more of this). > Everything else was rewritten from scratch. During some period of time > Brick was able to render itself on Athens canvas, but we dropped it because > of Font issues in athens. > There are even more issues for Athens, and they don't vanish magically. There are some issues on fogbugz just waiting for some feedback, preferable from people intending to use Athens. > Spotter is not the only tool written using Brick, GLMPager - a pane pager > in GT-Inspector, GT-Playground and GT-Debugger is also completely done > using Brick. Almost all tab labels and tab selector in GT tools are Bricks. > > ... > > We really would like to move all tools to Bloc as soon as possible, but we > just need something right now that works and can be used in current version. > But wyh not waiting on Bloc or (even better) help finishing Bloc. Why it is needed to push this into the release. > I think we will never (but who knows) announce Brick as separate project. > In our minds it is just useful helper library. > For me, this just disqualifies Brick from being used in the core image. I see that many things in the GToolkit are better than the old one (theming/layouting/delegate behavior in sub(classes/bricks). Great, it makes fun to work with it,extending the inspector or Spotter search. But I don't understand why this is pushed that way and on top of the old system/classes instead of cleaning that up. nicolai > > Thanks for reading :) > > Cheers, > Alex >

March 24, 2015

Re: [Pharo-dev] Morphs becoming unresponsive

by Henrik Johansen

> On 24 Mar 2015, at 11:22 , Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > Subject: Re: [Pharo-dev] Morphs becoming unresponsive > From: Alain Plantec <alain.plantec(a)yahoo.com> > Date: 24 Mar 2015 11:21:55 CET > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello Henrik, > > I read > windowEvent: anEvent > .... > WorldState quitSession. > self removeProperty: #closeWorldDialogOpen ] > > but shouldn't it be > > windowEvent: anEvent > .... > WorldState quitSession. > self removeProperty: #canOpenCloseDialog ] > > Cheers > Alain You are right of course, thanks! Last minute renames are never a good idea, even when the method is 5 lines long :/ I submitted a new slice where the property name is consistent. Cheers, Henry

March 24, 2015

Populating/editing list with modal dialogs in Glamour

by Yuriy Tymchuk

Hi everyone, Iâm playing with glamour, and Iâm trying to construct a list that can be edited e.g. you can add items, edit them and remove and for adding and editing you have a custom popup written again in glamour. So first question is how can I dead with basic actions? Is the GLMActionListPresentation way to go, or I should look on the other things. Another question is how do you open a modal window with glamour and how do you get the result from it. Iâll be very thankful for any reply. Cheers. Uko

March 24, 2015

Re: [Pharo-dev] Update question

by Thierry Goubier

2015-03-24 11:13 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > Today I wanted (again) to update my image and it can't find GT packages. > So I'm interested how the community deals with that. Do you take fresh > downloaded images regularly? Or you do not update? Is it just me? > I don't update. I want to make sure my developments are buildable somewhere else (for a team member, for versionning, for moving work from one computer to another), so I make sure I have a script for a fresh image (and I regularly rebuild (i.e. commit, push, make clean, make). My scripts are Makefiles, and the Makefiles are in the version control system. Thierry > > thanks, > > Norbert > > >

March 24, 2015