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.

Thanks,
Dave