- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Formalised UI

by StÃ©phane Ducasse

Hi antony Yes I like your look. > If Pharo is meant to be a 'professional' environment then IMO you > should concentrate on implementing known and tested solutions for > layout, rather than inventing a new system. > > By professional I am assuming people mean interfaces as you see in > Windows and OSX applications e.g. fields, buttons, checkboxes etc. By professional we mean: clean and robust, Of course we would like to have a good layout and UI. But someone has to do it. :) What is also important is that people get the fredom to invent new things and that pharo keeps making progress even at the price to be incompatible. > > > Your example of functional relationships between ordinates has been > well studied in the field of constraint satisfaction - specifically > in Smalltalk. There is a package, cassowary (sp?) that is designed > to do this. However, IMO this idea i's overly general for > 'professional' UIs. > > I've implemented a layout manager for VW based on the Java layout > manager using in Matisse, that allows you to achieve slick looking > UI layouts in a declarative fashion. You should look to Java for > ideas about layout and dimensioning. The Java ecosystem is well in > front of Smalltalk in this area, given that Java is focussed on > those kinds of applications. Is your code free? Lot of people in the past started and never finished (Bricks for example was one of these attempts). Now may be you could join gary effort with polymorph? There is also Miro, ISqueak... One of the key aspects is that the underlying infrastructure should be able to easily switch between UI. We expect the clean of mike to fix issues to that respect. A key important message of pharo is if you do something good we will not let it aside (I remember the blue look of Hneryk with antialiased fonts before mac os X, or the new compiler that if marcus would not have invested was lost). > Regarding geometric properties of controls, the key characteristics > are those that allow for visual alignment, recognizing that the > visual bounds of a control in it's various states is not always the > same as it's alignment points. Two examples of this are 1) the focus > indicator of OSX which is outside of the visual/alignment dimensions > of the control and 2) the borders of controls that use dark/light > line pairs for boundaries usually want to align to other controls > using the dark line, which is often above the lighter line - hence > the alignment geometry of the control even in it's unfocussed state > is not the same as it's draw bounds. > > Thus OSX controls have both bounds and alignment insets. > > A key alignment point is the text baseline. This is the most common > problem with UIs. Basically, if you don't align on baselines then > everything looks crap. > > There are various spacing and dimensioning relations between > controls, between non-control elements and to the window border. > These are dependent on the platform, the types of controls and > whether the controls are semantically related. Thus these spacing > constants need to be symbolic. > > Finally, professional looking interfaces really require that you > eliminate configurability from controls. Colors, fonts, borders etc > are all designed to harmonize in OSX, and IMO this is a primary > reason that Squeak looks like a toy, and VW on OSX looked so > appalling before I fixed it. Google for 'ASBAqua' for details. Oh yes!!!!!!!!!!! Samuel Morello proposed us to design a user interface for pharo and he discussed with Gary. > > > All of this I have done (sans a few corner cases) and published (for > VW). I've detailed a lot of this on my VW blog: http://www.cincomsmalltalk.com/userblogs/antony/blogView > . IMO the best approach for Pharo is to focus on solving specific > issues, and the best way to do that is to try and implement UIs that > look at home on e.g. OSX, and hence discover what techniques/tools/ > frameworks you need to do that, rather than try to invent new ways > of doing things. Squeak is already littered with the result of that, > and Smalltalk's poor modularity and packaging means that such > abandoned projects stick like bubblegum in carpet. :) We are slowly fixing that > > > I'm now in the early days of a (commercial) product, preliminary > name 'Stardust Smalltalk' (based on Squeak, not VW), that implements > the ideas from my blog - better UI, alternative forms of code > navigation, Did you check the way newspeak does it with hopstoch > new packaging/deployment tools including GIT integration Interesting. What do you mean by new packaging. We are thinking about a module system but for milestone 4 or 5 (one year or two from now). Can you bootstrap the kernel? One which version of Squeak are you based? > and modularity enhancements, If you want to share code let us know. > WebKit integration, LLVM/Clang integration. A very early screenshot > is here: http://linkuistics.com/ftp/Stardust-2008-10-03.png. I > mention this to show that my comments above are not abstract > opinions. I'm in the trenches with these issues. > > BTW: I mean no disrespect to Squeak. Looking like a toy is great for > an education product, which in the scheme of things is a more > important tool than yet another commercial IDE. We are in sycn there. Do not worry. We love the idea in etoy for Kids but the implementation makes me sick. > > > On 03/10/2008, at 11:32 AM, Igor Stasenko wrote: > >> The idea behind ordinates is to deal with morphic layouts. >> >> Any morph , can define an arbitrary set of ordinates, then another >> morph can say - lets my ordinate 'center' be a function which >> calculates its position by taking another morph ordinate into >> account. >> There can be infinite number of combinations how one morph's layout >> can depend on another one. And ordinate system can allow any of >> them - >> its up to you to define a function which calculates morph's position >> based on another coordinates. >> >> Example: >> morph A is rectangle and defines following ordinates: >> - origin = coordinate(x1 @ y1) >> - corner = coordinate(x2 @ y2) >> - center = function(origin + corner / 2 ) >> - topright = function (corner x , origin y) >> - bottomleft = function (origin x, corner y) >> - width = function ( x2-x1 ) >> - height = function ( y2-y1) >> >> Now morph B , is a circle and defines following ordinates: >> - center >> - radius >> >> now suppose i want that morph B should always be drawn in a center of >> morph A, with diameter = height of morphA : >> center = function( morphA center) >> radius = function (morphA height / 2 ) >> >> Now, if you try to play with morphA, by dragging it over desktop or >> resizing it - the morphB will automagically update its position as >> well. >> >> 2008/10/2 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> Well, I've done a bit with CSS (3.0) not fully looked though, just >>> enough >>> that our Report Builder file format (XML) is roughly equivalent. >>> >>> Just a thought about states of "widgets" I've seen in the wild... >>> base >>> Morphic doen't honour any of them by default... hence lots of >>> extra code for >>> dealing with interactive states in eveyone's subclasses/overrides. >>> To be >>> fair it is not appropriate to every Morph... just more common with >>> "standard" (if you like) styles of widgets. >>> >>> As for ordinates, it was on IRC with Sig... tricky to track down >>> logs, did >>> find a link for a related dev-list email part of it though: >>> >>> http://www.nabble.com/Re:--squeak-dev--Subcanvas-p18270830.html >>> >>> Gary. >>> >>> ----- Original Message ----- From: "Michael Rueger" <m.rueger(a)acm.org >>> > >>> To: "An open mailing list to discuss any topics related to an >>> open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Thursday, October 02, 2008 6:42 PM >>> Subject: Re: [Pharo-project] Formalised UI >>> >>> >>>> Gary Chambers wrote: >>>>> >>>>> Just some thoughts picked up over the years. Things that all >>>>> Morphs >>>>> should have, at least, defaults for... >>>>> >>>>> UI States: >>>> >>>> how does this list compare to the list of possible CSS states? >>>> >>>> >>>>> Transitions would be nice, but might be a bit overboard... Igor >>>>> and I >>>>> discussed a framework based on 4 dimensional representations >>>>> being function >>>>> based (I think we coined the phrase "Ordinates"). >>>> >>>> Can you say more about this? >>>> >>>> Michael >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > It is as useless to argue with those who have renounced the use of > reason as to administer medication to the dead. > -- Thomas Jefferson > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2008

Re: [Pharo-project] Formalised UI

by Antony Blakey

If Pharo is meant to be a 'professional' environment then IMO you should concentrate on implementing known and tested solutions for layout, rather than inventing a new system. By professional I am assuming people mean interfaces as you see in Windows and OSX applications e.g. fields, buttons, checkboxes etc. Your example of functional relationships between ordinates has been well studied in the field of constraint satisfaction - specifically in Smalltalk. There is a package, cassowary (sp?) that is designed to do this. However, IMO this idea i's overly general for 'professional' UIs. I've implemented a layout manager for VW based on the Java layout manager using in Matisse, that allows you to achieve slick looking UI layouts in a declarative fashion. You should look to Java for ideas about layout and dimensioning. The Java ecosystem is well in front of Smalltalk in this area, given that Java is focussed on those kinds of applications. Regarding geometric properties of controls, the key characteristics are those that allow for visual alignment, recognizing that the visual bounds of a control in it's various states is not always the same as it's alignment points. Two examples of this are 1) the focus indicator of OSX which is outside of the visual/alignment dimensions of the control and 2) the borders of controls that use dark/light line pairs for boundaries usually want to align to other controls using the dark line, which is often above the lighter line - hence the alignment geometry of the control even in it's unfocussed state is not the same as it's draw bounds. Thus OSX controls have both bounds and alignment insets. A key alignment point is the text baseline. This is the most common problem with UIs. Basically, if you don't align on baselines then everything looks crap. There are various spacing and dimensioning relations between controls, between non-control elements and to the window border. These are dependent on the platform, the types of controls and whether the controls are semantically related. Thus these spacing constants need to be symbolic. Finally, professional looking interfaces really require that you eliminate configurability from controls. Colors, fonts, borders etc are all designed to harmonize in OSX, and IMO this is a primary reason that Squeak looks like a toy, and VW on OSX looked so appalling before I fixed it. Google for 'ASBAqua' for details. All of this I have done (sans a few corner cases) and published (for VW). I've detailed a lot of this on my VW blog: http://www.cincomsmalltalk.com/userblogs/antony/blogView . IMO the best approach for Pharo is to focus on solving specific issues, and the best way to do that is to try and implement UIs that look at home on e.g. OSX, and hence discover what techniques/tools/ frameworks you need to do that, rather than try to invent new ways of doing things. Squeak is already littered with the result of that, and Smalltalk's poor modularity and packaging means that such abandoned projects stick like bubblegum in carpet. I'm now in the early days of a (commercial) product, preliminary name 'Stardust Smalltalk' (based on Squeak, not VW), that implements the ideas from my blog - better UI, alternative forms of code navigation, new packaging/deployment tools including GIT integration and modularity enhancements, WebKit integration, LLVM/Clang integration. A very early screenshot is here: http://linkuistics.com/ftp/Stardust-2008-10-03.png . I mention this to show that my comments above are not abstract opinions. I'm in the trenches with these issues. BTW: I mean no disrespect to Squeak. Looking like a toy is great for an education product, which in the scheme of things is a more important tool than yet another commercial IDE. On 03/10/2008, at 11:32 AM, Igor Stasenko wrote: > The idea behind ordinates is to deal with morphic layouts. > > Any morph , can define an arbitrary set of ordinates, then another > morph can say - lets my ordinate 'center' be a function which > calculates its position by taking another morph ordinate into account. > There can be infinite number of combinations how one morph's layout > can depend on another one. And ordinate system can allow any of them - > its up to you to define a function which calculates morph's position > based on another coordinates. > > Example: > morph A is rectangle and defines following ordinates: > - origin = coordinate(x1 @ y1) > - corner = coordinate(x2 @ y2) > - center = function(origin + corner / 2 ) > - topright = function (corner x , origin y) > - bottomleft = function (origin x, corner y) > - width = function ( x2-x1 ) > - height = function ( y2-y1) > > Now morph B , is a circle and defines following ordinates: > - center > - radius > > now suppose i want that morph B should always be drawn in a center of > morph A, with diameter = height of morphA : > center = function( morphA center) > radius = function (morphA height / 2 ) > > Now, if you try to play with morphA, by dragging it over desktop or > resizing it - the morphB will automagically update its position as > well. > > 2008/10/2 Gary Chambers <gazzaguru2(a)btinternet.com>: >> Well, I've done a bit with CSS (3.0) not fully looked though, just >> enough >> that our Report Builder file format (XML) is roughly equivalent. >> >> Just a thought about states of "widgets" I've seen in the wild... >> base >> Morphic doen't honour any of them by default... hence lots of extra >> code for >> dealing with interactive states in eveyone's subclasses/overrides. >> To be >> fair it is not appropriate to every Morph... just more common with >> "standard" (if you like) styles of widgets. >> >> As for ordinates, it was on IRC with Sig... tricky to track down >> logs, did >> find a link for a related dev-list email part of it though: >> >> http://www.nabble.com/Re:--squeak-dev--Subcanvas-p18270830.html >> >> Gary. >> >> ----- Original Message ----- From: "Michael Rueger" >> <m.rueger(a)acm.org> >> To: "An open mailing list to discuss any topics related to an >> open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Thursday, October 02, 2008 6:42 PM >> Subject: Re: [Pharo-project] Formalised UI >> >> >>> Gary Chambers wrote: >>>> >>>> Just some thoughts picked up over the years. Things that all Morphs >>>> should have, at least, defaults for... >>>> >>>> UI States: >>> >>> how does this list compare to the list of possible CSS states? >>> >>> >>>> Transitions would be nice, but might be a bit overboard... Igor >>>> and I >>>> discussed a framework based on 4 dimensional representations >>>> being function >>>> based (I think we coined the phrase "Ordinates"). >>> >>> Can you say more about this? >>> >>> Michael >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. -- Thomas Jefferson

Oct. 3, 2008

Re: [Pharo-project] Formalised UI

by Igor Stasenko

The idea behind ordinates is to deal with morphic layouts. Any morph , can define an arbitrary set of ordinates, then another morph can say - lets my ordinate 'center' be a function which calculates its position by taking another morph ordinate into account. There can be infinite number of combinations how one morph's layout can depend on another one. And ordinate system can allow any of them - its up to you to define a function which calculates morph's position based on another coordinates. Example: morph A is rectangle and defines following ordinates: - origin = coordinate(x1 @ y1) - corner = coordinate(x2 @ y2) - center = function(origin + corner / 2 ) - topright = function (corner x , origin y) - bottomleft = function (origin x, corner y) - width = function ( x2-x1 ) - height = function ( y2-y1) Now morph B , is a circle and defines following ordinates: - center - radius now suppose i want that morph B should always be drawn in a center of morph A, with diameter = height of morphA : center = function( morphA center) radius = function (morphA height / 2 ) Now, if you try to play with morphA, by dragging it over desktop or resizing it - the morphB will automagically update its position as well. 2008/10/2 Gary Chambers <gazzaguru2(a)btinternet.com>: > Well, I've done a bit with CSS (3.0) not fully looked though, just enough > that our Report Builder file format (XML) is roughly equivalent. > > Just a thought about states of "widgets" I've seen in the wild... base > Morphic doen't honour any of them by default... hence lots of extra code for > dealing with interactive states in eveyone's subclasses/overrides. To be > fair it is not appropriate to every Morph... just more common with > "standard" (if you like) styles of widgets. > > As for ordinates, it was on IRC with Sig... tricky to track down logs, did > find a link for a related dev-list email part of it though: > > http://www.nabble.com/Re:--squeak-dev--Subcanvas-p18270830.html > > Gary. > > ----- Original Message ----- From: "Michael Rueger" <m.rueger(a)acm.org> > To: "An open mailing list to discuss any topics related to an > open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, October 02, 2008 6:42 PM > Subject: Re: [Pharo-project] Formalised UI > > >> Gary Chambers wrote: >>> >>> Just some thoughts picked up over the years. Things that all Morphs >>> should have, at least, defaults for... >>> >>> UI States: >> >> how does this list compare to the list of possible CSS states? >> >> >>> Transitions would be nice, but might be a bit overboard... Igor and I >>> discussed a framework based on 4 dimensional representations being function >>> based (I think we coined the phrase "Ordinates"). >> >> Can you say more about this? >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 3, 2008

[Pharo-project] Re: Exupery's VMMaker on SqueakSource now has closures

by Markus Fritsche

bryce(a)kampjes.demon.co.uk schrieb: > I can supply a built VM if anyone wants to try it immediately. If > not I'll package one up after finishing tidying up. Hello Bryce, I'd like to try it out immediately. But... What are the premises? Do I have to build a special VM for Exupery (your post indicates that)? Is Exupery x86_64 compatible? Do I have to take special actions with my image? Can I run 'seaside' with exupery? Are there drawbacks/ gains on memory/ cpu consumption?

Oct. 3, 2008

Re: [Pharo-project] History and SUnit

by Keith Hodges

Oh and in the ss/Testing repo the master packages are still SUnit and SUnitGUI, the "Testing" heirarchy is a proposed reorganisation for the future. Keith

Oct. 2, 2008

Re: [Pharo-project] History and SUnit

by Keith Hodges

StÃ©phane Ducasse wrote: > Thanks > I will have a look. I do not really understand what is written, this > is too cryptic. > Does the framework changes remove the fact that tests should start > with test? > > Stef Yes, although the default behaviour is preserved, TestCase subclasses can publish their own test suites with whatever behaviour they wish. BTW: the framework has changed somewhat since that documentation was written. For example in SSpec "specs" start with spec* the goal is to enable TestRunner to be used as a runner for SSpec as well as SUnit, if I ever get around to it. Keith

Oct. 2, 2008

[Pharo-project] Exupery's VMMaker on SqueakSource now has closures

by bryce＠kampjes.demon.co.uk

I can supply a built VM if anyone wants to try it immediately. If not I'll package one up after finishing tidying up. Looking at the bytecodes, they're suppressing context recycling whenever a closure is created. The only reason that closures refer to their surrounding contexts is to support ^ returns from blocks. With two more context creation bytecodes we should allow all contexts to be recycled except the outer method context when there's a block that ^ returns. Such optimisation can wait though, especially as it would involve removing some of Eliot's sanity checking which may be useful when adapting the image to use these bytecodes. Bryce

Oct. 2, 2008

[Pharo-project] Re: Universe Browser - search

by Dan Corneanu

Just made an update and seen the Univers Browser (enhanced). It seems to have what I wanted :) On Thu, Oct 2, 2008 at 11:46 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > Hi, > I know it is not decided yet what will pharo use for loading code, but > I would really appreciate a search button in the Univers Browser. > I always find myself lost in the tree. >

Oct. 2, 2008

[Pharo-project] Universe Browser - search

by Dan Corneanu

Hi, I know it is not decided yet what will pharo use for loading code, but I would really appreciate a search button in the Univers Browser. I always find myself lost in the tree.

Oct. 2, 2008

[Pharo-project] Did you harvest Kernel-dc.198

by StÃ©phane Ducasse

Hi marcus did you harvest ? Name: Kernel-dc.198 Author: dc Time: 28 September 2008, 4:00:03 pm UUID: 3b2eeec4-6461-4d22-94d1-e7f692e7e177 Ancestors: Kernel-marcus.denker.197 - M7166: speedup allSelectors add allSelectorsBelow:. Firstly #allSelectors inefficiently creates multiple intermediate collections. Refactoring this yields a 27% speed improvement. Secondly many users of #allSelectors forget that when applied to the class side it doesnt stop at ProtoObject class, it continues to Class ClassDescription, Behavior, Object and ProtoObject. This is catered for by adding #allSelectorsBelow: Magritte and SUnit are heavy users which benefit. I imagine not so I will.

Oct. 2, 2008