Aaah, the pain or ParagraphEditor refactoring ;-)

Hi all,

while further battling full unicode support I ended up refactoring
ParagraphEditor to the extend that there a no references to the inst var
sensor left. There are still a few references to the global Sensor though.

With moving the model inst var down we could now basically get rid of
class Controller :-)

Class KeyboardBuffer is gone already.

All that needs to be done is moving the utility methods in
ScreenController to e.g. Display so we can remove that subclass of
Controller as well.

Volunteers?

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael,

Do you mean:

fullScreen:
fullScreenOff
fullScreenOn
isFullScreen
lastScreenModeSelected
toggleFullScreen

???

I mean, that actually looks like something I can handle if you think of me like a first year apprentice who needs very specific instructions!  Where do you want them to go?  It's the whole change set thing that always takes me a while to figure out...!

Rob

On Mon, Feb 23, 2009 at 10:06 PM, Michael Rueger <[hidden email]> wrote:

Hi all,

while further battling full unicode support I ended up refactoring
ParagraphEditor to the extend that there a no references to the inst var
sensor left. There are still a few references to the global Sensor though.

With moving the model inst var down we could now basically get rid of
class Controller :-)

Class KeyboardBuffer is gone already.

All that needs to be done is moving the utility methods in
ScreenController to e.g. Display so we can remove that subclass of
Controller as well.

Volunteers?

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Rob Rothwell wrote:
> The class side methods seem easy enough to move to the instance side of
> DisplayScreen so that the global Display can execute them.  Just some
> hunting down of the senders of those methods to do.  All that remains on
> the instance side is:
>
> ScreenController>>objectForDataStream: refStrm

Yes, that can just go away with the class.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

For Pharo it would actually be new versions of the affected packages
that you need to upload to the Pharo inbox :-)

Rob Rothwell wrote:
> Michael
>
> Can you try this then and tell me if I got it right?  Sorry I am not

Seems to work in my image.

> savvy enough to combine the removal of the class with the rest of the

You could simply append the remove to the file using a text editor.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Rob,

On Tue, Feb 24, 2009 at 2:38 PM, Rob Rothwell <[hidden email]> wrote:
> to the pharo inbox, removing references to ScreenController and the
> ScreenController class itself.  Maybe someone can tell me if I did this
> right!

thank you very much for your commit. Unfortunately, this will be a bit
hard for the release team to integrate your changes because the mcz
you published are related but not linked. Please provide a SLICE as
explained at http://code.google.com/p/pharo/wiki/HowToContribute and
then your commit will be perfect I guess :-).

Thank you



--
Damien Cassou
http://damiencassou.seasidehosting.st