my ���proposal��� is just a fast sketch ��made to illustrate how I would like to show certain functionality, ��it does not take into account any other functionality��� If I finish my browser proposal ever, it will have a lot more buttons in the toolbar :)

about hierarchy I think it should spawn a new browser, as before��� but it is still something we need to play with it.

NOoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

The same way we use all the time variables.

*we* use them all the time, but most people does not use them never :)

anyway: an option in a tab is one click, same as with a button: not hard��� and we can play with the information we show in auxiliary panels better :)

We could have a set up for normal dev and one for indiana jones.

Esteban

Stef

Le 19/8/15 11:50, Esteban Lorenzano a ��crit��:

On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier@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.��

(also, our philosophy is incremental: we improve what we have while we wait for the break-thru improvements)

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)

Thierry