February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Michael Rueger

Rob Rothwell wrote: > On Mon, Feb 23, 2009 at 11:16 PM, Michael Rueger <m.rueger(a)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(a)sbcglobal.net address seems to bounces when sending through my mail server

Feb. 24, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Rob Rothwell

On Mon, Feb 23, 2009 at 11:16 PM, Michael Rueger <m.rueger(a)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? Rob

Feb. 24, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Rob Rothwell

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

Feb. 24, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Michael Rueger

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

Feb. 24, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Michael Rueger

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

Feb. 24, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Rob Rothwell

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

Feb. 24, 2009

Re: [Pharo-project] Aaah, the pain or ParagraphEditor refactoring ; -)

by Rob Rothwell

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

Feb. 24, 2009

[Pharo-project] Aaah, the pain or ParagraphEditor refactoring ;-)

by Michael Rueger

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

Feb. 24, 2009

Re: [Pharo-project] looking for Unicode testers

by Michael Rueger

Igor Stasenko wrote: > what is not very convenient is that copy/paste (as well as the rest of > keyboard shortcuts ) is not working when keyboard layout not english. If you could be so kind to tell me what comes back in slot 3 of the input event on your Russian keyboard if you simply type the equivalent of 'xcv' (without alt or ctrl)? I'm interested in what comes back on the keyDown and the keystroke event. Thanks Michael

Feb. 24, 2009

Re: [Pharo-project] suggestion for the category chooser

by Geert

Igor Stasenko wrote: > >> it would be nice to use things like browser's search bar, so when you >> start typing, a list pops up with >> suggested names. > Are you referring to the search bar which displays "C... (class search), i... (implementor search), #C... (class ref search), #s... (sender search)"? How does this search bar actually work? -- View this message in context: http://n2.nabble.com/suggestion-for-the-category-chooser-tp2371841p2375675.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 24, 2009