March 2011 - Pharo-dev - lists.pharo.org

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

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

by Igor Stasenko

Haha... that's fun! :) 2011/3/25 Torsten Bergmann <astares(a)gmx.de>: > GÃ¶ran wrote: >>One way could be to create a fast "Morphic player" layer in js > > Did you see http://astares.blogspot.com/2011/03/morphic-in-javascript.html > > Try it here: > Â http://chirp.scratchr.org/dl/experimental/JsMorphic/morphic.html > > Bye > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > -- Best regards, Igor Stasenko AKA sig.

March 25, 2011

Re: [Pharo-project] [ANN] Self-learning PocketCube Solver

by HwaJong Oh

it's 2x2x2 Rubik's cube. Much simpler thant original 3x3x3. http://en.wikipedia.org/wiki/Pocket_cube -- View this message in context: http://forum.world.st/ANN-Self-learning-PocketCube-Solver-tp3404815p3405036… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 25, 2011

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

by Torsten Bergmann

GÃ¶ran wrote: >One way could be to create a fast "Morphic player" layer in js Did you see http://astares.blogspot.com/2011/03/morphic-in-javascript.html Try it here: http://chirp.scratchr.org/dl/experimental/JsMorphic/morphic.html Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

March 25, 2011

Re: [Pharo-project] pharo closures

by Toon Verwaest

> If i'm not mistaken, remote temp vectors are rare.. > (Eliot could give you a nice doit to count all closures in system > which using temps vector) > > So if its even slow, its not a big deal anyways. My point was not really that I would make it faster. My point was more that I would do the straightforward thing and link context frames together rather than remote vectors. If I see a context frame linked from another frame, I can generally understand what this means. If I see an array with values shared between context frames ... it's not immediately obvious from inspecting the objects. So the semantics get slightly obscured. 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 ;) cheers, Toon

March 25, 2011