On 1 January 2014 19:25, David T. Lewis <lewis at 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 at 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