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