Le 20/8/15 11:08, Esteban Lorenzano a écrit :
On 20 Aug 2015, at 09:14, stepharo <steph...@free.fr
<mailto:steph...@free.fr>> wrote:
For example why protocol get the same space than method. We could
split the protocol by half and use the space for
soemthing useful.
I would like the coding area to expand a bit when a method is too long.
I do it all the time by hand.
not just a bit: I would like a button (and a key combination) to
expand the full area to occupy all browser space when needed.
and not just the code area: the different panels too: no matter how
much you reduce the size of protocols and/or packages, there will
always be methods and classes with bigger names… I think an “expand”
function is better solution than arbitrary change panel sizes.
I want an accordeon like.....
Esteban
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
<mailto:esteba...@gmail.com>>:
On 19 Aug 2015, at 11:50, Esteban Lorenzano
<esteba...@gmail.com <mailto:esteba...@gmail.com>> wrote:
On 19 Aug 2015, at 11:44, Thierry Goubier
<thierry.goub...@gmail.com <mailto: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
