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> |
In reply to this post by Gary Chambers-4
<base href="x-msg://850/">Do you have an example where the DropListMorph wrapSelector is broken ?
Ben On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
|
In reply to this post by Gary Chambers-4
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> |
In reply to this post by Gary Chambers-4
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> |
In reply to this post by Benjamin Van Ryseghem (Pharo)
<BASE
href="x-msg://850/">
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
|
In reply to this post by Stéphane Ducasse
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" <[hidden email]> To: <[hidden email]> 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> |
In reply to this post by Gary Chambers-4
<base href="x-msg://850/">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:
|
In reply to this post by Gary Chambers-4
<base href="x-msg://850/">
Ok, found why :) This fix it for me :) Can you have a quick look ? Thanks in advance, Ben <base href="x-msg://850/"> On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:
DropListMorph-wrapSelector.st (370 bytes) Download Attachment |
In reply to this post by Gary Chambers-4
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 |
In reply to this post by Gary Chambers-4
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" <[hidden email]> > To: <[hidden email]> > 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> > > > |
In reply to this post by Gary Chambers-4
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" <[hidden email]> > To: <[hidden email]> > 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> > > > |
In reply to this post by Benjamin Van Ryseghem (Pharo)
<BASE
href="x-msg://850/">
Yep, that's what I expected as fix ;-)
Regards, Gary
|
In reply to this post by Stéphane Ducasse
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" <[hidden email]> To: <[hidden email]> 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" > <[hidden email]> > To: <[hidden email]> > 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> > > > |
In reply to this post by Stéphane Ducasse
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" <[hidden email]> To: <[hidden email]> 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 |
In reply to this post by Stéphane Ducasse
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" <[hidden email]> To: <[hidden email]> 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" <[hidden email]> To: <[hidden email]> 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" <[hidden email]> > To: <[hidden email]> > 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 > > > Pharo2.0Changes.6.cs (107K) Download Attachment |
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" <[hidden email]> To: <[hidden email]> 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" <[hidden email]> > To: <[hidden email]> > 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" <[hidden email]> >> To: <[hidden email]> >> 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 >> >> >> > Pharo2.0Changes.7.cs (107K) Download Attachment |
Administrator
|
In reply to this post by Gary Chambers-4
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.
Cheers,
Sean |
Free forum by Nabble | Edit this page |