TextAttribute's #actonClickFor: - what package?

> 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?)

> On 28 December 2013 23:06, Frank Shearar <[hidden email]> 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.
>

> On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
>> On 28 December 2013 23:06, Frank Shearar <[hidden email]> 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).

> On 31 December 2013 18:11, David T. Lewis <[hidden email]> wrote:
> > On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
> >> On 28 December 2013 23:06, Frank Shearar <[hidden email]> 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.
>

> On Tue, Dec 31, 2013 at 09:21:13PM +0000, Frank Shearar wrote:
>> On 31 December 2013 18:11, David T. Lewis <[hidden email]> wrote:
>> > On Tue, Dec 31, 2013 at 05:35:30PM +0000, Frank Shearar wrote:
>> >> On 28 December 2013 23:06, Frank Shearar <[hidden email]> 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.

> On 1 January 2014 17:55, David T. Lewis <[hidden email]> 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.
>

> On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
>> On 1 January 2014 17:55, David T. Lewis <[hidden email]> 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.

> On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
>> On 1 January 2014 17:55, David T. Lewis <[hidden email]> 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.

> On 1 January 2014 19:25, David T. Lewis <[hidden email]> wrote:
> > On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
> >> On 1 January 2014 17:55, David T. Lewis <[hidden email]> 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?
>

> On Thu, Jan 02, 2014 at 09:31:36AM +0000, Frank Shearar wrote:
> > On 1 January 2014 19:25, David T. Lewis <[hidden email]> wrote:
> > > On Wed, Jan 01, 2014 at 06:25:27PM +0000, Frank Shearar wrote:
> > >> On 1 January 2014 17:55, David T. Lewis <[hidden email]> 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.