February 2015 - Pharo-users

Re: [Pharo-users] pharo and ui again

by Nicolai Hess

2015-02-12 14:35 GMT+01:00 kilon alios <kilon.alios(a)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(a)dcc.uchile.cl> wrote: > >> >> On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)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 >> >> >

Feb. 12, 2015

[Job][Research] Inria Competitive selection 2015 : young graduate scientist ("CR2")

by Marcus Denker

Competitive selection 2015 : young graduate scientist ("CR2") Inria is launching a round of competitions to recruit seventeen young graduate scientists. Theses positions will be allocated as follows: two positions at Grenoble, Lille, Nancy, Rennes, Rocquencourt, Saclay and Sophia-Antipolis research centres and three positions at Bordeaux research centre. Registration conditions ================== Registration for the young graduate scientist competition begins on 26 January 2015. The following may apply: â¢ Holders of a doctorate or equivalent degree; â¢ Applicants able to prove publications and scientific work deemed equivalent. There are no age limits or nationality requirements for the recruitment of young graduated scientists. DEADLINE: ========= â¢ 20 February 2015: Deadline for downloading application files â¢ 23 February 2015: Deadline for submitting application files More information: http://www.inria.fr/en/institute/recruitment/offers/young-graduate-scientis…

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

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(a)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(a)dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>> wrote: > >> On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)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

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by kilon alios

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(a)dcc.uchile.cl> wrote: > > On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)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 > >

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

> On Feb 12, 2015, at 10:12, kilon alios <kilon.alios(a)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

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

> On Feb 12, 2015, at 07:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 12 Feb 2015, at 00:46, Nicolai Hess <nicolaihess(a)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

Feb. 12, 2015

Re: [Pharo-users] pharo and ui again

by Johan Fabry

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/PharoBookWorkInProgre… <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> - 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(a)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

Feb. 12, 2015

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

by Stephan Eggermont

Thanks Hilaire, that works fine. I can add the listener when the actual dragging starts and remove it on mouseUp. MDShape>>doDrag: aMouseMoveEvent with: aMDShape ActiveHand addEventListener: self. aMouseMoveEvent hand startDrag: aMouseMoveEvent with: aMDShape. MDShape>>handleListenEvent: anEvent anEvent isMouse ifFalse: [ ^self]. anEvent isMouseUp ifTrue: [ ActiveHand removeEventListener: self ]. anEvent isMouseMove ifTrue: [ self moved ] MDShape>>moved connectors do: [ :connector | connector moved ] Stephan

Feb. 12, 2015

Re: [Pharo-users] GSOC 2015 application

by Martin BÃ¤hr

Excerpts from stepharo's message of 2015-02-12 08:21:07 +0100: > we maintain one single list for pharo topics (related or not to GSOC) > I will not edit your item but you can do a pull request :) > https://github.com/pharo-project/pharo-project-proposals how can i preview changes i make? also it seems that http://topics.pharo.org/ is not being updated. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Feb. 12, 2015

Re: [Pharo-users] GSOC 2015 application

by Sebastian Sastre

nice! I've never heard about that before. Thanks for the heads up Stef! Added entries should go to the bottom or at the top? from mobile > On 12/02/2015, at 05:21, stepharo <stepharo(a)free.fr> wrote: > > Sebastian > > we maintain one single list for pharo topics (related or not to GSOC) > I will not edit your item but you can do a pull request :) > > https://github.com/pharo-project/pharo-project-proposals > > Stef > > Le 11/2/15 19:37, Sebastian Sastre a Ã©crit : >> Okay here comes some notes Iâve compiled: >> >> >> VOSS for Pharo >> http://voss.logicarts.com/ >> Implications: a completely object oriented database industry proven would have a legacy and a open sourced release empowering Pharo users and startups to stay object oriented even when persisting data. >> VOSS has dual license commercial and GPLv3, John, VOSS author already offered himself to mentor porters. >> https://www.linkedin.com/in/johnclapperton >> >> SQLServer client for Pharo >> Implications: some applications that have this dependency needs to extend and modernize features are challenged by this dependency that Pharo cannot use in a production ready state. >> >> SQL Alchemy for Pharo >> Implications: Big-data is a growing market that is easy to mine with a tool like Pythonâs SQL Alchemy. A Pharo version of such powerful tool would open this market opportunity for people wanting to offer Pharo-based solutions in this segment. Smalltalkâs syntax and tooling superiority could provide a significant push forward in this technology competitiveness because they might empower Pharo users to deliver solutions faster. >> http://www.sqlalchemy.org/ >> >> Remote Environments for Pharo >> Implications: being able to inspect, browse and debug reliably a server Pharo image from a client Pharo image would spark countless possibilities. Some of them: server maintenance; hot debug on GUI-less servers in production; live develop or debug remotely mobile devices that doesnât have a server. Hot changes in Pharo powered drones and robots. >> >> Pharo on mobile >> Implications: Is not that mobile is a growing market, is more like mobile is going supernova: http://a16z.com/2014/10/28/mobile-is-eating-the-world/ >> The power of Pharo and its libraries on mobile devices is currently perhaps one of its biggest opportunities. >> >> Deep learning for Pharo >> Implications: Robotics, drones and the internet of things will gather data from sensors that will need interpretation and modelling. All sorts of AI will use deep learning techniques and Pharo would be a great orchestrator of that modelling. >> http://www.quora.com/What-is-the-best-deep-learning-library-at-the-current-… >> >> Pharo Hadoop client >> Implications: Apache Hadoop can scale from single server to thousands of servers. The explosion of sensors, drones and mobile devices and printed devices with sensors are going to generate incredible amounts of data to process and model. Hadoop is a good fit for that and Pharo can empower faster modelling and orchestration of what to do with all that information stored in this widely adopted Hadoop technology. >> http://wiki.apache.org/hadoop/PoweredBy >> >> Cross platform Native Widgets for Pharo >> Implications: The web is fantastic but at the same time there is a big pressure to create great native applications due to the improved User Experience that the native widgets can provide. Making Pharo to create them via things like wxWidgets (https://www.wxwidgets.org/about/screenshots/) would instantly create opportunities to develop fast applications with a great UX. >> >> Protips site for Pharo >> Implications: I might spark the beginning of a mentoring ecosystem. StackOverflow is great but at the same time for a niche like Smalltalk it might not be enough to show the problem-solving potential of the platform. A site dedicated to share pro tips centered on Pharo would slowly a steady show the platformâs value. The site has to be social friendly. Each tip should have an author that can set there StackOverflow, LinkedIn, facebook, twitter or any social profile she wants. Requires nice branding and UX/UI design. Optional variation of the same idea: make it for any Smalltalk dialect instead of only Pharo. >> >> REPL IDE for Pharo >> Implications: Smalltalkers are used to very powerful IDEs. What if we have to put Pharo in a really underpowered or monitorless device? Having a powerful REPL IDE that can evaluate expressions, inspect and debug, would empower users to still do things in mini-devices during the incoming tide wave of internet-of-things. >> >> A GUI builder for Pharo >> Implications: If whatever you are doing you cannot make it visual easily, people cannot perceive it easily. Due to evolutionary reasons, our brain has unfair bias towards visual processing. Lets make something that allows Pharo to create visual things easier. Something like PARTS or Dolphin Smalltalk GUI builder would be huge. >> >> best! >> >> o/ >> >> >>> On Feb 11, 2015, at 12:14 PM, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: >>> >>> Excerpts from Stephan Eggermont's message of 2015-02-11 15:05:14 +0100: >>>> Sebastian wrote: >>>>> Can I brainstorm a wishlist? I could get wild on it :D >>>> >>>> Sure, as long as it is projects that you would be willing to mentor, >>>> and sized like they could fit. >>> >>> well, someone else could be willing to mentor then, so i don't think it hurts >>> to get wild on ideas, as long as accepted ideas come with a mentor. >>> >>> greetings, martin. >>> >>> -- >>> eKita - the online platform for your entire academic life >>> -- >>> chief engineer eKita.co >>> pike programmer pike.lysator.liu.se caudium.net societyserver.org >>> secretary beijinglug.org >>> mentor fossasia.org >>> foresight developer foresightlinux.org realss.com >>> unix sysadmin >>> Martin BÃ¤hr working in china http://societyserver.org/mbaehr/ >

Feb. 12, 2015