[Pharo-project] Polymorph (and a few other) changes/fixes
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). Attached cs and description of changes Regards, Gary
Thanks! I really want to have a look at your changes to learned. I cleaned the <on> <off> menu items handling. Now no string generation and string parsing anymore :) I let the code to be compatible and in 2.1 we can flush them. Stef
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Do you have an example where the DropListMorph wrapSelector is broken ? Ben On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Hi, well it seems that there is now an inst var on DropListMorph for wrapSelector, only used by getter/setter and wrapItem:index: Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as updateList never gets sent to the list... E.g. (UITheme builder newDropListFor: (ListModel new list: {Object. Rectangle}) list: #list getSelected: nil setSelected: nil getEnabled: nil help: nil) wrapSelector: #className; openInWindow Easy to fix but I'll wait till it is before I post some of my changes that were in conflict. Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 10:28 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes Do you have an example where the DropListMorph wrapSelector is broken ? Ben On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). Attached cs and description of changes Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
I do not get why, but in your example, wrapSelector instance is always nil ... I use this (DropListMorph + wrapSelector) for nautilus, and it works as expected (the list is wrapped too). Ben On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:
Hi,
well it seems that there is now an inst var on DropListMorph for wrapSelector, only used by getter/setter and wrapItem:index:
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as updateList never gets sent to the list...
E.g.
(UITheme builder newDropListFor: (ListModel new list: {Object. Rectangle}) list: #list getSelected: nil setSelected: nil getEnabled: nil help: nil) wrapSelector: #className; openInWindow
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 10:28 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Do you have an example where the DropListMorph wrapSelector is broken ?
Ben
On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:
Hi,
well it seems that there is now an inst var on DropListMorph for wrapSelector, only used by getter/setter and wrapItem:index:
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as updateList never gets sent to the list...
E.g.
(UITheme builder newDropListFor: (ListModel new list: {Object. Rectangle}) list: #list getSelected: nil setSelected: nil getEnabled: nil help: nil) wrapSelector: #className; openInWindow
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 10:28 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Do you have an example where the DropListMorph wrapSelector is broken ?
Ben
On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Yep, that's what I expected as fix ;-) Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 11:58 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben ------------------------------------------------------------------------------ On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote: Hi, well it seems that there is now an inst var on DropListMorph for wrapSelector, only used by getter/setter and wrapItem:index: Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as updateList never gets sent to the list... E.g. (UITheme builder newDropListFor: (ListModel new list: {Object. Rectangle}) list: #list getSelected: nil setSelected: nil getEnabled: nil help: nil) wrapSelector: #className; openInWindow Easy to fix but I'll wait till it is before I post some of my changes that were in conflict. Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 10:28 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes Do you have an example where the DropListMorph wrapSelector is broken ? Ben On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote: Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). Attached cs and description of changes Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt> ------------------------------------------------------------------------------ Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:
Hi,
well it seems that there is now an inst var on DropListMorph for wrapSelector, only used by getter/setter and wrapItem:index:
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed. So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as updateList never gets sent to the list...
E.g.
(UITheme builder newDropListFor: (ListModel new list: {Object. Rectangle}) list: #list getSelected: nil setSelected: nil getEnabled: nil help: nil) wrapSelector: #className; openInWindow
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
Regards, Gary ----- Original Message ----- From: Benjamin To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, April 25, 2012 10:28 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Do you have an example where the DropListMorph wrapSelector is broken ?
Ben
On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Gary I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ? ExpanderMorph>>defaultTitleMorph "Answer a default title morph for the receiver." ^ExpanderTitleMorph basicNew basicTheme: self theme; initialize; hResizing: #spaceFill; vResizing: #shrinkWrap; basicTheme: nil On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Hi Stef, I guess you mean to move the resizing bits. It is explicit in ExpanderMorph because that's how the title should be in the context of an expander. The ExpanderTitleMorph *could* be used elsewhere with different properties. Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 10:42 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes Gary I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ? ExpanderMorph>>defaultTitleMorph "Answer a default title morph for the receiver." ^ExpanderTitleMorph basicNew basicTheme: self theme; initialize; hResizing: #spaceFill; vResizing: #shrinkWrap; basicTheme: nil On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo: self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]] Stef
Well, since a TabLabelMorph could have any morph within it all morphs would have to implement #font: otherwise. It is the price of having both convenience and flexibility. Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 12:53 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo: self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]] Stef
Gary Chambers-4 wrote
Well, since a TabLabelMorph could have any morph within it all morphs would have to implement #font: otherwise.
This is something I've wondered about since finding Smalltalk. Isn't that the Smalltalk way? i.e. put an extension method in Morph that does nothing and package it with Polymorph. -- View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p4586... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Well, Stef was wanting to get away from all that ;-) Hence Object cleanup etc. Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean@clipperadams.com> To: <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 4:16 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Gary Chambers-4 wrote
Well, since a TabLabelMorph could have any morph within it all morphs would have to implement #font: otherwise.
This is something I've wondered about since finding Smalltalk. Isn't that the Smalltalk way? i.e. put an extension method in Morph that does nothing and package it with Polymorph.
-- View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p4586... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Gary Chambers-4 wrote
Well, Stef was wanting to get away from all that ;-) Hence Object cleanup etc.
I totally understand the cleanup of regular methods, but are extension methods included? In fact, why not hide extension categories by default in Nautilus and then you have both polymorphic simplicity and a manageable number of methods to deal with from the tools... -- View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p4591... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
two answers - we should pay attention that sometimes gary hacked polymorph because he knew that he could not touch the core - so there are some parts that should get in the right places. - this is not about visibility more about dependencies stef On Apr 27, 2012, at 12:05 AM, Sean P. DeNigris wrote:
Gary Chambers-4 wrote
Well, Stef was wanting to get away from all that ;-) Hence Object cleanup etc.
I totally understand the cleanup of regular methods, but are extension methods included? In fact, why not hide extension categories by default in Nautilus and then you have both polymorphic simplicity and a manageable number of methods to deal with from the tools...
-- View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p4591... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stéphane Ducasse wrote
- this is not about visibility more about dependencies
So an extension method does not create a dependency, right? If I replace a test like:
(m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont] with a Morph>>font: method in a *Polymorph protocol, all the code is still in the Polymorph package, so it's simpler, with no clear deficiency (except possibly clutter in the browser, which we discussed). I'm just thinking this through for myself....
-- View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p4592... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Apr 27, 2012, at 2:53 PM, Sean P. DeNigris wrote:
Stéphane Ducasse wrote
- this is not about visibility more about dependencies
So an extension method does not create a dependency, right? If I replace a test like:
(m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont] with a Morph>>font: method in a *Polymorph protocol, all the code is still in the Polymorph package, so it's simpler, with no clear deficiency (except possibly clutter in the browser, which we discussed). I'm just thinking this through for myselfâ¦.
yes Now too much layering can be a problem so this is why we want to get core packages solid. Stef
-- View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p4592... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
In the future we will have to look at respondsTo: and remove them because we should enforce for example that objects that are used have the right protocol |label| label := self checkboxLabelForText: aCheckbox label. (label respondsTo: #enabled:) ifTrue: [ label enabled: aCheckbox enabled]. label font: self labelFont. ^label On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:
self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]]
Stef
Indeed. Hold off on integration for a few mins, some last minute fixes... Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 1:17 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes In the future we will have to look at respondsTo: and remove them because we should enforce for example that objects that are used have the right protocol |label| label := self checkboxLabelForText: aCheckbox label. (label respondsTo: #enabled:) ifTrue: [ label enabled: aCheckbox enabled]. label font: self labelFont. ^label On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:
self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]]
Stef
Fixes for checkbox, Benjamin, please check as I had to revert the CheckboxMorph>>initialize to not hook the click event. Also I notice that tabbing from lists (and shift-tabbing from multiline text) appears to have been broken at some point before these changes. Attached lastest cs Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 3:36 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Indeed.
Hold off on integration for a few mins, some last minute fixes...
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 1:17 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
In the future we will have to look at respondsTo: and remove them because we should enforce for example that objects that are used have the right protocol
|label| label := self checkboxLabelForText: aCheckbox label. (label respondsTo: #enabled:) ifTrue: [ label enabled: aCheckbox enabled]. label font: self labelFont. ^label
On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:
self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]]
Stef
And another... That'll have to do for now. The tab focus things will take quite some investigation... Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 3:52 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Fixes for checkbox, Benjamin, please check as I had to revert the CheckboxMorph>>initialize to not hook the click event.
Also I notice that tabbing from lists (and shift-tabbing from multiline text) appears to have been broken at some point before these changes.
Attached lastest cs
Regards, Gary
----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 3:36 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Indeed.
Hold off on integration for a few mins, some last minute fixes...
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 1:17 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
In the future we will have to look at respondsTo: and remove them because we should enforce for example that objects that are used have the right protocol
|label| label := self checkboxLabelForText: aCheckbox label. (label respondsTo: #enabled:) ifTrue: [ label enabled: aCheckbox enabled]. label font: self labelFont. ^label
On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:
self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]]
Stef
And, as promised, some Android themes... (posting mcz here for those interested). Incomplete and not usable from a "desktop" theme point of view but usable for some things. (plain lists currently having black text on black background etc. amongst other things) Change the theme in settings to one of the Android ones and do UITheme exampleBasicControls to test out. Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 4:06 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
And another...
That'll have to do for now. The tab focus things will take quite some investigation...
Regards, Gary
----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 3:52 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Fixes for checkbox, Benjamin, please check as I had to revert the CheckboxMorph>>initialize to not hook the click event.
Also I notice that tabbing from lists (and shift-tabbing from multiline text) appears to have been broken at some point before these changes.
Attached lastest cs
Regards, Gary
----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 3:36 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Indeed.
Hold off on integration for a few mins, some last minute fixes...
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 1:17 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
In the future we will have to look at respondsTo: and remove them because we should enforce for example that objects that are used have the right protocol
|label| label := self checkboxLabelForText: aCheckbox label. (label respondsTo: #enabled:) ifTrue: [ label enabled: aCheckbox enabled]. label font: self labelFont. ^label
On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:
self allMorphsDo: [:m | (m ~= self and: [m respondsTo: #font:]) ifTrue: [m font: aFont]]
Stef
On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote:
Hi Stef,
I guess you mean to move the resizing bits.
I do not know. I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me. Stef
It is explicit in ExpanderMorph because that's how the title should be in the context of an expander.
The ExpanderTitleMorph *could* be used elsewhere with different properties.
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 10:42 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Gary
I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ?
ExpanderMorph>>defaultTitleMorph "Answer a default title morph for the receiver."
^ExpanderTitleMorph basicNew basicTheme: self theme; initialize; hResizing: #spaceFill; vResizing: #shrinkWrap; basicTheme: nil
On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
Indeed, unfortunately, due to the way it was done all those years ago, many (Poly)morphs create sub/ancillary morphs in the initialize. If the theme is not set they will get created with the current theme, rather than the theme doing the initial creation. I suppose the submorph creation could be done in a separate method and called after initalize and theme setting, a lot more work to do that way though. Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 12:55 PM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote:
Hi Stef,
I guess you mean to move the resizing bits.
I do not know. I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me. Stef
It is explicit in ExpanderMorph because that's how the title should be in the context of an expander.
The ExpanderTitleMorph *could* be used elsewhere with different properties.
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 10:42 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Gary
I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ?
ExpanderMorph>>defaultTitleMorph "Answer a default title morph for the receiver."
^ExpanderTitleMorph basicNew basicTheme: self theme; initialize; hResizing: #spaceFill; vResizing: #shrinkWrap; basicTheme: nil
On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote:
Hi Stef,
I guess you mean to move the resizing bits.
I do not know. I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me. Stef
It is explicit in ExpanderMorph because that's how the title should be in the context of an expander.
The ExpanderTitleMorph *could* be used elsewhere with different properties.
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, April 25, 2012 10:42 AM Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
Gary
I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ?
ExpanderMorph>>defaultTitleMorph "Answer a default title morph for the receiver."
^ExpanderTitleMorph basicNew basicTheme: self theme; initialize; hResizing: #spaceFill; vResizing: #shrinkWrap; basicTheme: nil
On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
esteban, marcus I will integrate these fixes probably in the beginning of the afternoon. Stef On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
Attached cs and description of changes
Regards, Gary <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
participants (5)
-
Benjamin -
Gary Chambers -
Sean P. DeNigris -
Stéphane Ducasse -
Stéphane Ducasse