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 "I am about to be written on an object file. Write a path to me in the other system instead." "| dp | dp := DiskProxy global: #ScheduledControllers selector: #screenController args: #(). refStrm replace: self with: dp. ^ dp" ^ nil Can this just go away if the class goes away? I think I can do this for you... Rob On Mon, Feb 23, 2009 at 10:17 PM, Rob Rothwell <r.j.rothwell@gmail.com>wrote:

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 <m.rueger@acm.org> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael Can you try this then and tell me if I got it right? Sorry I am not savvy enough to combine the removal of the class with the rest of the changes made. When I try to us the change sorter to add that change, I just get a nil, and I can't figure out how to manually add it into the file without getting an error when I load it...sigh... Anyway, the toggle full screen menu options work, the labels update appropriately, and if for some reason someone wants to us the full screen button on TheWorldMainDockingBar, it works too. These are just instance methods of DisplayScreen now, and I referenced Display where appropriate. Maybe you could tell me if I did this right and tell me how to properly upload to the Pharo inbox? If you don't mind for this simple thing, then perhaps I could do other such simple tasks for you in the future. I don't mind doing things like this that I can handle and contributing somehow when someone just needs grunt work like this done. I'm sure I would learn some things along the way... Take care, Rob On Mon, Feb 23, 2009 at 11:13 PM, Michael Rueger <m.rueger@acm.org> wrote:

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael, I published: Graphics-RobRothwell.78 Morphic-RobRothwell.275 ST80-RobRothwell.62 System-RobRothwell.230 to the pharo inbox, removing references to ScreenController and the ScreenController class itself. Maybe someone can tell me if I did this right! Along the way I would ask if anyone wants anything done with TheWorldMainDockingBar, which doesn't use the new File Browser, and certainly doesn't have the same "look and feel" that Pharo seems to be evolving towards... Hope this helps; let me know if I can help with other such rudimentary tasks! Take care, Rob P.S. I'll try to figure out why my email address is bouncing on you. On Mon, Feb 23, 2009 at 11:45 PM, Michael Rueger <m.rueger@acm.org> wrote:

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Thanks for pointing me towards the right way to do it. I figured it would be challenging when there were so many packages, but I have never done this before! I'll try to figure it out tonight...is there anything I need to do to "clean up" the "incorrect" packages I submitted? Thank you, Rob On Tue, Feb 24, 2009 at 8:47 AM, Damien Cassou <damien.cassou@gmail.com>wrote:

Hi Rob,

On Tue, Feb 24, 2009 at 2:38 PM, Rob Rothwell <r.j.rothwell@gmail.com> 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

dont worry we will fix that. On Feb 24, 2009, at 3:02 PM, Damien Cassou wrote:

On Tue, Feb 24, 2009 at 2:59 PM, Rob Rothwell <r.j.rothwell@gmail.com> wrote:

...

I'll try to figure it out tonight...is there anything I need to do to "clean up" the "incorrect" packages I submitted?

Just asks the PharoInbox admins to remove them.

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Just for information, couldn't Safaràa be introduced here ?

Safarà is not useable yet. It is too slow :-( Lukas -- Lukas Renggli http://www.lukas-renggli.ch

...

...

Just for information, couldn't Safaràa be introduced here ?

Safarà is not useable yet. It is too slow :-(

So is it killed by over-engineering or over flexibility?

Writing an editor is not trivial. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Is there anything to look at though, just curious from a Sophie point of view how you approached the problem.

Documentation: http://vst.ensm-douai.fr/Esug2008Media/uploads/1/safara-EsugAwards2008.pdf Implementation (a lot of work will be required): http://www.squeaksource.com/Safara.html Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Lukas, can you make a more detailed overview,please, at what stage it is, and why it too slow. I wasn't aware it even exists!

Safarà was one of the Google Summer of Code 2008 projects. Luigi Panzeri is the author of Safarà, I was mentoring him. I have it running in a 3.9 image together with OmniBrowser. 1. Load OB-Morphic-lr.45, OmniBrowser-lr.407 and OB-Standard-lr.323 from http://source.wiresong.ca/ob/. 2. Load RoelTyper-rw.60, Shout-lr.2, ECompletion-lr.93 and ECompletionOmniBrowser-dc.4 from http://source.lukas-renggli.ch/unsorted. 3. Load Safara-Core.LPM.16, Safara-Morphic-LPM.16 and Safara-Extensions-LPM.11 from http://www.squeaksource.com/Safara. 4. Execute SAMorphicPlatform install to use Safarà instead of the default ParagraphEditor. For small code snippets basic editing works reasonably well. For larger texts (more than a screen) redrawing is extremely slow (due to the fact that formatting is stored in ordered collections). Our goal was to first make it work, before optimizing. The code itself is solid and there are a couple of test cases. Some parts certainly require some refactoring to make them more extensible and easier to use. As you can see in the demo, the basic functionality such as text editing, text selection, syntax highlighting and contextual menus are there. Luigi was one of the best students I ever worked with. He worked very hard on Safarà and I am impressed by the result, especially given that he was relatively new to Smalltalk and Squeak when the project started. He has a strong background in Lisp and Emacs and therefore has good knowledge on the workings of an editor. I heard that he is interested to continue working on Safarà this summer. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Lukas Renggli wrote:

...

Is there anything to look at though, just curious from a Sophie point of view how you approached the problem.

Documentation:

http://vst.ensm-douai.fr/Esug2008Media/uploads/1/safara-EsugAwards2008.pdf

Implementation (a lot of work will be required):

http://www.squeaksource.com/Safara.html

Interesting! Quite a few of the concepts can be found in Sophie too (a bit different, but nonetheless), so there seems to be some merit to those :-) Can you explain where the performance problems are in your approach? And how do you define "too slow"? MIchael

...

Can you explain where the performance problems are in your approach?

At the current state, the problem are the followings: Safarà Commands, the user can invoke (e.g. uppercase words, insert char, paste, browse methods, etc.), act on meaningful pieces (ranges) of texts (words, characters, regions, smalltalk parsed expressions, etc.). At every command invokation, parsers rebuild the range database. That is fine and done right, except that in some cases I could use better algorithm (as Lukas said, first make it work, then make it fast) as a lot of simple commands has often only a local effect on the text range database, then not a full rebuild is really needed. Text is presented with different visual properties (foreground colors, underline, right font, etc.), depending on its meaning (syntax highlighting, and more). At a first stage Safarà drew character x character, but it was too slow. The problem is that the meaning of the text is stored into ranges that are overlapping, instead I need runs (non overlapping ranges of text) in order to present the text. So I have to implement an algorithm that rebuild and perhaps cache better the run database. I have never really completed to do that, as I stopped to work on it. The work at squeaksource about runs was coded in a sprint made at the last ESUG) Second problem: perhaps it is a bad idea to parse the whole content of the buffer at each command invokation, i.e. user input. Parsing/SyntaxHighLighting stuff should be processed in background.

...

And how do you define "too slow"?

Too slow to convince me to use it to code Safarà itself. It hangs your pc for few seconds on long texts (> 10 lines) on each insertion. All this feedbacks/rumors about Safarà is really motivating for me. I hope to go back working on it to make it usable. I am quite confident that I can do it and I d like to do that before the summer. Luigi Panzeri -- View this message in context: http://n2.nabble.com/Aaah%2C-the-pain-or-ParagraphEditor-refactoring---%29-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Luigi PAnzeri wrote:

The problem is that the meaning of the text is stored into ranges that are overlapping, instead I need runs (non overlapping ranges of text) in order to present the text. So I have to implement an algorithm that rebuild and perhaps cache better the run database. I have never really completed to do that, as I stopped to work on it. The work at squeaksource about runs was coded in a sprint made at the last ESUG)

A lot of the features and problems you describe we also encountered and (partially) solved in the Sophie text rendering. We are also using ranges (called markers in Sophie) which allow to add layers on top of the underlying content. We avoided some of the problems you describe by dealing with edits and rendering in a multi stage process. First the edits manipulate the text structure (a tree of sections and text runs) and updating marker ranges in the process. Marker update is pretty efficient as it only involves adjusting a few offsets. Then a display structure/list is generated while applying any style transformations added by the markers affecting the text. Overlapping markers a split into runs during the compositing process, also a very efficient process. At last the display list is rendered. Some operations like cursor movement and selections can be handled without going through the above steps, simply by overlaying them on the display structure. But, it only took us three years to get there and there is still a lot to be improved. On the other hand Sophie text also deals with embedded images, links, trigger overlays etc, so it is a fairly complex system overall. But imagine being able to embed images, audio or video into method source/comments :-) OK, theoretically ParagraphEditor can do that to, but you don't want to know ;-) Michael

do you think that this is a matter of running a profiler or that there is something consuming too much messages (double dispatch or something like that?) Do you know if its author would like to continue in a SummerTalk or related? Stef On Feb 26, 2009, at 8:33 PM, Lukas Renggli wrote:

...

Is there anything to look at though, just curious from a Sophie point of view how you approached the problem.

Documentation:

http://vst.ensm-douai.fr/Esug2008Media/uploads/1/safara-EsugAwards2008.pdf

Implementation (a lot of work will be required):

http://www.squeaksource.com/Safara.html

Lukas

-- Lukas Renggli http://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

Rob Rothwell wrote:

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...!

For Pharo it would actually be new versions of the affected packages that you need to upload to the Pharo inbox :-) I would suggest to migrate those to the global Display, which is an instance of DisplayScreen. Thanks! Michael

Rob Rothwell wrote:

On Mon, Feb 23, 2009 at 11:16 PM, Michael Rueger <m.rueger@acm.org <mailto:m.rueger@acm.org>> wrote:

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

So, in this case, that would be

DisplayScreen, and somehow the removal of ScreenController?

Rather the related Monticello packages. For DisplayScreen that would (or rather should) be Graphics-Display Objects, but Pharo right now has only one large Graphics package. For ScreenController it would be ST80-Kernel-Remnants which ends up being part of ST80. Michael P.S. the cc rjriv@sbcglobal.net address seems to bounces when sending through my mail server