Hi again! Well, we had an other Software Smalltalk Night and we want to try to make a Smalltalk Kinect Fun project. It was pretty easy to conenct the Kinect camera with a Squeak For Scratch image. That enabled everybody to easily get going. Since a few days I try to prepare further steps and I must say,... I am completely lost in the UI frameworks. Let's have a simple example. A window with a title, 2 labels, 2 entry fields, one checkbox and 2 buttons. e.g. a login form for a Pharo application. We will need the parts, the layout, the events, the starting point as well as a result handler.... After 5 days I can tell ,that I am lost in Morphic, UIManager, Traits/No-Traits, Spec, GLMMorphic, Poly.... And sometimes things are even mixed up and I am not able to decide which approach to follow,... Some examples store widgets in instance variables, others initialize the morph based on the underlying model. MVC is sometimes mixed up... And this was just the topic parts and partially layout and events.... How does one open this login as an overlay, or as temporary replacement for the main content.... Â I tried Spec, but somehow it is much more difficult to get a proper functioning layout that behaves mature during resize and such events than expected. Is it possible to take a more Squeakish approach and just instantiate ui components compose them, define handler/callback symbols in those instances and then generate a specification/code out of this? Can anybody please point me at a full documentation on how to do things properly? There are many examples for the widgets but there is not a single example on how to built a real framework based on MVC in Pharo. Well and unfortunately a lot of stuff is outÃdated already. I somehow have the feeling that one and the same thing was implemented over and over again. I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I feel like the UI development removes all the productivity that one usually has with Smalltalk. I'd like to provide the interested locals here with a bsic implementation that they will be able to extend or go on with. But I do not want to invest time into not supported things. Thank you for any hint again! Sebastian
2015-02-11 23:28 GMT+01:00 Sebastian Heidbrink <sheidev@yahoo.de>:
Hi again!
Well, we had an other Software Smalltalk Night and we want to try to make a Smalltalk Kinect Fun project. It was pretty easy to conenct the Kinect camera with a Squeak For Scratch image. That enabled everybody to easily get going.
Since a few days I try to prepare further steps and I must say,... I am completely lost in the UI frameworks.
Let's have a simple example.
A window with a title, 2 labels, 2 entry fields, one checkbox and 2 buttons. e.g. a login form for a Pharo application. We will need the parts, the layout, the events, the starting point as well as a result handler.... After 5 days I can tell ,that I am lost in Morphic, UIManager, Traits/No-Traits, Spec, GLMMorphic, Poly....
a quick example (based on the code from class WidgetExamples) http://ws.stfx.eu/PXC188LWWWBN it is just an example and of course you need to wire up all the widget controls (textfield/checkbox) with your model. With spec this is easy too. But this kind of dialogs (request dialog, alert dialog, choose from a list dialog) are so common, that we really should build a small widget library, otherwise every developer builds his own spec models.
And sometimes things are even mixed up and I am not able to decide which approach to follow,... Some examples store widgets in instance variables, others initialize the morph based on the underlying model. MVC is sometimes mixed up... And this was just the topic parts and partially layout and events.... How does one open this login as an overlay, or as temporary replacement for the main content....
I tried Spec, but somehow it is much more difficult to get a proper functioning layout that behaves mature during resize and such events than expected. Is it possible to take a more Squeakish approach and just instantiate ui components compose them, define handler/callback symbols in those instances and then generate a specification/code out of this?
Can anybody please point me at a full documentation on how to do things properly?
I wish there was something like this. We have some spec docs at http://spec.st/ there are many resources for morphic at http://wiki.squeak.org/squeak/morphic But much howtos or tutorials widely scattered and aren't up to date. The best thing you can do is look at the examples (and tools) in the image ask in this mailng list write about your progress and experience! ( Help others who may have the same questions).
There are many examples for the widgets but there is not a single example on how to built a real framework based on MVC in Pharo.
Well and unfortunately a lot of stuff is outÃdated already. I somehow have the feeling that one and the same thing was implemented over and over again.
yes that is true.
I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I feel like the UI development removes all the productivity that one usually has with Smalltalk.
I'd like to provide the interested locals here with a bsic implementation that they will be able to extend or go on with. But I do not want to invest time into not supported things.
Support = Someone has to invest the time. nicolai
Thank you for any hint again! Sebastian
On Feb 12, 2015, at 07:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 12 Feb 2015, at 00:46, Nicolai Hess <nicolaihess@web.de> wrote:
But much howtos or tutorials widely scattered and aren't up to date.
Johan Fabry's talk at the Pharo Days was an excellent introduction to Spec, watch it.
Well, thank you very much for the recommendation :-). Are the videos of the talks online? I did not see an announcement for that, and Iâd like to see some of the talks I missed on Friday due to being stuck in the Douai snow ... ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
BTW, Johan, I cannot find your slides in http://www.slideshare.net/pharoproject/presentations ?
On 12 Feb 2015, at 13:45, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 12, 2015, at 07:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 12 Feb 2015, at 00:46, Nicolai Hess <nicolaihess@web.de> wrote:
But much howtos or tutorials widely scattered and aren't up to date.
Johan Fabry's talk at the Pharo Days was an excellent introduction to Spec, watch it.
Well, thank you very much for the recommendation :-). Are the videos of the talks online? I did not see an announcement for that, and Iâd like to see some of the talks I missed on Friday due to being stuck in the Douai snow ...
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
On 12 Feb 2015, at 17:53, Sven Van Caekenberghe <sven@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â¦
On 12 Feb 2015, at 13:45, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 12, 2015, at 07:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 12 Feb 2015, at 00:46, Nicolai Hess <nicolaihess@web.de> wrote:
But much howtos or tutorials widely scattered and aren't up to date.
Johan Fabry's talk at the Pharo Days was an excellent introduction to Spec, watch it.
Well, thank you very much for the recommendation :-). Are the videos of the talks online? I did not see an announcement for that, and Iâd like to see some of the talks I missed on Friday due to being stuck in the Douai snow ...
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
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@inria.fr> wrote:
On 12 Feb 2015, at 17:53, Sven Van Caekenberghe <sven@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
Le 11/02/2015 23:28, Sebastian Heidbrink a écrit :
I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I feel like the UI development removes all the productivity that one usually has with Smalltalk.
You are pretty right. For a small UI project, the UI development can be high. For a bigger project, where the UI part represent a small fraction of the whole project, it is a different story as most of the development will be out of the UI land and will benefit from the Pharo productivity. This is what I experienced with DrGeo. By the way, before Polymorph, the situation was even worst. Did you look at the Polymorph example in the WidgetExamples class ? There are good starter. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
One note on the GUI situation of Pharo. The situation of Pharo is pretty much the same situation for most programming languages. I am coming from python and the situation is pretty much the same but scaled up to the size of the python community which is huge. So instead like pharo of having 6 or 7 GUIs frameworks , Python has hundreds. I will say 4 are the most popular, pyQT which wraps QT (and its alternative pyside) , wxPython (wraps wxWidgets) , pyGTK (wraps GTK) and tkinter (wraps tk gui api) . All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple, GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed. Pharo will follow and does follow a similar route. I am actually thinking of making my own GUI API since none seems to fit my needs or the way I like to work. In the end no generic solution will be able to beat a customized one. This is why we need fragmentation. On Thu, Feb 12, 2015 at 10:46 AM, Hilaire <hilaire@drgeo.eu> wrote:
Le 11/02/2015 23:28, Sebastian Heidbrink a écrit :
I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I feel like the UI development removes all the productivity that one usually has with Smalltalk.
You are pretty right. For a small UI project, the UI development can be high. For a bigger project, where the UI part represent a small fraction of the whole project, it is a different story as most of the development will be out of the UI land and will benefit from the Pharo productivity. This is what I experienced with DrGeo.
By the way, before Polymorph, the situation was even worst. Did you look at the Polymorph example in the WidgetExamples class ? There are good starter.
Hilaire
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
On Feb 12, 2015, at 10:12, kilon alios <kilon.alios@gmail.com> wrote:
All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,
GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed.
I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4. I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us. So how exactly are you going to convince 10 people to work on the GUI API of your choosing ? Are you going to pull out the argument that all theses APIs are doing more less the same thing ? Good luck convincing them. I will certainly not be one of them when the center of my philosophy is "the devil is in the details". All pharo developers may end up focusing on Spec for example will be enough reason for me to consider abandoning Pharo because I don't like Spec. Most likely I wont because I will find a way not to have to use it but you get my point. Coding is not there just to satisfy practical needs (because otherwise I would not even being using Pharo) its even more about personal taste , this is why we have tons of programming languages and even more libraries. Also the bigger the library it is the slower it moves because of backward compatibility and having to make happy a big user base. You want to add a new feature ? Sure can do . You dont like the general design ? Oops sorry you are out of luck. Personally I like Morphic, I heavily dislike Spec and the verdict is open for Bloc. I will have to use Bloc on a project to make up my mind but so far I have been told that Bloc is a work in progress in early stages. So for me the situation is crystal clear Morphic all the way and if I find something I don't like, subclass and improve. But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone. And I am glad they dont. But in any case I would not want to force my opinion on other people and instead I recognize that people want different things. So I definitely approve of many options and I also approve that pharo core developers try to make Pharo more modular to make it easier to mix different libraries together , I think that will be so awesome. On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 12, 2015, at 10:12, kilon alios <kilon.alios@gmail.com> wrote:
All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,
GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed.
I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4.
I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Kilon, itâs not nice of you to say that I have a problem. I have an opinion, not a problem. And Iâm saying that we have 4 developers at most, not 10.
On Feb 12, 2015, at 14:35, kilon alios <kilon.alios@gmail.com> wrote:
And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us.
So how exactly are you going to convince 10 people to work on the GUI API of your choosing ? Are you going to pull out the argument that all theses APIs are doing more less the same thing ? Good luck convincing them. I will certainly not be one of them when the center of my philosophy is "the devil is in the details".
All pharo developers may end up focusing on Spec for example will be enough reason for me to consider abandoning Pharo because I don't like Spec. Most likely I wont because I will find a way not to have to use it but you get my point.
Coding is not there just to satisfy practical needs (because otherwise I would not even being using Pharo) its even more about personal taste , this is why we have tons of programming languages and even more libraries. Also the bigger the library it is the slower it moves because of backward compatibility and having to make happy a big user base. You want to add a new feature ? Sure can do . You dont like the general design ? Oops sorry you are out of luck.
Personally I like Morphic, I heavily dislike Spec and the verdict is open for Bloc. I will have to use Bloc on a project to make up my mind but so far I have been told that Bloc is a work in progress in early stages. So for me the situation is crystal clear Morphic all the way and if I find something I don't like, subclass and improve.
But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone. And I am glad they dont. But in any case I would not want to force my opinion on other people and instead I recognize that people want different things.
So I definitely approve of many options and I also approve that pharo core developers try to make Pharo more modular to make it easier to mix different libraries together , I think that will be so awesome.
On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry@dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>> wrote:
On Feb 12, 2015, at 10:12, kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote:
All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,
GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed.
I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4.
I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own.
---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> <---
Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> PLEIAD lab - Computer Science Department (DCC) - University of Chile
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Dont we all have problems we try to find solutions for ? I find nothing wrong with that. You may think I try to insult you, I can assure you I am not that kind of person and I respect your opinion. I am curious are you going to be one of those 4 developers that will make contributions to Spec ? Or are you a Spec contributor already ? On Thu, Feb 12, 2015 at 4:01 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Kilon, itâs not nice of you to say that I have a problem. I have an opinion, not a problem.
And Iâm saying that we have 4 developers at most, not 10.
On Feb 12, 2015, at 14:35, kilon alios <kilon.alios@gmail.com> wrote:
And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us.
So how exactly are you going to convince 10 people to work on the GUI API of your choosing ? Are you going to pull out the argument that all theses APIs are doing more less the same thing ? Good luck convincing them. I will certainly not be one of them when the center of my philosophy is "the devil is in the details".
All pharo developers may end up focusing on Spec for example will be enough reason for me to consider abandoning Pharo because I don't like Spec. Most likely I wont because I will find a way not to have to use it but you get my point.
Coding is not there just to satisfy practical needs (because otherwise I would not even being using Pharo) its even more about personal taste , this is why we have tons of programming languages and even more libraries. Also the bigger the library it is the slower it moves because of backward compatibility and having to make happy a big user base. You want to add a new feature ? Sure can do . You dont like the general design ? Oops sorry you are out of luck.
Personally I like Morphic, I heavily dislike Spec and the verdict is open for Bloc. I will have to use Bloc on a project to make up my mind but so far I have been told that Bloc is a work in progress in early stages. So for me the situation is crystal clear Morphic all the way and if I find something I don't like, subclass and improve.
But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone. And I am glad they dont. But in any case I would not want to force my opinion on other people and instead I recognize that people want different things.
So I definitely approve of many options and I also approve that pharo core developers try to make Pharo more modular to make it easier to mix different libraries together , I think that will be so awesome.
On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 12, 2015, at 10:12, kilon alios <kilon.alios@gmail.com> wrote:
All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,
GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed.
I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4.
I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
2015-02-12 14:35 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us.
But you both agree on: "Pharo needs a GUI framework" , no?
But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone.
It is not the goal of Spec to replace Morphic.And "Spec or Bloc" is not the question. Spec without the UI elements is pretty useless.
On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 12, 2015, at 10:12, kilon alios <kilon.alios@gmail.com> wrote:
All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,
GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed.
I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4.
I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
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. On Thu, Feb 12, 2015 at 4:10 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-02-12 14:35 GMT+01:00 kilon alios <kilon.alios@gmail.com>:
And there lies your problem. You dont agree with me and I dont agree with you and the next guy wont agree with either of us.
But you both agree on: "Pharo needs a GUI framework" , no?
But there are many people out there that love Spec and Bloc may be proven an excellent replacement for Morphic who knows , we definitely wont know if everyone start focusing on Spec alone.
It is not the goal of Spec to replace Morphic.And "Spec or Bloc" is not the question. Spec without the UI elements is pretty useless.
On Thu, Feb 12, 2015 at 2:51 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 12, 2015, at 10:12, kilon alios <kilon.alios@gmail.com> wrote:
All of the above frameworks have tons of users so one thing that this shows us is that fragmentation is really beneficial to a community. The reason is simple,
GUI is so complex subject but there will never be one ring to rule them all. Many have tried, all of them have failed.
I donât agree. If we would have more than 10 developers working on GUI frameworks in Pharo this may be the case. But we donât have this number. If we are very lucky we may have 4.
I would rather have 4 persons pulling a large cart in the same direction, instead of 4 of them pulling their own cart (1/4th the size) in more-or-less the same direction (if at all) as the other guys. In the first case a lot more progress will be made. If there is something wrong with the cart, fix it! Do not waste all this time building your own.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
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@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
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@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@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
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@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
Hi Sebastian, Iâm on holiday, so I will be brief with my replies, I hope you understand ;-) Spec is the official way to go for building UIs in Pharo: - With Spec you can write your example in 30 minutes, it just needs 1 class with 4 instvars and 3 short methods. - Most advanced documentation is a work in progress that is online here: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres...> - The interested locals should be able to continue working on that without too many issues. (send asSpecAdapter. to the morph) - If there is no Spec widget (ComposableModel subclass) for what you want to do, you can compose Morphs as well. If you have specific issues with layout behaviors in Spec please report them on the mailing list so we are aware / we may propose solutions. Success!
On Feb 11, 2015, at 23:28, Sebastian Heidbrink <sheidev@yahoo.de> wrote:
Hi again!
Well, we had an other Software Smalltalk Night and we want to try to make a Smalltalk Kinect Fun project. It was pretty easy to conenct the Kinect camera with a Squeak For Scratch image. That enabled everybody to easily get going.
Since a few days I try to prepare further steps and I must say,... I am completely lost in the UI frameworks.
Let's have a simple example.
A window with a title, 2 labels, 2 entry fields, one checkbox and 2 buttons. e.g. a login form for a Pharo application. We will need the parts, the layout, the events, the starting point as well as a result handler.... After 5 days I can tell ,that I am lost in Morphic, UIManager, Traits/No-Traits, Spec, GLMMorphic, Poly.... And sometimes things are even mixed up and I am not able to decide which approach to follow,... Some examples store widgets in instance variables, others initialize the morph based on the underlying model. MVC is sometimes mixed up... And this was just the topic parts and partially layout and events.... How does one open this login as an overlay, or as temporary replacement for the main content....
I tried Spec, but somehow it is much more difficult to get a proper functioning layout that behaves mature during resize and such events than expected. Is it possible to take a more Squeakish approach and just instantiate ui components compose them, define handler/callback symbols in those instances and then generate a specification/code out of this?
Can anybody please point me at a full documentation on how to do things properly? There are many examples for the widgets but there is not a single example on how to built a real framework based on MVC in Pharo. Well and unfortunately a lot of stuff is outÃdated already. I somehow have the feeling that one and the same thing was implemented over and over again.
I honestly try to bring Pharo/Smalltalk to the crowd, but somhow I feel like the UI development removes all the productivity that one usually has with Smalltalk.
I'd like to provide the interested locals here with a bsic implementation that they will be able to extend or go on with. But I do not want to invest time into not supported things.
Thank you for any hint again! Sebastian
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
participants (7)
-
Hilaire -
Johan Fabry -
kilon alios -
Marcus Denker -
Nicolai Hess -
Sebastian Heidbrink -
Sven Van Caekenberghe