Most of these are unclassified, except for TextURL's, which lives in Morphic. (This method references Morph directly, through an #isKindOf:.)
Now the name strongly suggests that the method/group of methods belongs to a graphical UI, which makes me think that Morphic is, indeed, the place for them to live.
But is it really? Could these methods live in Morphic for now, or do they really belong to a layer just below Morphic and ST80? (We see quite a few things in the image that are parts of or support for a GUI, but not any specific GUI. Transcripter, for instance. Is this layer the Graphics package?)
frank
On 28 December 2013 23:06, Frank Shearar frank.shearar@gmail.com wrote:
Most of these are unclassified, except for TextURL's, which lives in Morphic. (This method references Morph directly, through an #isKindOf:.)
Now the name strongly suggests that the method/group of methods belongs to a graphical UI, which makes me think that Morphic is, indeed, the place for them to live.
But is it really? Could these methods live in Morphic for now, or do they really belong to a layer just below Morphic and ST80? (We see quite a few things in the image that are parts of or support for a GUI, but not any specific GUI. Transcripter, for instance. Is this layer the Graphics package?)
I'm tempted to just move these to Morphic. If we want the selectors to work in ST80 - and I don't know that - we'll need to work a fair bit on separating out the logic anyway. Moving the selectors to Morphic will at least solve one small part of the problem.
frank
On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
On 28 December 2013 23:06, Frank Shearar frank.shearar@gmail.com wrote:
Most of these are unclassified, except for TextURL's, which lives in Morphic. (This method references Morph directly, through an #isKindOf:.)
Now the name strongly suggests that the method/group of methods belongs to a graphical UI, which makes me think that Morphic is, indeed, the place for them to live.
But is it really? Could these methods live in Morphic for now, or do they really belong to a layer just below Morphic and ST80? (We see quite a few things in the image that are parts of or support for a GUI, but not any specific GUI. Transcripter, for instance. Is this layer the Graphics package?)
I'm tempted to just move these to Morphic. If we want the selectors to work in ST80 - and I don't know that - we'll need to work a fair bit on separating out the logic anyway. Moving the selectors to Morphic will at least solve one small part of the problem.
A quick look at senders suggests that these methods are intended for use in any UI framework, not just Morphic. For example #actOnClickFor:in:at:editor: is sent by both Paragraph (MVC) and NewParagraph (Morphic).
Perhaps you can just give them a meaningful method category?
Dave
On 31 December 2013 18:11, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
On 28 December 2013 23:06, Frank Shearar frank.shearar@gmail.com wrote:
Most of these are unclassified, except for TextURL's, which lives in Morphic. (This method references Morph directly, through an #isKindOf:.)
Now the name strongly suggests that the method/group of methods belongs to a graphical UI, which makes me think that Morphic is, indeed, the place for them to live.
But is it really? Could these methods live in Morphic for now, or do they really belong to a layer just below Morphic and ST80? (We see quite a few things in the image that are parts of or support for a GUI, but not any specific GUI. Transcripter, for instance. Is this layer the Graphics package?)
I'm tempted to just move these to Morphic. If we want the selectors to work in ST80 - and I don't know that - we'll need to work a fair bit on separating out the logic anyway. Moving the selectors to Morphic will at least solve one small part of the problem.
A quick look at senders suggests that these methods are intended for use in any UI framework, not just Morphic. For example #actOnClickFor:in:at:editor: is sent by both Paragraph (MVC) and NewParagraph (Morphic).
That's what I thought :( They're not written in a way appropriate to supporting multiple UIs though. Well, actually, they're almost all completely UI independent, except for TextURL's "anObject isKindOf: Morph". OK, scratch the move-to-Morphic idea.
Perhaps you can just give them a meaningful method category?
Well, I could punt them into System. System isn't a _terrible_ home. It's the highest layer we have before heading up into Morphic or ST80. Most of the classes these methods use are System: Project, ProjectLoading. Possibly the "right" solution is to route stuff through UIManager.
I don't want them in Collection mainly because of the references to System classes. The Collection package shouldn't depend on System, and there's no way we can make System not depend on Collection. Cycles, cycles, wheels within wheels.
frank
Dave
On Tue, Dec 31, 2013 at 09:21:13PM +0000, Frank Shearar wrote:
On 31 December 2013 18:11, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
On 28 December 2013 23:06, Frank Shearar frank.shearar@gmail.com wrote:
Most of these are unclassified, except for TextURL's, which lives in Morphic. (This method references Morph directly, through an #isKindOf:.)
Now the name strongly suggests that the method/group of methods belongs to a graphical UI, which makes me think that Morphic is, indeed, the place for them to live.
But is it really? Could these methods live in Morphic for now, or do they really belong to a layer just below Morphic and ST80? (We see quite a few things in the image that are parts of or support for a GUI, but not any specific GUI. Transcripter, for instance. Is this layer the Graphics package?)
I'm tempted to just move these to Morphic. If we want the selectors to work in ST80 - and I don't know that - we'll need to work a fair bit on separating out the logic anyway. Moving the selectors to Morphic will at least solve one small part of the problem.
A quick look at senders suggests that these methods are intended for use in any UI framework, not just Morphic. For example #actOnClickFor:in:at:editor: is sent by both Paragraph (MVC) and NewParagraph (Morphic).
That's what I thought :( They're not written in a way appropriate to supporting multiple UIs though. Well, actually, they're almost all completely UI independent, except for TextURL's "anObject isKindOf: Morph". OK, scratch the move-to-Morphic idea.
Perhaps you can just give them a meaningful method category?
Well, I could punt them into System. System isn't a _terrible_ home. It's the highest layer we have before heading up into Morphic or ST80. Most of the classes these methods use are System: Project, ProjectLoading. Possibly the "right" solution is to route stuff through UIManager.
I don't want them in Collection mainly because of the references to System classes. The Collection package shouldn't depend on System, and there's no way we can make System not depend on Collection. Cycles, cycles, wheels within wheels.
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
Thanks, Dave
On 1 January 2014 17:55, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Dec 31, 2013 at 09:21:13PM +0000, Frank Shearar wrote:
On 31 December 2013 18:11, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
On 28 December 2013 23:06, Frank Shearar frank.shearar@gmail.com wrote:
Most of these are unclassified, except for TextURL's, which lives in Morphic. (This method references Morph directly, through an #isKindOf:.)
Now the name strongly suggests that the method/group of methods belongs to a graphical UI, which makes me think that Morphic is, indeed, the place for them to live.
But is it really? Could these methods live in Morphic for now, or do they really belong to a layer just below Morphic and ST80? (We see quite a few things in the image that are parts of or support for a GUI, but not any specific GUI. Transcripter, for instance. Is this layer the Graphics package?)
I'm tempted to just move these to Morphic. If we want the selectors to work in ST80 - and I don't know that - we'll need to work a fair bit on separating out the logic anyway. Moving the selectors to Morphic will at least solve one small part of the problem.
A quick look at senders suggests that these methods are intended for use in any UI framework, not just Morphic. For example #actOnClickFor:in:at:editor: is sent by both Paragraph (MVC) and NewParagraph (Morphic).
That's what I thought :( They're not written in a way appropriate to supporting multiple UIs though. Well, actually, they're almost all completely UI independent, except for TextURL's "anObject isKindOf: Morph". OK, scratch the move-to-Morphic idea.
Perhaps you can just give them a meaningful method category?
Well, I could punt them into System. System isn't a _terrible_ home. It's the highest layer we have before heading up into Morphic or ST80. Most of the classes these methods use are System: Project, ProjectLoading. Possibly the "right" solution is to route stuff through UIManager.
I don't want them in Collection mainly because of the references to System classes. The Collection package shouldn't depend on System, and there's no way we can make System not depend on Collection. Cycles, cycles, wheels within wheels.
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
No, although I wouldn't mind seeing a separate text-handling package at some point, rather than having String and Text in the same package as Array and Dictionary.
I mean that TextSqkProjectLink >> #actOnClick: methods references Project. That's the cause of the dependency. Doing one of those horrible "dynamic dependency" things just doesn't seem like the right thing. If we could find a way to route this particular Project reference through UIManager, for instance, that would address my immediate concerns.
frank
Thanks, Dave
On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
On 1 January 2014 17:55, David T. Lewis lewis@mail.msen.com wrote:
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
No, although I wouldn't mind seeing a separate text-handling package at some point, rather than having String and Text in the same package as Array and Dictionary.
I mean that TextSqkProjectLink >> #actOnClick: methods references Project. That's the cause of the dependency. Doing one of those horrible "dynamic dependency" things just doesn't seem like the right thing. If we could find a way to route this particular Project reference through UIManager, for instance, that would address my immediate concerns.
Thanks, I see it now.
A TextSqkProjectLink is logically associated with projects, which are a part of System-Support, so that dependency makes sense. It's not a UI thing, so routing through UIManager would not be right.
Putting TextSqkProjectLink into the system package along with Project might be sensible, although there are some other dependencies to sort out before that can be done. I'll try to follow up on that later if noone else gets to it first.
Dave
On 1 January 2014 19:25, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
On 1 January 2014 17:55, David T. Lewis lewis@mail.msen.com wrote:
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
No, although I wouldn't mind seeing a separate text-handling package at some point, rather than having String and Text in the same package as Array and Dictionary.
I mean that TextSqkProjectLink >> #actOnClick: methods references Project. That's the cause of the dependency. Doing one of those horrible "dynamic dependency" things just doesn't seem like the right thing. If we could find a way to route this particular Project reference through UIManager, for instance, that would address my immediate concerns.
Thanks, I see it now.
A TextSqkProjectLink is logically associated with projects, which are a part of System-Support, so that dependency makes sense. It's not a UI thing, so routing through UIManager would not be right.
I'd mentioned UIManager just because these methods are about a user clicking on some piece of text, and because MorphicUIManager uses Project (in its #restoreDisplay). Moving TextSqkProjectLink to System-Support sounds sensible.
Putting TextSqkProjectLink into the system package along with Project might be sensible, although there are some other dependencies to sort out before that can be done. I'll try to follow up on that later if noone else gets to it first.
That would be great! I'm hip deep in looking over Colin's big chunk of Environment change, and trying to figure out whether my Monticello changes are completely broken, or just broken because Environments might work slightly differently now.
frank
Dave
On 1 January 2014 19:25, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
On 1 January 2014 17:55, David T. Lewis lewis@mail.msen.com wrote:
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
No, although I wouldn't mind seeing a separate text-handling package at some point, rather than having String and Text in the same package as Array and Dictionary.
I mean that TextSqkProjectLink >> #actOnClick: methods references Project. That's the cause of the dependency. Doing one of those horrible "dynamic dependency" things just doesn't seem like the right thing. If we could find a way to route this particular Project reference through UIManager, for instance, that would address my immediate concerns.
Thanks, I see it now.
A TextSqkProjectLink is logically associated with projects, which are a part of System-Support, so that dependency makes sense. It's not a UI thing, so routing through UIManager would not be right.
Putting TextSqkProjectLink into the system package along with Project might be sensible, although there are some other dependencies to sort out before that can be done. I'll try to follow up on that later if noone else gets to it first.
You mean like making RunArray >> #scanFrom: use a registry, so that it doesn't know of TextSqkProjectLink and TextSqkPageLink directly?
frank
Dave
On Thu, Jan 02, 2014 at 09:31:36AM +0000, Frank Shearar wrote:
On 1 January 2014 19:25, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
On 1 January 2014 17:55, David T. Lewis lewis@mail.msen.com wrote:
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
No, although I wouldn't mind seeing a separate text-handling package at some point, rather than having String and Text in the same package as Array and Dictionary.
I mean that TextSqkProjectLink >> #actOnClick: methods references Project. That's the cause of the dependency. Doing one of those horrible "dynamic dependency" things just doesn't seem like the right thing. If we could find a way to route this particular Project reference through UIManager, for instance, that would address my immediate concerns.
Thanks, I see it now.
A TextSqkProjectLink is logically associated with projects, which are a part of System-Support, so that dependency makes sense. It's not a UI thing, so routing through UIManager would not be right.
Putting TextSqkProjectLink into the system package along with Project might be sensible, although there are some other dependencies to sort out before that can be done. I'll try to follow up on that later if noone else gets to it first.
You mean like making RunArray >> #scanFrom: use a registry, so that it doesn't know of TextSqkProjectLink and TextSqkPageLink directly?
Sort of like that but no registry should be needed. I'm writing some unit tests first to make sure we don't break the fileIn/fileOut mechanism. It looks like there are some incomplete implementations in TextAttribute subclasses too, I'm not sure if this matters. I'll post something this weekend if not before.
Dave
On Thu, Jan 02, 2014 at 08:23:36AM -0500, David T. Lewis wrote:
On Thu, Jan 02, 2014 at 09:31:36AM +0000, Frank Shearar wrote:
On 1 January 2014 19:25, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
On 1 January 2014 17:55, David T. Lewis lewis@mail.msen.com wrote:
I think I am misunderstanding something. What is the dependency that is causing a problem? I can see that the #actOnClick methods are serving to dispatch things for handling mouse click events, and that this is related to UI processing (Morphic and MVC so far). But I don't see where those methods are causing a package dependency problem.
Or are you saying that class TextAttribute itself does not belong in Collections? Sorry, I think I am just misunderstanding the problem here.
No, although I wouldn't mind seeing a separate text-handling package at some point, rather than having String and Text in the same package as Array and Dictionary.
I mean that TextSqkProjectLink >> #actOnClick: methods references Project. That's the cause of the dependency. Doing one of those horrible "dynamic dependency" things just doesn't seem like the right thing. If we could find a way to route this particular Project reference through UIManager, for instance, that would address my immediate concerns.
Thanks, I see it now.
A TextSqkProjectLink is logically associated with projects, which are a part of System-Support, so that dependency makes sense. It's not a UI thing, so routing through UIManager would not be right.
Putting TextSqkProjectLink into the system package along with Project might be sensible, although there are some other dependencies to sort out before that can be done. I'll try to follow up on that later if noone else gets to it first.
You mean like making RunArray >> #scanFrom: use a registry, so that it doesn't know of TextSqkProjectLink and TextSqkPageLink directly?
Sort of like that but no registry should be needed. I'm writing some unit tests first to make sure we don't break the fileIn/fileOut mechanism. It looks like there are some incomplete implementations in TextAttribute subclasses too, I'm not sure if this matters. I'll post something this weekend if not before.
CollectionsTests-dtl.209, Collections-dtl.556, and System-dtl.656 are my proposed changes for addressing this. These are in the inbox because the changes to text attribute classes touch a lot of code.
In the course of doing the unit tests, I tripped over some classes that have incomplete implementations with respect to fileout and filein. These are classes that appear to be unused or redundant, and can probably be removed from the image. They are:
testTextAnchor testTextIndent testTextMessageLink testTextPlusJumpStart testTextPlusJumpEnd
The test for PluggableTextAttribute shows a real failure (a preexisting condition), though this may not be terribly important.
Dave
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Frank Shearar