2015-03-24 16:43 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:

The same in Brick:

GLMButtonBrick new

...

marginLeft: 10; text: 'Parse'; vAlign: #center; hSpaceFill; openInBrickWindow

Yes, I agree - using composition for margin/padding/aligning is much more simple, readable, fast and maintainable, than horrible scripting in brick, sorry for that.

Yes, I'm pretty sure writing the same stuff in Motif or Windows 3.1 works too. Oh, well, maybe not in Windows 3.1 ;) And, so what? Is the contest writing a basic, business gui of the 80's the shortest way? Thierry

Hi Kilon, The situation is like this. For quite a while we did not have enough expertise in this community to build serious UI frameworks that can work. In the meantime we learnt a lot. GT is not just a couple of windows. It's an experiment of building something that does not exist anywhere else, and we learnt a lot from doing it. For example, to make Spotter both responsive and robust, the most difficult part was to learn to build the machinery behind, but now we are passed that initial step. At the same time, Alain put a ton of effort in Bloc. Athens was exercised both as the engine behind Block and from the Roassal team. And there are others like Sean, Nicolai and Ben who work around the same areas. This are all seemingly parallel and uncoordinated efforts, but they are converging. It is exactly because we are committed to the long term goal of building a real and better alternative to Morphic that we choose to not stop half way with Brick which is probably enough for GT purposes and choose instead to invest in evaluating Bloc. Yes, we do not have the replacement now, but we have never had so much investment and will around the UI as we have now. We do not know at this point what is the better way, we do not know the exact roadmap because it is more than just a matter of implementation. But, I know that the kinds of results we had recently around the UI is a highly encouraging predictor. Cheers, Doru On Tue, Mar 24, 2015 at 5:19 PM, kilon alios <kilon.alios@gmail.com> wrote:

" if you read my mail, you will notice that I said BOTH are on the table (and we are actually moving oon both): - Bloc is the redesign - In the mean time we WORK and ENCOURAGE others to work on improve it."

Last time I asked about Bloc , I was told not to use it and instead stick with Spec or Morphic.

I said it before and will say it again, you guys need to sit down and make a roadmap for Pharo because I am reading a lot of conflicting posts in this mailing list and this is does not give the professional look Pharo wants to show to people outside Pharo. As a user "replace in the long run" is not enough ! The original author of Bloc , Alain, also said that he is pretty much the only one that works on Bloc (with some help from Stef) and if people dont start helping him out he is going to give up.

How many more threads should we have about the GUI future of Pharo before people really get the message that we need a roadmap ?

Additionally , Pharo needs a roadmap , seriously it does.

"but Morphic it self has several fundamental flaws that cannot be fixed and that’s why in the long, very long way, needs to be replaced. "

What flaws , where , when , how , why ? So much discussion that Morphic must go , close to zero discussion what the actual problems are.

"First, Athens is not a replace for Morphic, is a replace for the canvas in which morphs are drawn. So is not Morphic or Athens… is "Morph using DisplayPlugin" or "Morphic using Athens".

Second I did not say Athens is to replace Morphic . From my understanding Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am wrong.

"Glamour is very mature and I’ve used it serval times… and in theory Brick will be compatible with Glamour (mostly) so even if developers deprecate one for the other you will be able to use your code (mostly). "

Brick is called non usable by its own authors. Glamour is framework of building browsers and simplified GUIs , its nowhere near as powerful as Morphic and is based on Morphic. From the looks of its is not even as powerful as Spec. Through the couple years I have been around I have seen at best a couple of question on how to make it work compared to hundreds of questions about Spec and Morphic . How something can be matured if it is not heavily used ?

"But anyway, how can Athens be so slow? Why? Can you share some info? "

You ask me to tell you why Athens is slow when we have this discussion before ( a few months ago) and you told me that Athens is slow because of how Pharo handles rendering and that as soon as we move to SDL things will be 10 times faster.

All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for mercy at 50% consumption. Calling it slow , is an understatement.

Other much simpler example are very slow too like the sliding logo example at many more.

Of course this problem affects Morphic too so personally I am examining the possibility that no pharo library will satisfy me and instead I will make my own GUI API on top of QT or HTML. Obviously more work for me, obviously a scenario that I want to avoid, but if the alternative is an app that consumes 50% cpu then I dont have much of a choice. Maybe I could take a look at Mars too.

-- www.tudorgirba.com "Every thing has its own flow"

Tudor , I am only amazed how much you guys accomplish with so limited resources. I may not agree with some of the choices but I am very happy with the progress Pharo is making and glad I stick around. If the community is not ready for a roadmap , so be it. You will be ready when you will be ready.I do think however that more the community grows coordinating effort will become a key issue. I do agree that things look very encouraging and I trust the community to move Pharo forward. Just a side note: what I find cool about Pharo GUI coding is that all tools are written in Pharo. Its easy to take this for granted but taking a look at other dynamic programming languages shows that his is a blessing. I have to confess I did not understand this obsession of implementing everything in Pharo when I joined coming from python. But now I find this obsession too infectious to resist :) On Tue, Mar 24, 2015 at 11:56 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi Kilon,

The situation is like this. For quite a while we did not have enough expertise in this community to build serious UI frameworks that can work. In the meantime we learnt a lot. GT is not just a couple of windows. It's an experiment of building something that does not exist anywhere else, and we learnt a lot from doing it. For example, to make Spotter both responsive and robust, the most difficult part was to learn to build the machinery behind, but now we are passed that initial step. At the same time, Alain put a ton of effort in Bloc. Athens was exercised both as the engine behind Block and from the Roassal team. And there are others like Sean, Nicolai and Ben who work around the same areas.

This are all seemingly parallel and uncoordinated efforts, but they are converging. It is exactly because we are committed to the long term goal of building a real and better alternative to Morphic that we choose to not stop half way with Brick which is probably enough for GT purposes and choose instead to invest in evaluating Bloc.

Yes, we do not have the replacement now, but we have never had so much investment and will around the UI as we have now. We do not know at this point what is the better way, we do not know the exact roadmap because it is more than just a matter of implementation. But, I know that the kinds of results we had recently around the UI is a highly encouraging predictor.

Cheers, Doru

On Tue, Mar 24, 2015 at 5:19 PM, kilon alios <kilon.alios@gmail.com> wrote:

...

" if you read my mail, you will notice that I said BOTH are on the table (and we are actually moving oon both): - Bloc is the redesign - In the mean time we WORK and ENCOURAGE others to work on improve it."

Last time I asked about Bloc , I was told not to use it and instead stick with Spec or Morphic.

I said it before and will say it again, you guys need to sit down and make a roadmap for Pharo because I am reading a lot of conflicting posts in this mailing list and this is does not give the professional look Pharo wants to show to people outside Pharo. As a user "replace in the long run" is not enough ! The original author of Bloc , Alain, also said that he is pretty much the only one that works on Bloc (with some help from Stef) and if people dont start helping him out he is going to give up.

How many more threads should we have about the GUI future of Pharo before people really get the message that we need a roadmap ?

Additionally , Pharo needs a roadmap , seriously it does.

"but Morphic it self has several fundamental flaws that cannot be fixed and that’s why in the long, very long way, needs to be replaced. "

What flaws , where , when , how , why ? So much discussion that Morphic must go , close to zero discussion what the actual problems are.

"First, Athens is not a replace for Morphic, is a replace for the canvas in which morphs are drawn. So is not Morphic or Athens… is "Morph using DisplayPlugin" or "Morphic using Athens".

Second I did not say Athens is to replace Morphic . From my understanding Bloc is based on Athens and Bloc is to replace Morphic. Correct me If I am wrong.

"Glamour is very mature and I’ve used it serval times… and in theory Brick will be compatible with Glamour (mostly) so even if developers deprecate one for the other you will be able to use your code (mostly). "

Brick is called non usable by its own authors. Glamour is framework of building browsers and simplified GUIs , its nowhere near as powerful as Morphic and is based on Morphic. From the looks of its is not even as powerful as Spec. Through the couple years I have been around I have seen at best a couple of question on how to make it work compared to hundreds of questions about Spec and Morphic . How something can be matured if it is not heavily used ?

"But anyway, how can Athens be so slow? Why? Can you share some info? "

You ask me to tell you why Athens is slow when we have this discussion before ( a few months ago) and you told me that Athens is slow because of how Pharo handles rendering and that as soon as we move to SDL things will be 10 times faster.

All I have to do is VGTiger runDemo and my 3Ghz Quad Cores beg me for mercy at 50% consumption. Calling it slow , is an understatement.

Other much simpler example are very slow too like the sliding logo example at many more.

Of course this problem affects Morphic too so personally I am examining the possibility that no pharo library will satisfy me and instead I will make my own GUI API on top of QT or HTML. Obviously more work for me, obviously a scenario that I want to avoid, but if the alternative is an app that consumes 50% cpu then I dont have much of a choice. Maybe I could take a look at Mars too.

-- www.tudorgirba.com

"Every thing has its own flow"

On Wed, Mar 25, 2015 at 6:08 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:

...

I have to confess I did not understand this obsession of implementing everything in Pharo when I joined coming from python. But now I find this obsession too infectious to resist :) That's why its impossible to convert people via HN and Reddit. Like skydiving (I imagine), it seems like a really bad idea to leave the safety of ill-conceived vendor-supplied tools until you jump and actually live it for yourself for long enough to realize what freedom feels like!

One of the things that drew me to do the Delay refactoring, is simply that I could. That is, I was amazed that I could dig so deep so easily, see a path to improvement and effect change at a fundamental level. Excepting complexities with the CI due to "changing the wheels on the car at 100km/h" (and one slip), it seems to have gone reasonably smoothly. That sense of mastery is seductive. cheers -ben