Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( you mean less messy Surely. I think that you did not look at Bloc because we have already a lot there and much nicer. You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
Hi Alain thierry did not look at Bloc :) We see it :) Stef Le 24/3/15 16:13, Alain Plantec via Pharo-dev a écrit :
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
Le 25/3/15 06:29, Ben Coman a écrit : 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. so nice that I blogged about it :)
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 15:16 GMT+01:00 Esteban Lorenzano esteba...@gmail.com: On 24 Mar 2015, at 14:29, kilon alios kilon.al...@gmail.com wrote: There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. 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. 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. One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
---BeginMessage--- Hello Esteban, Most probably is because you are doing double work: you draw with Athens, but you convert it to a Form to display it (and a Form is a Morph using DisplayPlugin). I can ensure you that if you use Athens directly with SDL2 (an example I can share with you anytime) it is orders of magnitude faster… please share :) I would like to learn how to use SDL2. Thanks Cheers Alain Esteban ---End Message---
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
---BeginMessage--- Hello Thierry, Le 24 mars 2015 à 15:24, Thierry Goubier thierry.goub...@gmail.com a écrit : One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( why do you think so ? Cheers Alain You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. Thierry ---End Message---
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
On 24 Mar 2015, at 14:29, kilon alios kilon.al...@gmail.com wrote: There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. 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. 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. I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc. 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). The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too. 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. But anyway, how can Athens be so slow? Why? Can you share some info? Most probably is because you are doing double work: you draw with Athens, but you convert it to a Form to display it (and a Form is a Morph using DisplayPlugin). I can ensure you that if you use Athens directly with SDL2 (an example I can share with you anytime) it is orders of magnitude faster… Esteban On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com wrote: And well… I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support… well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be “old stuff” and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric… but it cannot be used right now (or better: It cannot replace none of the previous yet) So… which one to use? We, the board, have something clear and some other not so clear yet, for example: - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. So well… yes this is a mess. Yes we are aware. No we don’t know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects… this is my recommendation: - Do not use “direct” Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon) And of course, I would help with fixes and reports on everything :) cheers, Esteban On 24 Mar 2015, at 12:37, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: Hi Nicolai, I am surprised by your conclusion that the current Brick implementation disqualifies it from being
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc. The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too. On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano esteba...@gmail.com wrote: And well… I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support… well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be “old stuff” and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric… but it cannot be used right now (or better: It cannot replace none of the previous yet) So… which one to use? We, the board, have something clear and some other not so clear yet, for example: - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. So well… yes this is a mess. Yes we are aware. No we don’t know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects… this is my recommendation: - Do not use “direct” Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon) And of course, I would help with fixes and reports on everything :) cheers, Esteban On 24 Mar 2015, at 12:37, Tudor Girba tu...@tudorgirba.com wrote: 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 nicolaih...@web.de wrote: 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel
[Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
And well… I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support… well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be “old stuff” and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric… but it cannot be used right now (or better: It cannot replace none of the previous yet) So… which one to use? We, the board, have something clear and some other not so clear yet, for example: - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. So well… yes this is a mess. Yes we are aware. No we don’t know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects… this is my recommendation: - Do not use “direct” Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon) And of course, I would help with fixes and reports on everything :) cheers, Esteban On 24 Mar 2015, at 12:37, Tudor Girba tu...@tudorgirba.com wrote: 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2015-03-23 20:54 GMT+01:00 Aliaksei Syrel alex.sy...@gmail.com mailto:alex.sy...@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
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
On 24 Mar 2015, at 14:23, Thierry Goubier thierry.goub...@gmail.com wrote: Hi Esteban, 2015-03-24 13:56 GMT+01:00 Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com: And well… I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the image, so the pain there is less) I suspect you mean Bloc, not Brick there, no? Now I'm lost ;) oops! yes, Bloc :P Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
Hi Esteban, 2015-03-24 13:56 GMT+01:00 Esteban Lorenzano esteba...@gmail.com: And well... I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and it's upcoming replace, Brick (but Brick is not in the image, so the pain there is less) I suspect you mean Bloc, not Brick there, no? Now I'm lost ;) Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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. Well said! Things have been converging for a long time. I remember Alain showed me a Bloc ancestor at my very first ESUG. I feel that it's taken so long precisely because of our concern to preserve the awesome build anything power of a live, direct Morphic world while building more more mundane/standard layer(s) on top. And the results do seems to be rapidly accelerating lately. For all of us who want to participate, I think the most important first step is research. Much good thinking about this has been done at and since PARC. There are great papers, articles, and videos available about: Self Morphic, the Star user interface, VPRI's experiments with e.g. text layout, MorphicWrappers and MathMorphs, the Alternate Reality Kit to name a few. You can also play with Self and Lively Kernel to see how things are done there. I think that if we were going to replace the live, direct, uniform Morphic world with merely a business UI toolkit that it would have been done a long time ago! - Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814926.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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 tu...@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.al...@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
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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! - Cheers, Sean -- View this message in context: http://forum.world.st/GLMBrick-whats-next-tp4797474p4814927.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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.al...@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
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 15:27 GMT+01:00 Alain Plantec via Pharo-dev pharo-dev@lists.pharo.org: -- Message transféré -- From: Alain Plantec alain.plan...@yahoo.com To: Pharo Development List pharo-dev@lists.pharo.org Cc: Date: Tue, 24 Mar 2015 15:27:18 +0100 Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?] Hello Thierry, Le 24 mars 2015 à 15:24, Thierry Goubier thierry.goub...@gmail.com a écrit : One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( why do you think so ? Because we're doing a rewrite, with no uses of the specifics of what Morphic uses. So whatever usage of a pattern of code, or of layout or display that was special to Morphic, will disappear: nobody will keep dead code which only exercise a corner case of Morphic alone. IMHO, Rubrics, just from it's layout approach, is already a step backward. Who knows why a Morph does z-ordering of its submorphs in the reverse order of all other gui toolkits? Has Bloc kept that? Why should it keep it? It's messing up Spec gui building. It will be disappear. Thierry Cheers Alain You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
Hi, 2015-03-24 15:27 GMT+01:00 Tudor Girba tu...@tudorgirba.com: Hi, I think I do not understand this point. Why do you say that the future solution will be less than Morphic? Because we're driving it with uses which are less than Morphic requirements were. Because you don't need Morphic power to do GT tools; it justs gets in the way: slow, over-engineered for that use case. As a consequence, you end up with Rubricks: dedicated, ad-hoc solution which is a far better match for its use case. That Rubricks proudly present its Z layering where Morphic was / is probably the easiest toolkit ever to do layering of arbitrary widgets on top of another? (*) Thierry (*) Even if we're not doing it(**). (**) Well, I did. Nobody's interested, so what ? Doru Thierry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
---BeginMessage--- Le 24 mars 2015 à 15:56, Thierry Goubier thierry.goub...@gmail.com a écrit : 2015-03-24 15:39 GMT+01:00 Denis Kudriashov dionisi...@gmail.com mailto:dionisi...@gmail.com: 2015-03-24 17:36 GMT+03:00 Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@gmail.com: IMHO, Rubrics, just from it's layout approach, is already a step backward. What you mean by this? What's wrong with Rubric layouting? Padding - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget Aligning - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget I don’t get it sorry. maybe one example would help ZOrdering - nothing says that submorphs in Morphic can't overlay each other. Bloc uses z-ordering exactly as Morphic (the code for adding/removing a submorph are nearly the same) Cheers Alain One of the issue with Morphic as it stands today is that the API is fairly complex if you want to carefully control placement and morph behavior under container resizing / move. Oh, and it's very buggy too. Rubricks shows an API which is even more complex, which isn't surprising if the inspiration is CSS layout. Thierry ---End Message---
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
Hi, On Tue, Mar 24, 2015 at 3:24 PM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-03-24 15:16 GMT+01:00 Esteban Lorenzano esteba...@gmail.com: On 24 Mar 2015, at 14:29, kilon alios kilon.al...@gmail.com wrote: There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. 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. 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. One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :( You'll probably tell me that for the kind of work we're doing in UI with Pharo, we don't need the power of Morphic and I'd agree with you. Still, I will miss the demise of Morphic. I think I do not understand this point. Why do you say that the future solution will be less than Morphic? Doru Thierry -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 15:39 GMT+01:00 Denis Kudriashov dionisi...@gmail.com: 2015-03-24 17:36 GMT+03:00 Thierry Goubier thierry.goub...@gmail.com: IMHO, Rubrics, just from it's layout approach, is already a step backward. What you mean by this? What's wrong with Rubric layouting? Padding - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget Aligning - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget ZOrdering - nothing says that submorphs in Morphic can't overlay each other. One of the issue with Morphic as it stands today is that the API is fairly complex if you want to carefully control placement and morph behavior under container resizing / move. Oh, and it's very buggy too. Rubricks shows an API which is even more complex, which isn't surprising if the inspiration is CSS layout. Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 16:43 GMT+01:00 Aliaksei Syrel alex.sy...@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
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
---BeginMessage--- Hello all, I think you should consider what is mature and what is in the image now. now we have Spec with Morphic, Morphic without Spec as an alternative, GT Tool framework (with Brick), Glamour. Regarding text editing we have Rubric. My fault, someone (sorry I don’t remember who) proposed to work on its integration (PluggableTextMorph replacement). As an answer, I said that I wouldn’t do it because of TxText. TxText is really cool but not fully integrated. Thus, maybe it was a mistake to not replace PluggableTextMorph with Rubric. And now yes, as a fork of PluggableTextMorph, Rubric brings a lot of code duplication. I guess we will have to live with that for a while. Cheers Alain Le 24 mars 2015 à 14:29, kilon alios kilon.al...@gmail.com a écrit : There is a big diffirence between Morphic and the other. Morphic is a full solution and mature one as well. The others , with the exception of Bloc , try to wrap things up or offering better solution to some areas. The one thing I don't understand is why improving Morphic or even redesigning it is not even on the table. Looks to me like the least painful scenario. Unless thats the intention of Bloc to be the next generation of Morphic. In that case I am all for Bloc. I am in a dilemma myself, I am currently deep into interfacing pharo with python for my project Ephestos but I will need to consider a GUI API soon. Spec is out of the question since I dont like the desing and does not support custom made GUIs which is what I want. Brick is as far as I understand an extension to morphic and not usable. Which leaves me with 2 candidates Morphic and Bloc. The one thing I really like about Bloc is that it is vectorial which is the kind of custom GUI I want to create but it will also have to be fast and since its related to Athens, Athens has proven very slow for my needs. So I am considering sticking to Morphic and make the GUI pseudo vectorial using bitmaps. In any case the situation is far from ideal . But I really like to push something forward (preferably Bloc or a new Morphci) and I would hate it if I go creating my own solution but that is a very likely scenario too. On Tue, Mar 24, 2015 at 2:56 PM, Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com wrote: And well… I think Nicolai is right in a point (not the fault of Brick, btw): current status is far from ideal: - we have Morphic, and it’s upcoming replace, Brick (but Brick is not in the image, so the pain there is less) - we have Spec to support our tooling. - we have Glamour to support… well, our tooling too. - we have now Brick, who (AFAIS) is an extension of Morphic, and a replacement the Morphic Widgets and also Glamour. GTTools team has explicitly declared Brick will replace Glamour (but API will remain largely compatible, they say). GTTools team has also stated they would use Bloc is they could/when they can. - We have the old Text Editor - We have Rubric, which was stated to be “old stuff” and deprecated - We have also the new TxModel which intends to replace both, Text Editor and Rubric… but it cannot be used right now (or better: It cannot replace none of the previous yet) So… which one to use? We, the board, have something clear and some other not so clear yet, for example: - we would like to replace Morphic with Bloc, but this is a lot of work and will take a lot of time so in the mean time we also clean old Morphic as much as we can (and we encourage people to do it) - Spec needs work too - Glamour will be replaced by Brick, so do not use it - TxModel will replace all the previous, but it needs a lor of work. In the mean time, we suggest to use and improve Rubric, and of course, we would like to have more people contributing to TxModel. So well… yes this is a mess. Yes we are aware. No we don’t know when things will improve, but *they will*. In the mean time as a Pharo user, I would like to know which one should I use for my projects… this is my recommendation: - Do not use “direct” Morphic unless doing graphics - Use TxModel and if you cannot, Rubric - Use Brick or Spec, not Glamour (because Brick will replace it soon) And of course, I would help with fixes and reports on everything :) cheers, Esteban On 24 Mar 2015, at 12:37, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com wrote: 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
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 16:03 GMT+01:00 Alain Plantec via Pharo-dev pharo-dev@lists.pharo.org: -- Message transféré -- From: Alain Plantec alain.plan...@yahoo.com To: Pharo Development List pharo-dev@lists.pharo.org Cc: Date: Tue, 24 Mar 2015 16:02:56 +0100 Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?] Le 24 mars 2015 à 15:56, Thierry Goubier thierry.goub...@gmail.com a écrit : 2015-03-24 15:39 GMT+01:00 Denis Kudriashov dionisi...@gmail.com: 2015-03-24 17:36 GMT+03:00 Thierry Goubier thierry.goub...@gmail.com: IMHO, Rubrics, just from it's layout approach, is already a step backward. What you mean by this? What's wrong with Rubric layouting? Padding - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget Aligning - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget I don't get it sorry. Padding by ten pixels to the left: | leftMargin aParserButton | leftMargin := Morph new width: 10; hResizing: #shrinkWrap; vResizing: #spaceFill. aParserButton := PluggableButtonMorph on: self getState: nil action: #parse. aParserButton hResizing: #spaceFill; vResizing: #shrinkWrap; label: 'Parse'. AlignmentMorph newRow vResizing: #shrinkWrap; hResizing: #spaceFill; layoutInset: 0; addMorph: aParserButton; addMorph: leftMargin; openInWorld Aligning to the center, horizontally: add a right and left morph, but hResizing: #spaceFill this time. Some type of constraints are hard to do with that system (*), but... LaTeX layout exclusively with that, so, maybe it works ;) ((*) And this is where someone knowing Rubricks could come with a few examples of those). maybe one example would help From the SmaCC GUI :) ZOrdering - nothing says that submorphs in Morphic can't overlay each other. Bloc uses z-ordering exactly as Morphic (the code for adding/removing a submorph are nearly the same) Ok. But do you know why? There is a reason for that choice. Spec had a real issue with that ordering, so the pressure will be to get it 'corrected'. Mind you, I consider Bloc a very good choice, but I fear that we're not able to stress it enough with hard, very advanced GUIs to ensure we're not loosing power compared to Morphic. Thierry Cheers Alain One of the issue with Morphic as it stands today is that the API is fairly complex if you want to carefully control placement and morph behavior under container resizing / move. Oh, and it's very buggy too. Rubricks shows an API which is even more complex, which isn't surprising if the inspiration is CSS layout. Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 17:36 GMT+03:00 Thierry Goubier thierry.goub...@gmail.com: IMHO, Rubrics, just from it's layout approach, is already a step backward. What you mean by this? What's wrong with Rubric layouting?
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
On Mar 24, 2015, at 10:29, kilon alios kilon.al...@gmail.com wrote: [Spec] does not support custom made GUIs which is what I want That’s simply not true. Spec supports the embedding of whatever Morph you want inside your GUI. So you can easily mix and match your custom components with all the standard Spec components. --- Save our in-boxes! http://emailcharter.org --- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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. One more time for people who still don't hear us. Brick is internal for GT. We just put in package named Brick reusable widgets we built to use in our tools. They just normal subclasses of morph. Nothing fancy. We don't want you to use it and suggest to learn Spec for UI, please. Keep Calm :) Cheers, Alex On Tue, Mar 24, 2015 at 4:28 PM, Thierry Goubier thierry.goub...@gmail.com wrote: 2015-03-24 16:03 GMT+01:00 Alain Plantec via Pharo-dev pharo-dev@lists.pharo.org: -- Message transféré -- From: Alain Plantec alain.plan...@yahoo.com To: Pharo Development List pharo-dev@lists.pharo.org Cc: Date: Tue, 24 Mar 2015 16:02:56 +0100 Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?] Le 24 mars 2015 à 15:56, Thierry Goubier thierry.goub...@gmail.com a écrit : 2015-03-24 15:39 GMT+01:00 Denis Kudriashov dionisi...@gmail.com: 2015-03-24 17:36 GMT+03:00 Thierry Goubier thierry.goub...@gmail.com: IMHO, Rubrics, just from it's layout approach, is already a step backward. What you mean by this? What's wrong with Rubric layouting? Padding - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget Aligning - resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget I don’t get it sorry. Padding by ten pixels to the left: | leftMargin aParserButton | leftMargin := Morph new width: 10; hResizing: #shrinkWrap; vResizing: #spaceFill. aParserButton := PluggableButtonMorph on: self getState: nil action: #parse. aParserButton hResizing: #spaceFill; vResizing: #shrinkWrap; label: 'Parse'. AlignmentMorph newRow vResizing: #shrinkWrap; hResizing: #spaceFill; layoutInset: 0; addMorph: aParserButton; addMorph: leftMargin; openInWorld Aligning to the center, horizontally: add a right and left morph, but hResizing: #spaceFill this time. Some type of constraints are hard to do with that system (*), but... LaTeX layout exclusively with that, so, maybe it works ;) ((*) And this is where someone knowing Rubricks could come with a few examples of those). maybe one example would help From the SmaCC GUI :) ZOrdering - nothing says that submorphs in Morphic can't overlay each other. Bloc uses z-ordering exactly as Morphic (the code for adding/removing a submorph are nearly the same) Ok. But do you know why? There is a reason for that choice. Spec had a real issue with that ordering, so the pressure will be to get it 'corrected'. Mind you, I consider Bloc a very good choice, but I fear that we're not able to stress it enough with hard, very advanced GUIs to ensure we're not loosing power compared to Morphic. Thierry Cheers Alain One of the issue with Morphic as it stands today is that the API is fairly complex if you want to carefully control placement and morph behavior under container resizing / move. Oh, and it's very buggy too. Rubricks shows an API which is even more complex, which isn't surprising if the inspiration is CSS layout. Thierry
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
On Wed, Mar 25, 2015 at 6:08 AM, Sean P. DeNigris s...@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
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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.
Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
---BeginMessage--- I don’t get it sorry. Padding by ten pixels to the left: | leftMargin aParserButton | leftMargin := Morph new width: 10; hResizing: #shrinkWrap; vResizing: #spaceFill. aParserButton := PluggableButtonMorph on: self getState: nil action: #parse. aParserButton hResizing: #spaceFill; vResizing: #shrinkWrap; label: 'Parse'. AlignmentMorph newRow vResizing: #shrinkWrap; hResizing: #spaceFill; layoutInset: 0; addMorph: aParserButton; addMorph: leftMargin; openInWorld Regarding this example, AlignmentMorph is a submorph of Morph with a layout policy. you can do the same with bloc. No time now but i will implement this example in my doc. Mind you, I consider Bloc a very good choice, but I fear that we're not able to stress it enough with hard, very advanced GUIs to ensure we're not loosing power compared to Morphic. yes, there is a risk, this is why we should progress carefully and not too fast thanks Alain ---End Message---
