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