2015-08-20 10:19 GMT+02:00 stepharo <steph...@free.fr>: > > > Le 20 août 2015 09:15, "stepharo" <steph...@free.fr> a écrit : > > > > For example why protocol get the same space than method. We could split > the protocol by half and use the space for > > soemthing useful. > > Protocol names can be long... > > > yes but 99% of the time you do not care. >
I'm not sure of that. On classes with a lot of methods (Object, Morph, any class with over 20 methods), I believe one rely on protocols to avoid being overwhelmed by the sheer number, and that most of them are irrelevant to the task at hand (the method you're writing and reading, and the same class methods it is using). I wonder if the fact Nautilus shows us by default the 'all' method list is not inciting us, by pure laziness, to disregard protocols... > And methods are way more important. > In fact protocol could just the tag (as in the catalog browser) after the > method names. > Then you could use the message list GUI instead of the system browser. Thierry > > Stef > > > > > I would like the coding area to expand a bit when a method is too long. > > I do it all the time by hand. > > Yes, especially with Seaside renderOn: > > Phil > > > > > Stef > > > > > > Le 19/8/15 13:13, Thierry Goubier a écrit : > >> > >> Hitting send too early :( > >> > >> 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: > >>> > >>> > >>>> On 19 Aug 2015, at 11:50, Esteban Lorenzano <esteba...@gmail.com> > wrote: > >>>> > >>>>> > >>>>> On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > >>>>> > >>>>>> <Screen Shot 2015-08-19 at 11.10.41.png> > >>>>>> > >>>>>> … but arriving to it is not so easy. > >>>>>> > >>>>>> In conclusion: We are doing some right steps. It is not finished, > but we are not going to go back to older way :) > >>>>> > >>>>> > >>>>> Hi Esteban, > >>>>> > >>>>> My opinion is that you're still tied a lot to the Smalltalk 80's > way... Which is good: someone coming from 1980 would be able to use > Nautilus ;) > >>>>> > >>>>> My critics on that design: the tabs are nice and certainly help see > that a class has a class side. Overall look is more up to date. Tabs > headers, scroll bars, etc... take far too much space: work area (the code > area) is 39% of overall window size, and 68% counting in the context > (package, class, protocol and method) (Numbers are worse on a small window, > of course, but I guess some do work on small screens). > >>>>> > >>>>> It will be nice to see simpler / cleaner Nautilus code coming along > :) > >>>> > >>>> > >>>> yes, of course you are right :) > >>>> the GTools guys are working in a complete replacement, and I’m sure > it will be a lot better… but we will always need a backdoor… and I would > like to have a good browser even as a backdoor. > >> > >> I'm certainly looking forward for the GT-based system browser results, > while probably I won't be using it; some of the design / implementation > choices of the GT tools just don't fit the way I work, and I feel down by > just looking at how clumsy and slow I become when using them. > >>>> > >>>> (also, our philosophy is incremental: we improve what we have while > we wait for the break-thru improvements) > >> > >> Agreed. I still miss a bit the OmniBrowser I started Pharo with... > Especially the code regularity and architecture. > >>>> > >>>> > >>>> Esteban > >>>> > >>>> ps: for me the “code area” is not equivalent to the “work area”: I > spend much more time understanding a problem than coding it, and for that a > view of the method *in the context* is better) > >> > >> That's why I added the 68% result: I do agree that the context matter; > I still think that the overhead is too high. > >> > >>> > >>> > >>> for example: I try your alt browser time to time, because I find it > has some good ideas. > >>> But since my workflow is usually: I dig a package, then I see the > classes inside and try to figure out how they work together, then I read > the comments, try to find examples, tests… then I finally go to the method > level, and even that often with an eye into the class it belongs and even > the package… so the AltBrowser is useless for me… it is really not > confortable for me to use… and yes, it has a bigger code area, but that is > not really relevant (for me). > >>> … and the traditional browser adapts a lot better to that way of doing. > >> > >> > >> I think I more or less do the same, but with a slightly different > approach, with for example a lot of scoping (to a class, to a package, > implementors, senders, finder). I especially rely on the fact that I stay > in the browser task model (but with multiple windows) all the time while > doing that; I don't have to deal with disparate tools (Spotter, Finder, > MessageList). > >> > >> I also like the fact I can see both class and instance side methods at > the same time... > >> > >>> > >>> Now… real question is: I work that way because fits better my > mind-model or my mind-model fits what the browser provides me? well, who > knows… but back in my java days I also was using the “java browsing > perspective” of Eclipse, who resembles a Smalltalk browser. > >> > >> > >> The good question we have here is that our > search/exploration/understanding strategies are different, but based on the > same building blocks... So there is some Moldable issue there as per the GT > group, but not inside the tool as they are currently doing, instead the > tool itself has to be moldable (or what is the tool). > >> > >> Now, I'm so attuned to the Alt Browser tree view that I prefer it in > any case... even to the point that I can do short and fast smalltalk edits > directly on github through the web interface. > >> > >> Thierry > >> > >>> > >>> Esteban > >>> > >>>> > >>>>> > >>>>> Thierry > >>> > >>> > >> > > > > >
