On 25 March 2011 12:12, Mariano Martinez Peck <[email protected]> wrote: > > > On Thu, Mar 24, 2011 at 4:33 PM, Dennis Schetinin <[email protected]> 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 <[email protected]> >>> >>> 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 <[email protected]> >>> 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.
