Transcripter's proper home (was Re: [squeak-dev] The Trunk: Collections-dtl.548.mcz)

> On Sat, Dec 14, 2013 at 09:38:27PM +0100, Nicolas Cellier wrote:
>> But Cuis is Morphic only and does not support MVC, so this is more a rename
>> than unification...
>> Cuis Paragraph is not a subclass of DisplayObject for example.
>>
>
> Yes I understand. As with other MVC/Morphic differences, the solution is
> to let either the current project or the current UI manager handle the
> differences. In this case it should be the project, because Transcripter
> is not a part of either the MVC or Morphic user interface. But to figure
> out how the Morphic parts should, Cuis is the reference.
>
> I have it down to three methods that need to be resolved through the
> current project. I want to see if I can simplify in any more, but in
> any case I'll post soon.

> Dave
>
>>
>> 2013/12/14 David T. Lewis <[hidden email]>
>>
>> > On Sat, Dec 14, 2013 at 03:10:32PM -0500, Colin Putney wrote:
>> > > On Fri, Dec 13, 2013 at 11:06 AM, Frank Shearar <[hidden email]
>> > >wrote:
>> > >
>> > > (a) The emergency evaluator's there _for good reason_.
>> > > > (b) We HAVE two UI frameworks right now. They're part of the standard
>> > > > image.
>> > > > (c) "Stripped" 4.5 base images do not have ST80, so this code is
>> > broken.
>> > > > (d) To fix it _requires_ two separate UI implementations because of
>> > point
>> > > > (b).
>> > > >
>> > >
>> > > I thought the point of the emergency evaluator was that it the fewest
>> > > dependencies possible. Since it scribbles directly on the Display, it
>> > > should work independently of any UI, and thus be useful when the UI is
>> > > broken.
>> > >
>> > > If the EE currently depends on MVC, then we remove that dependency,
>> > rather
>> > > than just generalize the dependency to MVC-or-Morphic. We could either
>> > > rewrite the bit that depends on MVC, or move the functionality that it
>> > does
>> > > depend on out of MVC and into a lower-level part of the system.
>> >
>> > Exactly right.
>> >
>> > I have a working implementation right now, please give me a day or so to
>> > play around with it.
>> >
>> > Whatever I post can go away if someone gets around to unifying NewParagraph
>> > with Paragraph (this is what Juan did in Cuis, and I am borrowing his code
>> > shamelessly).
>> >
>> > Dave
>> >
>> >
>> >
>
>>
>
>

> On 14 December 2013 20:58, David T. Lewis <[hidden email]> wrote:
> > On Sat, Dec 14, 2013 at 09:38:27PM +0100, Nicolas Cellier wrote:
> >> But Cuis is Morphic only and does not support MVC, so this is more a rename
> >> than unification...
> >> Cuis Paragraph is not a subclass of DisplayObject for example.
> >>
> >
> > Yes I understand. As with other MVC/Morphic differences, the solution is
> > to let either the current project or the current UI manager handle the
> > differences. In this case it should be the project, because Transcripter
> > is not a part of either the MVC or Morphic user interface. But to figure
> > out how the Morphic parts should, Cuis is the reference.
> >
> > I have it down to three methods that need to be resolved through the
> > current project. I want to see if I can simplify in any more, but in
> > any case I'll post soon.
>
> I confess to causing Dave and everyone else some measure of
> unhappiness in shoving Transcripter around. Thanks, Dave, for
> restoring Transcripter to its original glory AND BETTER, because it
> now works in both Morphic and ST80.

>
> One small niggle remains. Transcripter's still in the wrong package.
> Where should it live? I'm tempted to say "System" because that's
> currently the home of all the other application-level hook points (the
> AppRegistry subclasses, for instance). I say "tempted" because I do
> tend to rant about the size of System, and how it does too many
> things. However, System does form, at present at least, a reasonable
> point of separation between "core" stuff and "UI" stuff (Morphic,
> ST80).
>
> So, before I put my foot in it again, I'd like to propose that we move
> Transcripter to System because
> * it breaks another strand in the Collections -> System dependency, and
> * System's where all the other "UI and higher" hook points already live.
>
> Yea? Nay?

> On Sat, Dec 28, 2013 at 10:32:11PM +0000, Frank Shearar wrote:
>> On 14 December 2013 20:58, David T. Lewis <[hidden email]> wrote:
>> > On Sat, Dec 14, 2013 at 09:38:27PM +0100, Nicolas Cellier wrote:
>> >> But Cuis is Morphic only and does not support MVC, so this is more a rename
>> >> than unification...
>> >> Cuis Paragraph is not a subclass of DisplayObject for example.
>> >>
>> >
>> > Yes I understand. As with other MVC/Morphic differences, the solution is
>> > to let either the current project or the current UI manager handle the
>> > differences. In this case it should be the project, because Transcripter
>> > is not a part of either the MVC or Morphic user interface. But to figure
>> > out how the Morphic parts should, Cuis is the reference.
>> >
>> > I have it down to three methods that need to be resolved through the
>> > current project. I want to see if I can simplify in any more, but in
>> > any case I'll post soon.
>>
>> I confess to causing Dave and everyone else some measure of
>> unhappiness in shoving Transcripter around. Thanks, Dave, for
>> restoring Transcripter to its original glory AND BETTER, because it
>> now works in both Morphic and ST80.
>
> No problem at all from my POV. We ended up fixing a problem that none
> of us even knew was a problem, so I am happy with the outcome.
>
>>
>> One small niggle remains. Transcripter's still in the wrong package.
>> Where should it live? I'm tempted to say "System" because that's
>> currently the home of all the other application-level hook points (the
>> AppRegistry subclasses, for instance). I say "tempted" because I do
>> tend to rant about the size of System, and how it does too many
>> things. However, System does form, at present at least, a reasonable
>> point of separation between "core" stuff and "UI" stuff (Morphic,
>> ST80).
>>
>> So, before I put my foot in it again, I'd like to propose that we move
>> Transcripter to System because
>> * it breaks another strand in the Collections -> System dependency, and
>> * System's where all the other "UI and higher" hook points already live.
>>
>> Yea? Nay?
>
> I have no strong opinions one or or another, just as long as it goes in
> some category that makes logical sense. I think that the Transcripter
> probably originally went into Collections because it was implemented as
> a kind of collection. But if it makes more sense to consider it as part
> of System that is fine with me. It is important that the Transcripter be
> independent of the UI framework (MVC, Morphic, ...) and putting it in
> System is harmless from that point of standpoint, so +1 from me.