[Pharo-project] How to integrate Kernel-Extensions
Hi list, we (with Stef) are browsing Kernel-Extensions, here are some notes for discussion, as we think there is stuff that should be merged in Pharo. Null and Split-Join could be packaged on their own since they are well-defined features. Most of the cleanup methods make sense, but what's the difference between cleanUp and freeSomeSpace ? AppRegistry class >> removeObsolete "AppRegistry removeObsoleteClasses" self registeredClasses copy do:[:cls| (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) ifTrue:[self unregister: cls]]. self subclasses do:[:cls| cls removeObsolete]. Behavior class >> flushObsoleteSubclasses "Behavior flushObsoleteSubclasses" ObsoleteSubclasses finalizeValues. Behavior >> sourceMatchesBytecodeAt: Class class >> freeSomeSpace "Fix some problems with classes. Use Smalltalk allClassesDo: since it does not use the subclass list, which we may be modifying during this iteration" Smalltalk allClassesDo: [:ea | ea fixObsoleteSuperclass. ea removeDuplicateSubclassEntries] Collection >> contains: should probably be standardized as part of the STEPS project Collection >> reject:thenDo: and select:thenDo: should be included and similar enumerations reimplemented in this way too SystemDictionary >> forgetClass: aClass logged: aBool badly named but interesting "Delete the class, aClass, from the system. Note that this doesn't do everything required to dispose of a class - to do that use Class>>removeFromSystem." aBool ifTrue: [SystemChangeNotifier uniqueInstance classRemoved: aClass fromCategory: aClass category]. SystemOrganization removeElement: aClass name. self removeFromStartUpList: aClass. self removeFromShutDownList: aClass. self removeKey: aClass name ifAbsent: []. DataStream classRemoved: aClass. self flushClassNameCache SystemDictionary >> globals needs to pay attention that compiled methods share the associations Number >> to: stop do: aBlock displayingProgress: aString would be probably nicer with the block argument last === To discuss: Collection >> removeAll: comment should explain in which cases it is useful "the slow way" ^ self removeAllSuchThat: [ :each | true ] SequenceableCollection >> <= smells funny⦠what is it useful for ? SequenceableCollection >> replacing:with: replaces in place, not obvious from the name the stream methods like putOn: ⦠convenience ? are they coherent ? String >> withoutTrailing: probably makes sense but then this is mostly useful for line breaks⦠why not a #trimLinebreak Set >> likeOrAdd: ok but then that should be available for any collection (and renamed addIfAbsent:) "Include newObject as one of the receiver's elements, but only if not already present. Answer the oldObject." === Useless: ProtoObject >> iconOrThumbnailOfSize: Object >> askFor: and askFor:ifDefault: that's a workaround Object >> deprecated is already here Object >> log should be packaged in a logging package since it's a convenience method SequenceableCollection >> copyReplacing:with: just to type one space less ? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
I know about some of these. I'll leave my comments On Wed, Oct 01, 2008 at 10:53:25PM +0200, Damien Pollet wrote:
Hi list, we (with Stef) are browsing Kernel-Extensions, here are some notes for discussion, as we think there is stuff that should be merged in Pharo.
Most of the cleanup methods make sense, but what's the difference between cleanUp and freeSomeSpace ?
http://installer.pbwiki.com/FreeSomeSpace
AppRegistry class >> removeObsolete "AppRegistry removeObsoleteClasses" self registeredClasses copy do:[:cls| (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) ifTrue:[self unregister: cls]]. self subclasses do:[:cls| cls removeObsolete].
A cleanup method. I think I wrote it. It is used by a freeSomeSpace script
Behavior class >> flushObsoleteSubclasses "Behavior flushObsoleteSubclasses" ObsoleteSubclasses finalizeValues.
Behavior >> sourceMatchesBytecodeAt:
I wrote this one to make it possible to debug things that are badly compiled
Class class >> freeSomeSpace "Fix some problems with classes. Use Smalltalk allClassesDo: since it does not use the subclass list, which we may be modifying during this iteration" Smalltalk allClassesDo: [:ea | ea fixObsoleteSuperclass. ea removeDuplicateSubclassEntries]
I wrote this one to fix some somewhat common problems that can happen in the class heiarchy, especially when unloading packages.
SystemDictionary >> globals needs to pay attention that compiled methods share the associations
Number >> to: stop do: aBlock displayingProgress: aString would be probably nicer with the block argument last
I wrote that one to complement #do:displayingProgress:
SequenceableCollection >> <= smells funny⦠what is it useful for ?
This is built to make it easy to make multi-level sort blocks for SortedCollection: aSortedCollection sortBlock: [:a :b | {a isSpecial. a name} <= {b isSpecial. b name}]
=== Useless:
ProtoObject >> iconOrThumbnailOfSize: Object >> askFor: and askFor:ifDefault: that's a workaround
Object >> deprecated is already here Object >> log should be packaged in a logging package since it's a convenience method
No, that's not the idea at all. Object >> log and Null provide a very lightweight discarding logging framework. We would like it in the kernel so that no matter where a package winds up, it can always do logging, but it may be discarded. After the package Logging is loaded, the user or release team can decide where the logs go (transcript, stdout, and syslog are currently implemented) See http://wiki.squeak.org/squeak/3706 for the documentation on the logging framework.
SequenceableCollection >> copyReplacing:with: just to type one space less ?
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
String >> withoutTrailing: probably makes sense but then this is mostly useful for line breaks⦠why not a #trimLinebreak
Set >> likeOrAdd: ok but then that should be available for any collection (and renamed addIfAbsent:) "Include newObject as one of the receiver's elements, but only if not already present. Answer the oldObject."
add: by convention returns the added object likeOrAdd: is primarily finding an existing object does addIfAbsent: communicate this sufficiently? Personally I think add: should return the object that is actually in the Set after the operation, whereas by default it returns the object that was potentially added.
ProtoObject >> iconOrThumbnailOfSize:
It is not useless, it enables the explorer to work with subclasses of ProtoObject, in particular MagmaProxy 's
Object >> askFor: and askFor:ifDefault: that's a workaround
Its implemented to primarily offer an alternative to adding #isThis #isThat methods to Object. Keith
Object >> log should be packaged in a logging package since it's a convenience method
No, that's not the idea at all. Object >> log and Null provide a very lightweight discarding logging framework. We would like it in the kernel so that no matter where a package winds up, it can always do logging, but it may be discarded. After the package Logging is loaded, the user or release team can decide where the logs go (transcript, stdout, and syslog are currently implemented)
See http://wiki.squeak.org/squeak/3706 for the documentation on the logging framework.
The idea is to promote the use of logging throughout the image using the following convention. self log <subsystem> param1: value1 param2: value2. Thus removing Transcript show: from all over the kernel, and in the process provide more control (filtering, output options etc) via the chosen logging framework. Defining Object-#log ^ Null is the easiest way of implementing a NullLogger in a minimal image. However it is expected that a normal image such as Pharo would be provided with a Transcript logger as the default option. Goran's SLLog provides Transcript, File and Syslog output. Toothpick is also supported as a backend. The other complication is that I designed the logging framework with the intention of using the ProcessSpecific package whereby each process has its own buffer for the text being logged, thus avoiding any form of blocking semaphores etc. Including ProcessSpecific in the main image is another topic for discussion. Keith
I propose to harvest the cleaning behavior. I will go over the list and check Stef On Oct 1, 2008, at 10:53 PM, Damien Pollet wrote:
Hi list, we (with Stef) are browsing Kernel-Extensions, here are some notes for discussion, as we think there is stuff that should be merged in Pharo.
Null and Split-Join could be packaged on their own since they are well-defined features.
Most of the cleanup methods make sense, but what's the difference between cleanUp and freeSomeSpace ?
AppRegistry class >> removeObsolete "AppRegistry removeObsoleteClasses" self registeredClasses copy do:[:cls| (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) ifTrue:[self unregister: cls]]. self subclasses do:[:cls| cls removeObsolete].
Behavior class >> flushObsoleteSubclasses "Behavior flushObsoleteSubclasses" ObsoleteSubclasses finalizeValues.
Behavior >> sourceMatchesBytecodeAt:
Class class >> freeSomeSpace "Fix some problems with classes. Use Smalltalk allClassesDo: since it does not use the subclass list, which we may be modifying during this iteration" Smalltalk allClassesDo: [:ea | ea fixObsoleteSuperclass. ea removeDuplicateSubclassEntries]
Collection >> contains: should probably be standardized as part of the STEPS project Collection >> reject:thenDo: and select:thenDo: should be included and similar enumerations reimplemented in this way too
SystemDictionary >> forgetClass: aClass logged: aBool badly named but interesting "Delete the class, aClass, from the system. Note that this doesn't do everything required to dispose of a class - to do that use Class>>removeFromSystem."
aBool ifTrue: [SystemChangeNotifier uniqueInstance classRemoved: aClass fromCategory: aClass category]. SystemOrganization removeElement: aClass name. self removeFromStartUpList: aClass. self removeFromShutDownList: aClass. self removeKey: aClass name ifAbsent: []. DataStream classRemoved: aClass. self flushClassNameCache
SystemDictionary >> globals needs to pay attention that compiled methods share the associations
Number >> to: stop do: aBlock displayingProgress: aString would be probably nicer with the block argument last
=== To discuss:
Collection >> removeAll: comment should explain in which cases it is useful "the slow way" ^ self removeAllSuchThat: [ :each | true ]
SequenceableCollection >> <= smells funny⦠what is it useful for ? SequenceableCollection >> replacing:with: replaces in place, not obvious from the name the stream methods like putOn: ⦠convenience ? are they coherent ?
String >> withoutTrailing: probably makes sense but then this is mostly useful for line breaks⦠why not a #trimLinebreak
Set >> likeOrAdd: ok but then that should be available for any collection (and renamed addIfAbsent:) "Include newObject as one of the receiver's elements, but only if not already present. Answer the oldObject."
=== Useless:
ProtoObject >> iconOrThumbnailOfSize: Object >> askFor: and askFor:ifDefault: that's a workaround
Object >> deprecated is already here Object >> log should be packaged in a logging package since it's a convenience method
SequenceableCollection >> copyReplacing:with: just to type one space less ?
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Just some thoughts picked up over the years. Things that all Morphs should have, at least, defaults for... UI States: Enabled Enabled Mouse over Enabled Mouse down inside Enabled Mouse down outside (?) Enabled Selected Enabled Selected Mouse over Enabled Selected Mouse down inside Enabled Selected Mouse down outside (?) Disabled Disabled Mouse over (?) Disabled Mouse down inside (?) Disabled Mouse down outside (?) Disabled Selected Disabled Selected Mouse over (?) Disabled Selected Mouse down inside (?) Disabled Selected Mouse down outside (?) "Inactive" (may be responsive to input, as aside from disabled) (part of non primary, up-front window) (as above) ... Transitions between states ... Perhaps it would be good to have Morph have generalised support for these (the inactive ones I've picked up from the Mac, background windows tend to have their controls in a "relatively passive look" state. Just some thoughts for moving ahead with Polymorph... 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"). Regards, Gary.
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
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@acm.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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@acm.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@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@acm.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@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
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@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@acm.org
To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Hi antony
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.
Yes I understand. (We are doing the same for a lot of experimental code. For the release 1.0 we want to remove etoy + friends + bookmorph ) Our goal is similar except that we know that we do not have the workpower to offer support. Now some guys approached us to know if FFI and other stuff would be maintained / improved in Pharo because they would like to port VSE software. So clearly this is not something that we can offer but we would love if a company would offer this service on top or aside of pharo. We have no problems with people making money with what we are doing: in fact this is a goal that people can make money.
I'm focused on Traits + OmniBrowser.
Ok. What is your business model: offering a better IDE? Because we could buy it. I would love to see some real offer, because we are buying all kind of software and I would love to be able to buy some code software that supports our second main activity (coding - first one is writing papers).
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.
Do I guess correctly that you would like to sell a IDE for "Squeak"? I do not know myEclipse. If you would base your effort on Pharo we could also integrate your refactoring
Is your code free?
Yes, that code is. I haven't explicitly licensed it yet.
Let us know when you know and if you want to share what can be shared.
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.
Excellent!
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.
Sounds interesting.
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.
Welcome :)
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.
I would really like to have a bootstrap kernel so that we could even manage the source with git :)
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.
You are welcome. Our goal is really to get rid and improve a lot of things. So if you can share some parts we may be in a win-win situation.
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.
Nice quote :)
participants (8)
-
Antony Blakey -
Damien Pollet -
Gary Chambers -
Igor Stasenko -
Keith Hodges -
Matthew Fulmer -
Michael Rueger -
Stéphane Ducasse