On Aug 15, 2010, at 7:03 PM, Tudor Girba wrote:
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.
why not but having a 1.2 version would solve the problem too.
Cheers, Doru
On 15 Aug 2010, at 18:48, Mariano Martinez Peck wrote:
On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <renggli@gmail.com> wrote:
Lukas, Shout won't load in Pharo 1.2 because of issue
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project