- Pharo-dev - lists.pharo.org

Re: [Pharo-project] What is the future of GUI in Pharo?

by Igor Stasenko

On 25 March 2011 12:12, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Thu, Mar 24, 2011 at 4:33 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: >> >> Isn't there some kind of "Ideas" page yet? Would also be useful for GSoC, >> etc. > > http://code.google.com/p/pharo/wiki/IdeasToImplement > > but I guess it is quite outdated > Yes. But it would be nice to annotate this page and see and compare where we are now. >> >> 2011/3/24 Igor Stasenko <siguctua(a)gmail.com> >>> >>> Stef, put that on wiki, or somewhere else, so we can read it later :) >>> >>> I like Grand Plans.. especially if they are succeed :) >>> >>> On 24 March 2011 09:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> > Here is the vision: we need it better and simpler with better widgets, >>> > better UIBuilder and better tools. >>> > if you give me some engineers I can build something clear, now this is >>> > not the case so we are exploring and multiple paths >>> > Now if you want to see the system moving faster just join and help >>> > >>> > So here is a list >>> > >>> > Frameworks >>> > ---------- >>> > First step >>> > Â Â Â Â - Integrate polymorph (move class to the right packages, remove >>> > overrides) >>> > Â Â Â Â - Reduce complexity of morphic when possible >>> > >>> > In parallel >>> > Â Â Â Â - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) >>> > Â Â Â Â - Based on SimpleMorphic, clean also Morphic >>> > >>> > Alain told me that he want to take simpleMorphic and create a kernel >>> > that can be run and debugged on the side >>> > or morphic. Then he wants to add list and tree and see if he can add a >>> > better version of polymorph. >>> > Now he can fail too. so this is why the incremental points are >>> > important. >>> > >>> > Fixing and improving announcements is important >>> > Â Â Â Â - It was done during the last sprint >>> > Â Â Â Â - We were discussing how to make anonucement faster to avoid to >>> > climbing their parent tree - but no success so far. >>> > Â Â Â Â - Â We evaluated signals (as used in HPI frameworks) and we do >>> > not really like it. The use of thisContext is probably a problem among >>> > others. >>> > >>> > Widgets >>> > ------- >>> > We need better widgets >>> > Â Â Â Â - accordion >>> > Â Â Â Â - better text >>> > Â Â Â Â - grid >>> > Â Â Â Â We should evaluate your widgets to integrate them. But first we >>> > should clean what is there. >>> > Â Â Â Â Stacking on top of bad foundation just make the system more >>> > complex and difficult to maintain. >>> > >>> > >>> > Low level: a new Canvas and clean event >>> > ----------------------------------- >>> > Â Â Â Â Igor started to design a new canvas called Athens and we will >>> > see where it will go >>> > Â Â Â Â Again if people want to see this coming faster, they should >>> > help. >>> > Â Â Â Â The idea is to have a canvas for >>> > Â Â Â Â Â Â Â Â - opengl >>> > Â Â Â Â Â Â Â Â - cairo >>> > Â Â Â Â Â Â Â Â - bitbl >>> > >>> > Â Â Â Â We are evaluating the event hierarchy designed by Mickael Rueger >>> > and we would like >>> > Â Â Â Â to integrate it: eliminate the floating of arrays btween >>> > eventfetcher and HandMorph >>> > Â Â Â Â the idea is that event should be emitted by eventSensor not raw >>> > array >>> > >>> > Â Â Â Â I'm starting to clean Sensor references that are using the >>> > polling behavior because we should not have polling anymore >>> > Â Â Â Â the Windows virtual machine should be fixed and get the >>> > enhancement that Igor sent more than a year ago for the input semaphore >>> > Â Â Â Â and so that all the vm are aligned. >>> > >>> > >>> > Tools >>> > ----- >>> > Â Â Â Â We are rewriting from scratch the basic tools >>> > Â Â Â Â Â Â Â Â - Browser (Nautilus soon to be announced - with groups, >>> > package browsers, refactorings, may be plugin architecture) >>> > Â Â Â Â Â Â Â Â - Finder >>> > Â Â Â Â Â Â Â Â - TestRunner (soon) >>> > Â Â Â Â Â Â Â Â - MCBrowser >>> > Â Â Â Â Â Â Â Â - Debugger (waiting for a debugger model) >>> > Â Â Â Â The idea is that we want to kill the StringHolder hierarchy >>> > alltogther so in a first phase we will probably have to keep it >>> > Â Â Â Â for the debugger but only for it. >>> > >>> > Â Â Â Â We will remove toolBuilder (we are waiting to finish the >>> > TestRunner rewriting). >>> > >>> > Â Â Â Â Glamour will probably be used as a default super IDE of the >>> > future but it depends on people >>> > Â Â Â Â We are currently working on the fall back (the tools when you >>> > have nothing). >>> > >>> > So I hope it clarifies the picture and you are welcome to help. Now an >>> > important point >>> > This is not because something is under preparation that the other >>> > should not get clean and improve. >>> > We have no problem throwing away our effort if something better come up >>> > but we should be prepared that nothing come up or is delayed >>> > this is why we have this parallel strategy. >>> > >>> > >>> > Stef >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >> Many new things is happens this days on Pharo, and I donÂ´t understand >>> >> the >>> >> status of all. >>> >> >>> >> What is the future of GUI in Pharo? what changes will happen? which is >>> >> the >>> >> roadmap? Â Now I see SimpleMorphic. Pharo will work with it? Pharo will >>> >> works >>> >> with another way of draw/render the morphs? >>> >> We will reduce the number of morph classes and hierarchy? The Morphic >>> >> UI >>> >> designer will be incorporated in dev image? >>> >> >>> >> Thanks for your answers. >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Dennis Schetinin > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] pharo closures

by Stefan Marr

Hi: On 25 Mar 2011, at 11:01, Toon Verwaest wrote: > If you really win a lot of performance by doing so, this is justified (although I would still give it a different class than just Array ;)). I'm just trying to find out if that performance boost is really there. But I'm going to take this offline I think not to pollute the whole mailing list with our circular conversations, and I'll report back if we figure something interesting out ;) Well, for what it is worth, I really enjoy such discussions. And they are much more than all the usual ones here on the list ;) If you do not feel that the Pharo mailing list is the right place, there is always an almost unused smalltalk research mailing list... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 25, 2011

Re: [Pharo-project] Issue 3863 in pharo: packages cleanup needed

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3863 by marcus.d...(a)gmail.com: packages cleanup needed http://code.google.com/p/pharo/issues/detail?id=3863 in 13109

March 25, 2011

Re: [Pharo-project] GUIs with Pharo / how to learn smalltalk

by Igor Stasenko

On 25 March 2011 06:48, Daniel Lyons <fusion(a)storytotell.org> wrote: > Hi, > > I have two questions, a technical one and a more general one. > > In broad strokes, what are people doing for GUIs? My guess would be using Morphic, but googling around you find more abuse than use, it looks like, and very little live links to up-to-date documentation. It makes me wonder: is there something other than Morphic which is being used? Or is everyone doing web apps? Or is there some other GUI toolkit I haven't found yet, and that's where all the action is? Whenever I see a neat Morphic window or something, I feel a bit like there's a party going on somewhere and I didn't get an invitation. Like the first rule of Morphic club is you don't talk about Morphic club. > > The general question I have is basically, am I the problem? Is it that the documentation isn't where I expect to find it, or in the form I'm used to seeing, or that it isn't relevant somehow in the Smalltalk universe? Or is it all really intuitive except for me? :) I could accept that, I suppose, but how did you Smalltalk wizards become wizards? Did you just dive in and start reading the code in your own image? in most cases. And reading mailing lists , asking questions .. >Was there some master Smalltalk wizard that you knew who showed you how to do these things? Just ask questions, read answers. It works here. :) Our community is quite inviting to newcomers and we help each other. That's what i discovered when i first came to squeak community (Pharo was not formed at those days). >I'm currently reading Smalltalk Best Practice Patterns and it's one of the best programming books I've ever read. I see that there is a great deal of mastery of programming going around in Smalltalk circles, but I don't see the books that take you past beginner towards master, other than SBPP. So what's the trick going on here? How did you guys become excellent? > By reading code and writing code, exchanging ideas and communicating :) > I hope none of this comes across as negative; I think surely it's that I'm missing something. > > Thanks, > > â > Daniel Lyons > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by Mariano Martinez Peck

On Thu, Mar 24, 2011 at 4:33 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > Isn't there some kind of "Ideas" page yet? Would also be useful for GSoC, > etc. http://code.google.com/p/pharo/wiki/IdeasToImplement but I guess it is quite outdated > > > 2011/3/24 Igor Stasenko <siguctua(a)gmail.com> > >> Stef, put that on wiki, or somewhere else, so we can read it later :) >> >> I like Grand Plans.. especially if they are succeed :) >> >> On 24 March 2011 09:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> > Here is the vision: we need it better and simpler with better widgets, >> better UIBuilder and better tools. >> > if you give me some engineers I can build something clear, now this is >> not the case so we are exploring and multiple paths >> > Now if you want to see the system moving faster just join and help >> > >> > So here is a list >> > >> > Frameworks >> > ---------- >> > First step >> > - Integrate polymorph (move class to the right packages, remove >> overrides) >> > - Reduce complexity of morphic when possible >> > >> > In parallel >> > - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) >> > - Based on SimpleMorphic, clean also Morphic >> > >> > Alain told me that he want to take simpleMorphic and create a kernel >> that can be run and debugged on the side >> > or morphic. Then he wants to add list and tree and see if he can add a >> better version of polymorph. >> > Now he can fail too. so this is why the incremental points are >> important. >> > >> > Fixing and improving announcements is important >> > - It was done during the last sprint >> > - We were discussing how to make anonucement faster to avoid to >> climbing their parent tree - but no success so far. >> > - We evaluated signals (as used in HPI frameworks) and we do not >> really like it. The use of thisContext is probably a problem among others. >> > >> > Widgets >> > ------- >> > We need better widgets >> > - accordion >> > - better text >> > - grid >> > We should evaluate your widgets to integrate them. But first we >> should clean what is there. >> > Stacking on top of bad foundation just make the system more >> complex and difficult to maintain. >> > >> > >> > Low level: a new Canvas and clean event >> > ----------------------------------- >> > Igor started to design a new canvas called Athens and we will see >> where it will go >> > Again if people want to see this coming faster, they should help. >> > The idea is to have a canvas for >> > - opengl >> > - cairo >> > - bitbl >> > >> > We are evaluating the event hierarchy designed by Mickael Rueger >> and we would like >> > to integrate it: eliminate the floating of arrays btween >> eventfetcher and HandMorph >> > the idea is that event should be emitted by eventSensor not raw >> array >> > >> > I'm starting to clean Sensor references that are using the >> polling behavior because we should not have polling anymore >> > the Windows virtual machine should be fixed and get the >> enhancement that Igor sent more than a year ago for the input semaphore >> > and so that all the vm are aligned. >> > >> > >> > Tools >> > ----- >> > We are rewriting from scratch the basic tools >> > - Browser (Nautilus soon to be announced - with groups, >> package browsers, refactorings, may be plugin architecture) >> > - Finder >> > - TestRunner (soon) >> > - MCBrowser >> > - Debugger (waiting for a debugger model) >> > The idea is that we want to kill the StringHolder hierarchy >> alltogther so in a first phase we will probably have to keep it >> > for the debugger but only for it. >> > >> > We will remove toolBuilder (we are waiting to finish the >> TestRunner rewriting). >> > >> > Glamour will probably be used as a default super IDE of the >> future but it depends on people >> > We are currently working on the fall back (the tools when you >> have nothing). >> > >> > So I hope it clarifies the picture and you are welcome to help. Now an >> important point >> > This is not because something is under preparation that the other should >> not get clean and improve. >> > We have no problem throwing away our effort if something better come up >> but we should be prepared that nothing come up or is delayed >> > this is why we have this parallel strategy. >> > >> > >> > Stef >> > >> > >> > >> > >> > >> > >> > >> > >> >> Many new things is happens this days on Pharo, and I donÂ´t understand >> the >> >> status of all. >> >> >> >> What is the future of GUI in Pharo? what changes will happen? which is >> the >> >> roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will >> works >> >> with another way of draw/render the morphs? >> >> We will reduce the number of morph classes and hierarchy? The Morphic >> UI >> >> designer will be incorporated in dev image? >> >> >> >> Thanks for your answers. >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > -- > Dennis Schetinin >

March 25, 2011

[Pharo-project] Issue 3878 in pharo: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3878 by fernando...(a)gmail.com: #enableTextChange selector name is misleading, i propose changing the name to #canChangeText http://code.google.com/p/pharo/issues/detail?id=3878 It's sent by the TextEditor, to ask the morphs for permision to change the contents. Attachments: enableTextChange.1.cs 2.2 KB

March 25, 2011

Re: [Pharo-project] Brainstorming further out (was Re: What is the future of GUI in Pharo?)

by Janko MivÅ¡ek

Yep, most of what you described on HTML5 and Mobile front is already there or in planning/vision state in Aida land, together with Jtalk. I'm just preparing a "On the web frontiers.." submittion for ESUG talk about this, so guys please keep comming out with such ideas! Janko On 25. 03. 2011 09:37, GÃ¶ran Krampe wrote: > Hi all! > > <brainstorm> > I think we should think about what is happening out there with the new > explosion around two things: > > - Mobile apps > - HTML5 > > IT is changing, people are using pads and phones more than computers in > the very near future (or already). And HTML5 gives advanced capabilities > to play on these devices without having to buy the whole technical eco > system of them (on Android it is Dalvik and on iOS it is Objective-C > more or less). > > HTML5 is enabling stuff like ThinVNC for example (just google it). Or > endless mobile frameworks like Joapp.com etc. > > And then to top it off we have Google and it Nacl project (Native > client) which is basically a "sandboxed x86 environment" if I grokked it > correctly. > > I want to be able to develop systems in Pharo/Squeak that can reach > people on all these devices - of basically two flavors: > > - Typical mobile apps using webtech. For many of us - for maximum reach > and minimum "tie up" with any of these platforms I think the new web > solutions are the way to go. > > - Graphical apps that look exactly like I want (think games). > > How do we enable this? > > One way could be to create a fast "Morphic player" layer in js utilizing > HTML5 to talk back to a server side Squeak. Kinda like ThinVNC but > tailored for Morphic? > > Or even more crazy, what if one could sit in the debugger in Pharo and > "step into" code actually running inside the js engine in a browser, > seamless debugging and somehow also seamless access to the objects on > the js side? > > If someone here has seen how VW integrates with Gemstone (or perhaps > GLASS does the same now) - it is very seamless. > > In that "crazy vision" one obviously starts thinking of two roads: > > 1. Create a "Smalltalk" on top of js that we can "tether with". JTalk > perhaps? > > 2. Or perhaps it is even better to let js be js and instead make > Muhammed (=Pharo) come to the mountain (=the huge js eco system). Thus > we could create a low level tethering with Javascript and then make > Pharo "Javascript aware" on many levels, like inspectors, debugger, > browsers etc. > > ...hmmm, wow. Now that I am typing this the above #2 would be awesomely > cool. ;) > > Another more "conventional" way to capture #1 above is of course to > integrate Joapp or JQuery Mobile (Renggli already doing that I think) > with Seaside. > </brainstorm> > > regards, GÃ¶ran > > PS. Yes, this post didn't start with "I want to do X" but on the other > hand I am just brainstorming here, I am not saying anyone should do > *anything*. :) > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 25, 2011

Re: [Pharo-project] GUIs with Pharo / how to learn smalltalk

by Mariano Martinez Peck

About Morphic, I have a couple of links but probably are outdated: http://www.google.ch/url?sa=t&source=web&cd=4&ved=0CDEQFjAD&url=http%3A%2F%… morphic %20user%20interface&ei=QOGZTJafJImnON-LwewM&usg=AFQjCNGZCbShjz04JCkZwi6p5qcgSCD3gg&sig2=qpM75WlSGoQb-j4GYWv94w http://wiki.squeak.org/squeak/30 http://portal.acm.org/citation.cfm?id=215636 http://static.squeak.org/tutorials/morphic-tutorial-1.html http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic .final.pdf http://wiki.squeak.org/squeak/1820 (Morph) http://wiki.squeak.org/squeak/1285 (Morphic Architecture) http://www.elwedgo.de/fileadmin/events_in_smalltalk.pdf On Fri, Mar 25, 2011 at 10:19 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > About the "How to learn Morphic ?" point, there is a cool PharoCast that > shows basis > http://www.pharocasts.com/2011/02/pharo-gui-with-polymorph.html. > > About my own experience, I have learnt a bit by myself (RecentMessageList, > Finder) and then I have pair programmed with Alain during last ESUG and > learnt a lot :) > There is some stuff you can't guess because they are strange and a bit > disturbing (who said "layout" ? ^^), but then you can put some halt almost > everywhere (let me give you an advice, first create a subclass, then put a > halt ^^). > > But as said there is a lack of documentation, and I think than more > pharocast could be a good way to change this. And since we are cleaning the > system, I guess Morphic will come more and more understandable (I hope) ;) > > > I wish you good luck and I you have question do no hesitate :) > > > > Ben > > > > On Mar 25, 2011, at 9:06 AM, StÃ©phane Ducasse wrote: > > Hi Daniel > > I have two questions, a technical one and a more general one. > > > In broad strokes, what are people doing for GUIs? My guess would be using > Morphic, but googling around you find more abuse than use, it looks like, > and very little live links to up-to-date documentation. It makes me wonder: > is there something other than Morphic which is being used? Or is everyone > doing web apps? Or is there some other GUI toolkit I haven't found yet, and > that's where all the action is? Whenever I see a neat Morphic window or > something, I feel a bit like there's a party going on somewhere and I didn't > get an invitation. Like the first rule of Morphic club is you don't talk > about Morphic club. > > > Not really truth. :) Now we are cleaning the system and trying to make sure > that we understand it. > However it does not prevent you to learn. Look at Benjamin: (a smart second > year students), he built Finder and now he is building > Nautilus. Start by looking at some examples and ask for feedback. People > will help you. > Now this is clear that the documentation is not at the level it should be. > > The general question I have is basically, am I the problem? > > > No > > Is it that the documentation isn't where I expect to find it, or in the > form I'm used to seeing, or that it isn't relevant somehow in the Smalltalk > universe? > > > If you can VisualWorks there is a lot of documentation. > Now they have engineers too. > > Or is it all really intuitive except for me? :) > > > No I'm often puzzled too. The point is that I learn everyday more about the > system and when I do not like the way it is done > I try to fix it. My main goal is to learn every day. Sometimes this is > frustrating but in general it works. > > I could accept that, I suppose, but how did you Smalltalk wizards become > wizards? > > > I do not know. But probably starting to read > - mailing-list > - read the code > - break it by putting the wrong self halt at the wrong place > The cool aspect of Pharo is that it is really improving day after day. > And that when there is something ugly you can be sure that one of these > days we will fix it. Now we should go step by step. > > > Did you just dive in and start reading the code in your own image? > > > Yes. > When I started been an harvester for Squeak, here is what I did. > read the bug report (there was none so it was easy) > read the submitted code and if I do not understand pass to the next one > until I find something that I can understand > I still do that everyday. My goal is to have read a lot of the code. > > Was there some master Smalltalk wizard that you knew who showed you how to > do these things? > > > I learned smalltalk alone. > Now if you can pair program with somebody this is much cooler. > You have pharoCasts, have a look at them. > > I'm currently reading Smalltalk Best Practice Patterns > > Excellent book > > and it's one of the best programming books I've ever read. I see that there > is a great deal of mastery of programming going around in Smalltalk circles, > but I don't see the books that take you past beginner towards master, > > > You have smalltalk by example (even if it is for VW I like it). It is more > about design than Pharo by example and I would like to have one like that in > the future but too busy right now. > > other than SBPP. So what's the trick going on here? How did you guys become > excellent? > > > I hope none of this comes across as negative; > > > Not at all. We know our problems > > I think surely it's that I'm missing something. > > > Thanks, > > > â > > Daniel Lyons > > > > > > >

March 25, 2011

Re: [Pharo-project] Issue 3876 in pharo: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition

by pharo＠googlecode.com

Comment #2 on issue 3876 by nicolas....(a)gmail.com: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition http://code.google.com/p/pharo/issues/detail?id=3876 More exactly, ifFalse:ifTrue: float := self areLowercaseDigitsAllowed ifFalse: [SqNumberParser parse: '16r2.D2593D58B4FC4e-256'] ifTrue: [trueFraction asFloat]. because if lower case digits are allowed, then 16r2.D2593D58B4FC4e-256 is same as 16r2.D2593D58B4FC4E - 256

March 25, 2011

Re: [Pharo-project] Issue 3876 in pharo: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition

by pharo＠googlecode.com

Comment #1 on issue 3876 by nicolas....(a)gmail.com: SqNumberParserTest>>testFloatGradualUnderflow has an odd condition http://code.google.com/p/pharo/issues/detail?id=3876 Hmm, it sounds like a mistake, should be ifTrue:ifFalse: indeed.

March 25, 2011