On Sep 13, 2013, at 11:54 PM, GOUBIER Thierry <thierry.goub...@cea.fr> wrote:
> One thing with RB environment scoping: RB selector environments are passive. > The implementorsOf: environment just contains the result of the search, not > the search query. If you create a new method of the same name, the > environment won't see it, and the tools either since they can't ask the > environment to re-run the query. Yes and this is why we should unify Enviromnet and ring since in ring could can specify if you want active method. We should do a pass on all that. > > Thierry > > ________________________________________ > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane > Ducasse [stephane.duca...@inria.fr] > Date d'envoi : vendredi 13 septembre 2013 17:11 > À : Pharo Development List > Objet : Re: [Pharo-dev] Pharo Sprint in Buenos Aires - this saturday! > >> >> A RBEnvironment scoped version of my AltBrowser, with a bit of tree >> filtering on the display. > > Ok I see. > I want to have everytools working on environment so that we get scoping. > >> >> Finder is like the Finder plugin in Nautilus, except that it opens a scoped >> instance of the browser. >> >> MessageBrowser is replaced by a scoped instance of the browser. >> >> And the browser knows how to adjust the tree display depending on the scope >> (pruning the tree and adapting the display of items). >> >> Makes exploring code a lot easier mostly because of smart suggestions, >> otherwise I would do implementorsOf:, get the message browser, and use >> browse on each result one by one to open a new browser, and there have smart >> suggestions to do implementorsOf: to be able to follow a cascade of message >> sends :( >> >> I hated being in the finder, looking at the code pane and a multi arguments >> message and saying to myself 'but how will I do sendersOf or implementorsOf >> of that message?' > > Yes I understand. > >> >>>> , and I now have unified menus, shortcuts and smart suggestions and I find >>>> it really, really nice. >>> >>> do you have suggestion for the menus unification? >> >> Have a single code source editor* for all code panes, with the same menu >> building** code in each :) > > Oh yes!!!! > >> * This is probably the case in the old framework and the reason for having >> all thoses menu actions inside SmalltalkEditor. >> >> ** But something pluggable so that we may still be able to experiment! > > Yes. We should really revisit all the menus and get one way to build them and > reuse them. > >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des Systèmes Temps Réel Embarqués >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> <ScreenshotFinder.png> > > >
