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

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

by Dennis Schetinin

Isn't there some kind of "Ideas" page yet? Would also be useful for GSoC, etc. 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 24, 2011

[Pharo-project] Issue 3861 in pharo: Image freeze when changing system time

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3861 by lem...(a)gmail.com: Image freeze when changing system time http://code.google.com/p/pharo/issues/detail?id=3861 Pharo image: Pharo1.2.1a Latest update: #12343 Virtual machine used: 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.47' System: GNU / Linux. Opensuse 11.4 x86_64. KDE 4.6 Steps to reproduce: 1. open the image 2. change the time in my system to a previous time. For example from 13:00 to 12:00. 3. Image freeze... and you have to kill the vm. I try the same thing, with 'Squeak4.1 of 17 April 2010 [latest update: #9957]' VM, and it didn't freeze. I tested also both machines opened, and only cog freeze. So i think maybe it's a cog vm issue.

March 24, 2011

[Pharo-project] Issue 3860 in pharo: Overzealous arithmetic collection removal

by pharo＠googlecode.com

Status: Accepted Owner: ryd...(a)gmail.com Labels: Milestone-1.3 New issue 3860 by ryd...(a)gmail.com: Overzealous arithmetic collection removal http://code.google.com/p/pharo/issues/detail?id=3860 Separated to http://www.squeaksource.com/CollectionArithmetic. FloatArray and WordArray methods should be moved back into the image, as these specifically are numerical collections, not for general storage. It makes very little sense to remove the operations, but keep the primitive methods they use... Also be careful dot: change from Issue 3701 is not reverted when merging.

March 24, 2011

Re: [Pharo-project] Issue 3858 in pharo: On windows, Error when dropping an image in the vm

by pharo＠googlecode.com

Comment #5 on issue 3858 by siguc...(a)gmail.com: On windows, Error when dropping an image in the vm http://code.google.com/p/pharo/issues/detail?id=3858 it would be nice if you can nail down an issue to pharo-core image :)

March 24, 2011

Re: [Pharo-project] Issue 3858 in pharo: On windows, Error when dropping an image in the vm

by pharo＠googlecode.com

Comment #4 on issue 3858 by cy.delau...(a)gmail.com: On windows, Error when dropping an image in the vm http://code.google.com/p/pharo/issues/detail?id=3858 It's an image from http://www.moosetechnology.org/download It is the Moose 4.3 release I join a picture of the error Attachments: bug.png 34.8 KB

March 24, 2011

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

by Igor Stasenko

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.

March 24, 2011

Re: [Pharo-project] Issue 3667 in pharo: ThreadSafeTranscript does not understand crtab and crtab:

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3667 by marcus.d...(a)gmail.com: ThreadSafeTranscript does not understand crtab and crtab: http://code.google.com/p/pharo/issues/detail?id=3667 in 13107

March 24, 2011

Re: [Pharo-project] Issue 3701 in pharo: FloatArray>>dot: is defined in plugin but not at the image level

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3701 by marcus.d...(a)gmail.com: FloatArray>>dot: is defined in plugin but not at the image level http://code.google.com/p/pharo/issues/detail?id=3701 in 13107

March 24, 2011

Re: [Pharo-project] Issue 3638 in pharo: look for sender of etoyCleaningLeftToDo

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3638 by marcus.d...(a)gmail.com: look for sender of etoyCleaningLeftToDo http://code.google.com/p/pharo/issues/detail?id=3638 in 13107

March 24, 2011

[Pharo-project] [update 1.3] #13107

by Marcus Denker

13107 ----- Issue 3768: Deprecate String >> get/putInteger32: Issue 1765: JPEGReadWriter>>#decompressionTest should be made into a Sunit Test Issue 2240: CondenseChange Trait Tests Issue 2786: Mixed concerns on Object>>saveOnFile Issue 3638: look for sender of etoyCleaningLeftToDo Issue 3701: FloatArray>>dot: is defined in plugin but not at the image level Issue 3667: ThreadSafeTranscript does not understand crtab and crtab: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 24, 2011