SystemWindow
knownName ^label ___________ Morphic knownName "answer a name by which the receiver is known, or nil if none" ^ extension ifNotNil: [extension externalName] _____________ I modified and tested the attached. -jrm SystemWindow-knownName.st (394 bytes) Download Attachment |
"SystemWindow #knownName violates principle of least astonishment" Care to explain? Best regards -Tobias > On 12.12.2017, at 22:33, John-Reed Maffeo <[hidden email]> wrote: > > SystemWindow > knownName > > ^label > > ___________ > > Morphic > knownName > "answer a name by which the receiver is known, or nil if none" > ^ extension ifNotNil: [extension externalName] > > _____________ > > I modified and tested the attached. > > -jrm > <SystemWindow-knownName.st> |
Tobias, The application I am building uses #SystemWindow. The window has a model which contains the application program logic. One of the methods in my model wants to access the #SystemWindow so I gave it a name. When I tried to access the system window by name I got the label of the window and not the name I gave it (I was astonished!). As I dug through the code, I saw that the #knownName methods in #Morph and #SystemWindow return different values. Note: I am still a newbie andMorphic has been a mystery to me for a long time . I can work around the issue, but I was surprised, and confused by the fact that I was not getting the result I expected when I tried to access my application system window by the name I had given it. My design is probably bollocks and I don't really need to access the system window from the model, but I thought it was something deserved review. Thanks for taking and interest, -jrm On Tue, Dec 12, 2017 at 5:51 PM, Tobias Pape <[hidden email]> wrote:
|
Hi John-Reed, hi Tobias, I think that this is not the SystemWindow's fault but "name" as a concept for morphs is kind of broken. See the following methods in the Morph class: #innocuousName #name: #nameInModel #setNameTo: #tryToRenameTo: #knownName #renameInternal: #renameTo: #externalName I suspect that this has happened due to missing task-specific means of configuration. Like #printString, there can only be one to be used by all applications and tools. Here, the terms "internal" and "external" and "known" suggest that somebody tried to add such kind of configuration for "name". Without success, I would conclude. :-) Best, Marcel
|
Hello
It looks like a bug in the implementation of SystemWindow>>knownName John's proposal for a fix is 'From Squeak5.1 of 5 September 2016 [latest update: #16549] on 12 December 2017 at 2:25:14 pm'! !SystemWindow methodsFor: 'label' stamp: 'jrm 12/12/2017 14:23'! knownName "answer label if extension is nil" extension externalName ifNil:[^self label]. ^ extension externalName! ! or with relying on the implementation in Morph SystemWindow>>knownName | n | n := super knownName. n isNil ifTrue: [^self label] ifFalse: [^n] This implemenentation assumes that setting a label to a SystemWindow is the same as giving it a name with setNameTo: --Hannes On 12/13/17, Marcel Taeumel <[hidden email]> wrote: > Hi John-Reed, hi Tobias, > > I think that this is not the SystemWindow's fault but "name" as a concept > for morphs is kind of broken. See the following methods in the Morph class: > > #innocuousName > #name: > #nameInModel > #setNameTo: > #tryToRenameTo: > #knownName > #renameInternal: > #renameTo: > #externalName > > I suspect that this has happened due to missing task-specific means of > configuration. Like #printString, there can only be one to be used by all > applications and tools. Here, the terms "internal" and "external" and > "known" suggest that somebody tried to add such kind of configuration for > "name". Without success, I would conclude. :-) > > Best, > Marcel > Am 13.12.2017 03:00:50 schrieb John-Reed Maffeo <[hidden email]>: > Tobias, > > The application I am building uses #SystemWindow. The window has a model > which contains the application program logic. One of the methods in my model > wants to access the #SystemWindow so I gave it a name. When I tried to > access the system window by name I got the label of the window and not the > name I gave it (I was astonished!). As I dug through the code, I saw that > the #knownName methods in #Morph and #SystemWindow return different > values. > > Note: I am still a newbie andMorphic has been a mystery to me for a long > time . > > I can work around the issue, but I was surprised, and confused by the fact > that I was not getting the result I expected when I tried to access my > application system window by the name I had given it. My design is probably > bollocks and I don't really need to access the system window from the model, > but I thought it was something deserved review. > > http://wiki.c2.com/?PrincipleOfLeastAstonishment > [http://wiki.c2.com/?PrincipleOfLeastAstonishment] > > > Thanks for taking and interest, > > -jrm > > > > On Tue, Dec 12, 2017 at 5:51 PM, Tobias Pape <[hidden email] > [mailto:[hidden email]]> wrote: > > > "SystemWindow #knownName violates principle of least astonishment" > > Care to explain? > > Best regards > -Tobias > > >> On 12.12.2017, at 22:33, John-Reed Maffeo <[hidden email] >> [mailto:[hidden email]]> wrote: >> >> SystemWindow >> knownName >> >> ^label >> >> ___________ >> >> Morphic >> knownName >> "answer a name by which the receiver is known, or nil if none" >> ^ extension ifNotNil: [extension externalName] >> >> _____________ >> >> I modified and tested the attached. >> >> -jrm > >> <SystemWindow-knownName.st> > > > > |
Free forum by Nabble | Edit this page |