October 2008 - Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

Done in 10085 Stef On Oct 3, 2008, at 8:08 AM, Marcus Denker wrote: > > On 02.10.2008, at 21:59, StÃ©phane Ducasse wrote: > >> Hi marcus >> >> did you harvest ? >> > > No, but this looks good. > > Marcus > >> 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. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > 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] History and SUnit

by Simon Kirk

On 2 Oct 2008, at 23:24, Keith Hodges wrote: > 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. In the latest version of the SSpec runner that we use (which is also the latest in Squeaksource iirc, as John here made the most recent changes) specs can be whatever format you want, but the spec method(s) must be in the method category "specs" in order to run. Generally specs (ie BDD) are of the format "shouldDoBlahBlah" so that they read in a BDD manner when they report problems. In practice this means It parses the camel case in the output message, so for example: if the spec class is AddTwoNumbersSpec then you'd get something like "Add two numbers spec should get negative number for negative arguments". This sentence is English, and is relatively easy to parse and understand what the desired behaviour is. So: using "should" as a prefix makes sense to me, and I like the use of the method categorisation to define what runs as a spec: it makes it easy to turn some specs on and off within a spec class without having to do method renames, which is generally more hassle (changing a method category is a drag and drop operation). My â¬0.02 as usual. S ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 3, 2008

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

by bryce＠kampjes.demon.co.uk

Markus Fritsche writes: > 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? I'll bundle up the VM after work. (Tonight UK time) Exupery requires a few VM extensions, they're completely harmless unless you also load Exupery and start it running. I already need to maintain a VM for Exupery, so I merged the changes Pharo wanted into it. By merging the changes into Exupery's branch of VMMaker, they'll get in all future VMs I build. So long as you don't run Exupery, it's just another VM, but with both the truetype font changes and the closure bytecodes. You can run Seaside, and anything else. Exupery itself is compatable with Seaside. There's a tiny fix to Seaside's continuations that's been included in 2.9 that you may want. The VM is a 32 bit one, but runs OK on 64 bit Linux in compatability mode. If you want to have a modern VM with closure bytecodes then using the Exupery VMMaker is a reasonable thing to do. By just building using Exupery's latest version of VMMaker rather than the one from SqueakMap, you'll get closure support and sub-pixel anti-aliasing. Bryce

Oct. 3, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Simon Kirk

It has a search, but the last time I tried it it didn't actually find anything for any given string (perhaps I just had a bad experience) On 2 Oct 2008, at 22:05, Dan Corneanu wrote: > 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. >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 3, 2008

Re: [Pharo-project] Formalised UI

by Antony Blakey

On 03/10/2008, at 2:50 PM, StÃ©phane Ducasse wrote: > 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. I have slightly different goals. I'm less concerned about cleaning up Squeak to start with, more concerned with making something that is commercially focussed, with support, that is packaged to allow it to cross the chasm. To that end I don't care about breaking everything that I don't intend to support, so my refactoring can be quite aggressive. I'm focused on Traits + OmniBrowser. My reasons for attempting a commercial development is to generate a revenue stream that ensures continuity of development, so that it doesn't become abandonware. I'm planning for a situation like MyEclipse. I can support this project for at least a few years without revenue. > Is your code free? Yes, that code is. I haven't explicitly licensed it yet. > Now may be you could join gary effort with polymorph? My ongoing efforts are commercial, so it's probably not possible. And I've got a very definite architecture in progress already. > Did you check the way newspeak does it with hopstoch I was working on a dynamic document-based model before hopscotch was demonstrated, so yes. I have a background in structured document editors, which is what motivates me. > 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). My packaging/modularity project is called MirrorImage - some details are on my blog. It works with VW, although I haven't really released it because there wasn't much interest, and in any case VW is the wrong community for such proposals. MirrorImage is a reworking of how classes are defined. In particular it uses a DSL approach to system construction that allows classes to be incrementally constructed, with contributions from different 'Projects' that can be prioritized with dependencies etc based on a configuration algebra. Such contributions can be more that simply adding vars and methods (ala GST) - you can delete/add/transform/ shadow any part of the code model (ivar/cvar/methods/traits etc). Transformation is useful for changing the way traits are integrated into a class you want to change. Traits also have an interesting interaction with system construction from a pragmatic perspective because they act as a conceptual delimiter, although that may be less interesting once I don't have to rely on the completely braindead method-category string prefix model of packaging. My #1 dislike in Squeak. > Can you bootstrap the kernel? Not yet, I was about to do that when I decided to switch from VW. I will bootstrap the Kernel using the same technique that Lisp systems use to bootstrap. Once that works it will also be the tool I use to cut out the stuff I don't intend to support. > One which version of Squeak are you based? I started with the Damien's 3.10 dev packaging, although I'm thinking of switching to Pharo as a base. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince.

Oct. 3, 2008

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

by Marcus Denker

On 02.10.2008, at 21:59, StÃ©phane Ducasse wrote: > Hi marcus > > did you harvest ? > No, but this looks good. Marcus > 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. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 3, 2008

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