isTextMorph

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

isTextMorph

Eliot Miranda-2
Hi All,

    I notice that TextMorph answers true to isTextMorph but PluggableTextMorph & PluggableTextMorphPlus answer false.  Instead PluggableTextMorph implements isTextView.

Is this a bug or by design?  Will the world collapse if I implement PluggableTextMorph>>isTextMorph to answer true?
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: isTextMorph

Chris Muller-3
I have no idea the answer, but it's a curious question.  A quick look
at the api differences vs. similarities and, just by those numbers, it
doesn't look good..   :/

"explore it"
| tm ptm |
tm := TextMorph methodDictionary keys.
ptm := PluggableTextMorph methodDictionary keys.
{  {'TextMorph-specific'. tm difference: ptm. }.
{'PluggableTextMorph-specific'.  ptm difference: tm}.
{'Common'.  ptm intersection: tm.} }




On Sun, Jun 3, 2018 at 1:30 PM, Eliot Miranda <[hidden email]> wrote:

> Hi All,
>
>     I notice that TextMorph answers true to isTextMorph but
> PluggableTextMorph & PluggableTextMorphPlus answer false.  Instead
> PluggableTextMorph implements isTextView.
>
> Is this a bug or by design?  Will the world collapse if I implement
> PluggableTextMorph>>isTextMorph to answer true?
> _,,,^..^,,,_
> best, Eliot
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: isTextMorph

timrowledge
A bigger and more interesting question is why on earth we have three distinct classes. I suspect unfinished experiments that got glommed into the system without adequate thought and left there because nobody knows what the hell was really intended.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Earth is 98% full...please delete anyone you can.



Reply | Threaded
Open this post in threaded view
|

Re: isTextMorph

Chris Muller-3
I suspect if you spent half as much time reading the code as
your thesaurus, you may find the answer.   :)

They serve at different layers of abstraction, necessarily.


On Sun, Jun 3, 2018 at 3:30 PM, tim Rowledge <[hidden email]> wrote:
> A bigger and more interesting question is why on earth we have three distinct classes. I suspect unfinished experiments that got glommed into the system without adequate thought and left there because nobody knows what the hell was really intended.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Earth is 98% full...please delete anyone you can.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: isTextMorph

Jakob Reschke
In reply to this post by timrowledge
PluggableTextMorph is the MorphicToolBuilder variant of MVC's PluggableTextView, whereas I assume TextMorph is the original Morphic thing ported from Self. The purpose of the latter is to display text in Morphic and the purpose of the former is to display (and edit) text in tools. The pluggable morph contains a "non-pluggable" one. So, to me it looks like these two should not be confused, regarding #isTextMorph and #isTextView.

Regarding PluggableTextMorphPlus and the fact that PluggableTextMorph does not have a class comment, Tim might have a point. The Plus class does have a comment: "A pluggable text morph with support for color." But since any (Pluggable)TextMorph also supports colored text somehow, this explanation is a little too brief. It adds support for accessing the color from the model and adds the optional text styler for syntax highlighting. ...and an acceptAction, but this is definitely not captured in the class comment.

Anyway, PluggableTextMorph*Plus* is what MorphicToolBuilder builds when you ask for a pluggable text, be it for code or plain text.

It is unfortunate that MVC (or anything else) does not benefit from text styling (or any further customization, such as spell checker marks) this way, although Text and its color support are not specific to Morphic.


tim Rowledge <[hidden email]> schrieb am So., 3. Juni 2018, 22:31:
A bigger and more interesting question is why on earth we have three distinct classes. I suspect unfinished experiments that got glommed into the system without adequate thought and left there because nobody knows what the hell was really intended.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Earth is 98% full...please delete anyone you can.





Reply | Threaded
Open this post in threaded view
|

Re: isTextMorph

timrowledge


> On 03-06-2018, at 3:15 PM, Jakob Reschke <[hidden email]> wrote:
>
[snip]

> Regarding PluggableTextMorphPlus and the fact that PluggableTextMorph does not have a class comment, Tim might have a point. The Plus class does have a comment: "A pluggable text morph with support for color." But since any (Pluggable)TextMorph also supports colored text somehow, this explanation is a little too brief. It adds support for accessing the color from the model and adds the optional text styler for syntax highlighting. ...and an acceptAction, but this is definitely not captured in the class comment.

The comment is definitely inadequate since that class adds stuff that seems to be to support Shout styling and also adds another layer of accept related action customisation. An important basic tool related class like PluggableTextMorph having no comment that gives us a decent description of what it is for is not helpful. I suspect that the two could be merged to good effect.
>
> Anyway, PluggableTextMorph*Plus* is what MorphicToolBuilder builds when you ask for a pluggable text, be it for code or plain text.

Exactly - so is there real value in the non-Plus class?

TextMorph is interesting because amongst other things it is (well the TextMorphForEditView subclass) wrapped into a PluggableTextMorphPlus. It does have a comment, which is nice (special pun hidden in there).  Wrapping a 'single minded' morph to  make a pluggable one can be useful but you also get stuck with having to forward a load of messages and remembering that you are wrapping a class that can change. We have to hope that everyone that ever changes the wrapped class remembers to update the wrapper to keep things working.  I suggest that it is easier on everyone if the 'root' class is pluggable and has defaults for the pluggable parts that make it easy to use as a single minded object.

I'm fairly sure that things could be drastically simplified. Simpler is easier to document and easier to maintain and easier to improve. Simpler is very often better.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Base 8 is just like base 10, if you are missing two fingers.