There is free space for another functionnality. I asked for ideas of buttons before doing Scoped one (and it appeared that scoped is used by people). Variables is often used too, and there is no shortcut to browse all the access to the variables of a class so I think it is needed.
They seem more needed than a button with an action which can be triggered by cmd + n or m in the same context than when you are about to clic on it (selector selected).

The toolbar may take time to be loved, but I think new users are more used to a bar with functionnalities on top of a window than a middle bar. I would put all the buttons on top but I understand the strong link of hierarchy, class and comments with the classes panel so it is ok.

And yes, the layout handling in this case is very painful.

Franck

---

From: kilon.alios@gmail.com
Date: Tue, 18 Aug 2015 20:49:34 +0000
To: pharo-dev@lists.pharo.org; pharo-users@lists.pharo.org
Subject: Re: [Pharo-dev] Nautilus questions

I agree with your post about the buttons. Personally I have never used scoped or really need it as feature , I dont think I would be needing variables either. Actually two buttons I miss from Squeak is implementers and senders which I found super useful.

On Tue, Aug 18, 2015 at 11:00 PM Peter Uhn��k <i.uhnak@gmail.com> wrote:

Hi,

maybe I'm too picky, but I have couple of questions/remarks regarding current Nautilus UI.

Now, I'm happy that new features were added/reorganized, but it does feel it is a little bit chaotic right now.

I would expect the left/right history buttons being right next to the History Navigator selector. That way history-related controls are together and the purpose of the buttons is obvious

"Hier.", "Com."... abbreviating button labels? Really?

���And finally, why was part of the buttons moved up? And part stayed down?

I know that you wanted to distinguish "Scoped", because it opens a new browser, and Variables, because they have intermediate menu (and later open another menu).

But I think the fact that Variables are tied to a particular selected class would make much more sense to place the button beside hierachy/class button.

And opening Scoped can be denoted with an appropriate icon ( https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+window+icon&btnG=Search+by+image )

Placing them all on a single line would also save up vertical space, which considering we've added QualityAssistant and Rubric adds another line is quite valuable.

(And finally the width of the buttons should perhaps match more closely the actual needs of the label, because now it's bit cramped.)

��

���

And finally, code-wise I've never really interacted with Morphic and stayed in Spec, so when I was digging through code it seems that the way Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame identity��rightFraction: 0.10;��yourself);" constructs sprinkled haphazardly throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so hard once you get used to Morphic, because I spent probably more time doing elementary changes to layout than learning half of Spec... (Also since Spec can interoperate with Morphic, maybe the layout could also be adapted? Or slowly migrate Nautilus to Spec (if there are even plans like that)?)

Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a chef to tell when food isn't great (which is of course amplified by personal tastes).

So unless I am the only person bothered by this, I would like to raise a discussion (or send a slice, but the way I've done the layout weirds me out, so I still want to look into that regardless).

Cheers,

Peter