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