- Pharo-users - lists.pharo.org

Re: [Pharo-users] Getting notified when a morph moves

by Hilaire

Le 12/02/2015 17:12, Stephan Eggermont a Ã©crit : > Hilaire wrote: >> Okay if I understand correctly, the two morphs you want to link with a >> line are also morphs of yours? So you can mangle into them. I was >> supposing the two morphs to link could be arbitrary ones, i.e. ones you >> can't modify. > I am trying to get a better understanding of Morphic by writing a > small drawing editor suitable for a tutorial. > > current state: > http://smalltalkhub.com/#!/~StephanEggermont/MorphicDraw/ > > Stephan > > Nice :) You may find some useful information in the collaboractive book in the Morph chapter http://pharo.gemtalksystems.com Hilarie -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Sebastian Heidbrink

Hi! Well, I never understood that decision but the SushiStore was once removed from the Seaside repository. But it might be stil lavailable here: http://www.squeaksource.com/SeasideExamples.html have a look under Store. It was also used by James Foster while he did his tutorials for Seaside on Gemstone/Glass. So ther emight be a version here. http://seaside.gemtalksystems.com/ss/GemStoneExamples.html But I have no idea how outdated they are. I just remebered the shift centermouse button ui context menu access. (on Windows) I took these screenshots from a Pharo 4 image: Click the red menu button and you get: There you have all the menus to manipulate the look and feel of your morphic. Unfortunately the export to .morp files seems to be no more available in Pharo http://wiki.squeak.org/squeak/2236 I wonder if one could introduce a export to Spec ... I think it would be easy enoug for prototyping to just create a ui with this. The only thing missing would be a menu entry that allows to select events and add according announment symbols... and the receivers... It is all there for rapid protoyping it seems but is is not hooked up somehow. 20 minutes for a login screen with Spec is not yet competitive but especially if I need to know it first to be able to make it in 20 minutes... Thank you for the document link. I am already reading it. Sebastian Am 12.02.2015 um 10:53 schrieb Johan Fabry: > Some restricted comments inline > >> On Feb 12, 2015, at 17:15, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: >> >> I think there is most stuff out there in Pharo that is needed to built a nice UI with Model interaction. >> It took me jsut a few hours to built a nice Glamour based data model browser. >> So why do I struggle to built a login view?! >> I think this is because Glamour is its own example.... It is implemented in one way and there are few distractions. > Glamour is excellent! But only as long as you want to do something that fits the overall philosophy of it. Thatâs the advantages and the disadvantages of a domain-specific solution. Spec is a general-purpose solution. > > Your login UI should be able to be built in Spec in less than 20 minutes. (Supposing it is more or less like a traditional login UI). > >> What Pharo needs and I do not think that this is a too huge task is. >> A clear destiction of M, V and C accomplished by ClassNamingConvertions and package sub-division of these. >> A browser that just lists all the available basic morphs and their examples > Browse the hierarchy of ComposableModel and you have all the Spec widgets and UIs that are in the image. > >> A sushi store demo according to the current Pharo release. > I donât know this example, can you give a link to an example app? > >> A clear documentation what, Spec, Polymorph, Morphic,... are representing and on which "layer" they are positioned. OS-Layer, Common-Layer, Layout-Layer, Event-Layer. > Have a look at the Spec book chapter (in progress). It also relates the position of Spec with respect to Morphic https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… > > [â¦] > >> So and now her eis the question that I think needs to be discussed since it is the most controversial answered to me. >> "Spec or not to Spec?" >> >> I am kidding! >> But my current counter is 5 for Spec and 5 against Spec. >> I think some rason could be that Spec is misunderstood, or still under development/inmature. >> I can't tell, but a beginner wants to know: >> "WHAT AM I SUPPOSED TO DO!?" > To answer your BIG QUESTION ;-) Read the book chapter that I linked to above, or at least the first few sections, and try to build the login UI with Spec. Then you will have better information that can serve to make a choice for or against your use of Spec. > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

Feb. 12, 2015

Re: [Pharo-users] recover lost changes

by Ben Coman

On Fri, Feb 13, 2015 at 2:30 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > no. > in the best case it will be in pharo4 as preview. > (to remove/disable the old mechanism is going to take more time and > complicationsâ¦) > Isn't that what I said? :) Since both are tools selected from the method, they would really be on equal footing wrt priority. cheers -ben > > On 12 Feb 2015, at 18:07, Ben Coman <btc(a)openInWorld.com> wrote: > > So is the plan to integrate Epicea for Pharo 4 Release as the default > mechanism, and leave removal of the existing mechanism until Pharo 5? > cheers -ben > > On Fri, Feb 13, 2015 at 12:44 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> > On 12 Feb 2015, at 17:36, Ben Coman <btc(a)openInWorld.com> wrote: >> > >> > Is Epicea able to run parallel with the exiting changes framework, do >> we have to rip the latter out first? >> >> I works in parallel now. The idea is to remove the other mechanism in a >> second step. >> >> Marcus >> >> >> > >

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

Kilon, I repeat and paraphrase from my previous mail: In the end, you never clearly stated why you donât like Spec. You did not provide any more concrete information except that your taste is different. So please, instead of saying âI donât like Xâ clarify exactly what it is that you donât like and why. Otherwise there will never be advances and itâs annoying to hear the same vague complaints all over again â¦ > On Feb 12, 2015, at 19:46, kilon alios <kilon.alios(a)gmail.com> wrote: > > If Spec was what imagine the ideal GUI API to be then I would certainly love it to death. But thats besides the point , I have already explained what I dont like about Spec in another thread as you already mentioned. You cannot debate personal taste, sure you can clear misconceptions but in then end personal taste goes a lot deeper than that. There will be people who love Spec and people who hate it, and the rest will be somewhere in the between. You claimed how harmful is for Pharo to have a fragmentation for GUI APIs , I expressed the opposite opinion , its not as if we will agree in the end. We wont, we are clearly two people with different philosophies. For you reimplementing/reinventing the wheel is a waste of time, for me its the source of the human intelligence. Also I find reinventing the wheel a great way to learn the inner mechanics of the wheel and gain a deeper understanding. > > You dont need my approval to move Spec forward nor my permission. You will do just fine without me and I sincerely hope you find those 4 developers and move Spec light years ahead. I dont promise to like it but I will definitely keep an open mind and follow your progress. Who knows maybe one day I may be one of those 4 developers or even many more. But in the end I hope people never polarise on specific libraries and keep coming up with new fresh ideas and approaches even on the same problems. GTSpotter is one such example that has been a great addition to my workflow. > > And its not as if Spec is the only thing I dont like in Pharo. I dont like the design of new Playground and Inspector at least some parts of it I have already mentioned in other threads. I hated the white theme and I am glad I have no need to use it anymore. I dont like monticello GUI design. Auto completion is messy at times etc etc. I am sure other Pharo developers have their own likes and dislikes. > > PS: I did not complain about Spec, I only said that I don't like it and in the context of explaining why we need alternative solutions for GUI creation, or at least why I need them. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

Some restricted comments inline > On Feb 12, 2015, at 17:15, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > I think there is most stuff out there in Pharo that is needed to built a nice UI with Model interaction. > It took me jsut a few hours to built a nice Glamour based data model browser. > So why do I struggle to built a login view?! > I think this is because Glamour is its own example.... It is implemented in one way and there are few distractions. Glamour is excellent! But only as long as you want to do something that fits the overall philosophy of it. Thatâs the advantages and the disadvantages of a domain-specific solution. Spec is a general-purpose solution. Your login UI should be able to be built in Spec in less than 20 minutes. (Supposing it is more or less like a traditional login UI). > What Pharo needs and I do not think that this is a too huge task is. > A clear destiction of M, V and C accomplished by ClassNamingConvertions and package sub-division of these. > A browser that just lists all the available basic morphs and their examples Browse the hierarchy of ComposableModel and you have all the Spec widgets and UIs that are in the image. > A sushi store demo according to the current Pharo release. I donât know this example, can you give a link to an example app? > A clear documentation what, Spec, Polymorph, Morphic,... are representing and on which "layer" they are positioned. OS-Layer, Common-Layer, Layout-Layer, Event-Layer. Have a look at the Spec book chapter (in progress). It also relates the position of Spec with respect to Morphic https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… [â¦] > So and now her eis the question that I think needs to be discussed since it is the most controversial answered to me. > "Spec or not to Spec?" > > I am kidding! > But my current counter is 5 for Spec and 5 against Spec. > I think some rason could be that Spec is misunderstood, or still under development/inmature. > I can't tell, but a beginner wants to know: > "WHAT AM I SUPPOSED TO DO!?" To answer your BIG QUESTION ;-) Read the book chapter that I linked to above, or at least the first few sections, and try to build the login UI with Spec. Then you will have better information that can serve to make a choice for or against your use of Spec. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by kilon alios

If Spec was what imagine the ideal GUI API to be then I would certainly love it to death. But thats besides the point , I have already explained what I dont like about Spec in another thread as you already mentioned. You cannot debate personal taste, sure you can clear misconceptions but in then end personal taste goes a lot deeper than that. There will be people who love Spec and people who hate it, and the rest will be somewhere in the between. You claimed how harmful is for Pharo to have a fragmentation for GUI APIs , I expressed the opposite opinion , its not as if we will agree in the end. We wont, we are clearly two people with different philosophies. For you reimplementing/reinventing the wheel is a waste of time, for me its the source of the human intelligence. Also I find reinventing the wheel a great way to learn the inner mechanics of the wheel and gain a deeper understanding. You dont need my approval to move Spec forward nor my permission. You will do just fine without me and I sincerely hope you find those 4 developers and move Spec light years ahead. I dont promise to like it but I will definitely keep an open mind and follow your progress. Who knows maybe one day I may be one of those 4 developers or even many more. But in the end I hope people never polarise on specific libraries and keep coming up with new fresh ideas and approaches even on the same problems. GTSpotter is one such example that has been a great addition to my workflow. And its not as if Spec is the only thing I dont like in Pharo. I dont like the design of new Playground and Inspector at least some parts of it I have already mentioned in other threads. I hated the white theme and I am glad I have no need to use it anymore. I dont like monticello GUI design. Auto completion is messy at times etc etc. I am sure other Pharo developers have their own likes and dislikes. PS: I did not complain about Spec, I only said that I don't like it and in the context of explaining why we need alternative solutions for GUI creation, or at least why I need them. On Thu, Feb 12, 2015 at 7:57 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > Kilon, your second paragraph can be understood as a description of Spec. > There is a low level code and an extensions API, and ALL widgets are > implemented as such extensions and you can assemble a GUI framework. What > you propose as your ideal solution is reimplementing this wheel all over > again. > > In the end, you never clearly stated why you donât like Spec. I mean, > beyond the questions that I provided you an answer for some time ago. So > please, instead of saying âI donât like Xâ clarify exactly what it is that > you donât like and why. Otherwise there will never be advances and itâs > annoying to hear the same vague complaints all over again ... > > On Feb 12, 2015, at 15:28, kilon alios <kilon.alios(a)gmail.com> wrote: > > Frankly big libraries dont make much sense for me when it comes to Pharo. > Sure if we were talking about Python I would say yes. I do believe however > that Pharo makes it already very easy to combine libraries together. > > So for me the ideal solution would be a very low level core that comes > with very well documented extensions API and then widgets are implemented > as third party extensions that will allow you to assemble a GUI framework > tailor made to your own needs. Unfortunately making such a complex core > will require quite some effort . So my idea is not without its own > problems. > > So I would have to say no , I dont agree, at least I think we imagine > very different things. > > The goal of Spec may not be to replace Morphic but then the goal of the > human race was not to go to the moon until one day scientists told us its > possible. The same can happen with Spec, keep improving it , extending it > and people will keep using it more and more in place of Morphic even if > Spec still keeps relying in Morphic. Afterall its not difficult to > imagine Spec one day in the distant future coming with its own backend. > None can predict the future afterall, even if you invent it (sorry Alan). > But then this what makes future so exciting , its unpredictable nature. > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 12, 2015

Re: [Pharo-users] recover lost changes

by Esteban Lorenzano

no. in the best case it will be in pharo4 as preview. (to remove/disable the old mechanism is going to take more time and complicationsâ¦) cheers, Esteban > On 12 Feb 2015, at 18:07, Ben Coman <btc(a)openInWorld.com> wrote: > > So is the plan to integrate Epicea for Pharo 4 Release as the default mechanism, and leave removal of the existing mechanism until Pharo 5? > cheers -ben > > On Fri, Feb 13, 2015 at 12:44 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > > > On 12 Feb 2015, at 17:36, Ben Coman <btc(a)openInWorld.com> wrote: > > > > Is Epicea able to run parallel with the exiting changes framework, do we have to rip the latter out first? > > I works in parallel now. The idea is to remove the other mechanism in a second step. > > Marcus > > >

Feb. 12, 2015

Re: [Pharo-users] GSOC 2015 application

by Ben Coman

On Thu, Feb 12, 2015 at 4:02 PM, stepharo <stepharo(a)free.fr> wrote: > Me and Damien did a pass on them yesterday. > If people have projects that they want to mentor during GSOC or not they > can pull request on github pharo-project-.... > > Stef > > > Le 11/2/15 16:26, Ben Coman a Ã©crit : > > >> >> btw, Are all of these topics [http://topics.pharo.org/] still current >> (maybe some are too big for summer)? >> > > Hi Stef, Having the page title "Pharo Bachelor and Master Topics" is a little uninviting for a short program like GSoC. Might this be changed to something like "Pharo Topics" - with Bachelor & Masters mentioned underneath along with GSoC. Later perhaps links to additional sponsored-coding events could be added (anyone know of any?) Or otherwise might we have a gsoc.pharo.org with a different title but drawing from the same list ? cheers -ben

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

In any case, my slides are pretty useless without me giving the complete song and dance routine as well ;-) Best to see them together with the video ... > On Feb 12, 2015, at 17:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 12 Feb 2015, at 17:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> BTW, Johan, I cannot find your slides in http://www.slideshare.net/pharoproject/presentations ? >> > I have the .key files.. I will double check and upload the missingsâ¦ > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

Kilon, your second paragraph can be understood as a description of Spec. There is a low level code and an extensions API, and ALL widgets are implemented as such extensions and you can assemble a GUI framework. What you propose as your ideal solution is reimplementing this wheel all over again. In the end, you never clearly stated why you donât like Spec. I mean, beyond the questions that I provided you an answer for some time ago. So please, instead of saying âI donât like Xâ clarify exactly what it is that you donât like and why. Otherwise there will never be advances and itâs annoying to hear the same vague complaints all over again ... > On Feb 12, 2015, at 15:28, kilon alios <kilon.alios(a)gmail.com> wrote: > > Frankly big libraries dont make much sense for me when it comes to Pharo. Sure if we were talking about Python I would say yes. I do believe however that Pharo makes it already very easy to combine libraries together. > > So for me the ideal solution would be a very low level core that comes with very well documented extensions API and then widgets are implemented as third party extensions that will allow you to assemble a GUI framework tailor made to your own needs. Unfortunately making such a complex core will require quite some effort . So my idea is not without its own problems. > > So I would have to say no , I dont agree, at least I think we imagine very different things. > > The goal of Spec may not be to replace Morphic but then the goal of the human race was not to go to the moon until one day scientists told us its possible. The same can happen with Spec, keep improving it , extending it and people will keep using it more and more in place of Morphic even if Spec still keeps relying in Morphic. Afterall its not difficult to imagine Spec one day in the distant future coming with its own backend. None can predict the future afterall, even if you invent it (sorry Alan). But then this what makes future so exciting , its unpredictable nature. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 12, 2015