[squeak-dev] TextAttribute updates in inbox (was: TextAttribute's #actonClickFor: - what package?)

David T. Lewis lewis at mail.msen.com
Thu Jan 2 21:06:48 UTC 2014


On Thu, Jan 02, 2014 at 08:23:36AM -0500, David T. Lewis wrote:
> On Thu, Jan 02, 2014 at 09:31:36AM +0000, Frank Shearar wrote:
> > 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?
> > 
> 
> 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.

CollectionsTests-dtl.209, Collections-dtl.556, and System-dtl.656 are
my proposed changes for addressing this. These are in the inbox because
the changes to text attribute classes touch a lot of code.

In the course of doing the unit tests, I tripped over some classes that
have incomplete implementations with respect to fileout and filein.
These are classes that appear to be unused or redundant, and can probably
be removed from the image. They are:

	testTextAnchor
	testTextIndent
	testTextMessageLink
	testTextPlusJumpStart
	testTextPlusJumpEnd

The test for PluggableTextAttribute shows a real failure (a preexisting
condition), though this may not be terribly important.

Dave




More information about the Squeak-dev mailing list