As far as I know, this happens because now a TextMorph has a styler
strategy. By default, the styler is the NullStyler but it can be set
from outside to be something else (like a ShoutStyler).
Like that you have the two concerns (editing, and highlighting) nicely
supported by the framework without requiring subclassing.
So, I would say that the simplest way to go around this problem and
still be somewhat backward compatible would be to renamed styler to
shoutStyler in the PluggableShoutMorph.
Cheers,
Doru
On 15 Aug 2010, at 18:48, Mariano Martinez Peck wrote:
On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <[email protected]>
wrote:
> Lukas, Shout won't load in Pharo 1.2 because of issue
>
> http://code.google.com/p/pharo/issues/detail?id=2734
I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate.
I guess PluggableTextMorph should be fixed, or why was this instance
variable added? Is this coming from Squeak?
I have no idea. I asked several times if someone can fix it...
I am trying to start building PharoDev on top of PharoCore 1.2 but I
have this problem.
Lukas
>
> :(
>
>>
>> Lukas
>>
>> >
>> >
>> > The problem are the external pacakges. I have 100 references to
>> > Preferences in Pharo dev....almost EVERY external package uses
Preferences.
>> > So....we really need help of the external package maintainers
to update
>> > them. And I am not sure how easy is that.
>> > What should be easy is to have a Preferences class that
supports the
>> > simple API that everyone was using: add a preference. And make
>> > Preferenceclass return true or false for that preference. That
should be 90%
>> > of all usages, I guess..
>> > We can do that by just having a dictionary and overriding
>> > doesNotUnderstand:. We should not provide all this magic that
used to be
>> > there, e.g.compiling on the fly methods for accessed
perferences (which
>> > funnily had an empty source pointer...).
>> > I mean...is there a mapping between each previous preference a
the new
>> > ones?
>> >
>> >
>> > In 1.1, Preferences are returning the values from the Settings
framework
>> > for backward compatibillity.
>> > But I don't think that Preferences added are shown in the
Settings? This
>> > would require Settings to be generated, which is possible but I
thinknot
>> > really what we want.
>> > One could of course build this specification for the
Preferences... and
>> > maybe there was even code there for that ;-) I started the
cleanup bu
>> > removingunsent messages... but after a while that got really
boring. And
>> > Preferences was a near 2000 LOC abdomination of a class.
>> > I checked in 1.1Dev, and most of the references are from the
Core, which
>> > we removed in 1.2...
>> > Marcus
>> >
>> >
>> > --Marcus Denker
>> > -- http://www.marcusdenker.de <http://www.marcusdenker.de/>
>> > INRIA Lille -- Nord Europe. Team RMoD.
>> >
>> >
>> >
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
