martinmcclure
commented
3 years ago Thanks for the feedback!
It's much more usable with the pane dividers!
Thanks! More kinds of dividers are needed -- little one-pixel dividers between some of the sub-pane elements (like above a twizzle) but those are a little less simple to do, so will come a bit later.
General
I find it very disorienting when I select something (or deselect something) and where my eye and mouse are looking moves over an inch or two. It's such a busy screen that it's hard to find where I was. It's not the extra panes per se... is the way the existing ones move around, I'd rather have narrower panes that stayed put. This is fairly serious issue for me.
I agree. It's jarring the way it is. This should be able to be improved after issue #45 is addressed. And other clues about what is connected to what are planned.
I like the colored header backgrounds identifying the type of pane. However, the code header background is brick red and the stack header background is dark red; these are similar enough that they can't be easily distinguished but still obviously different colors. The stack could be less dark and the code a tad darker.
I'll take a look at that -- colors (that are specified in Sparkle code) are easy to change. I wanted to make those two in particular to look related, since they're both part of the debugger, but they could be a little more different.
Evaluator pane
I am not a shortcut user, I'm a right-click-menu person, and there is no right client menu with accept on it.
That is correct. So far, there are no right-click menus in Sparkle. There might be at some point, but I'd like to hold off on that for a while. In this era of touch-friendly interfaces, right-click menus are becoming less common, and I want to make sure that you can at least do everything without use of a right-click.
If I want to lookup the shortcut for accept, it's unreadable (light gray on sky blue)
That is standard Pharo, I'm afraid. (compare with the Pharo world menu) Workaround is to move your mouse so that some other option is selected, the un-selected state is more readable.
As with all things you've commented on that are "Standard Pharo" we can override them eventually, or Pharo may change to make it better.
I also don't mentally map "accept" as "evaluate" - any chance we could call this execute or something more logical?
"Accept" is the best word I've come up with so far. It's not just "evaluate." I think of it more like a code pane in a browser. There's a concept of having unsaved changes or not. There's also interaction with the undo functionality (which is not yet wired in, alas).
the background color for selected text starts off as this blazing turquoise. If you change focus (say, to a browser where you are entered an issue in github) it turns into a blueish gray that is similar to but does not match the grayish blue of selection in the other fields. None of the other fields background colors change when focus is lost.
Standard Pharo for text fields. I did recently mute the selection color for the multi-select lists, which were also that overly-bold blue.
Code pane
the brilliant turquoise (or sometimes gray) background in the numbered column next to the method name was confusing, it looks like a header went missing. It's indicating what line of code you have selected. The brightness is much more distracting than whatever value it provides.., it shouldn't be that hard to see what line you are on in these narrow panes, the problem is more that the line numbers are so faint. At least maybe less bright.
Yes. Standard Pharo. I'm not sure whether the line numbers are worth the space they take up -- it should be possible to turn those off at some point.
I was distressed at first to see that if you select a bit of text, every occurrence of that text is highlighted. On looking at a more complicated method, I can see the value, though. However, I think making the matching-highlight a little more subtle would make the code less chaotic looking.
This is also Standard Pharo, and I find it really useful. Could you include a screen-shot of what you're seeing? The secondary highlighting seems already quite subtle on my screen. Or maybe it's just that I'm used to it. A screen shot would help determine if it's the same on my screen as yours.
LisaAlmarode
It's much more usable with the pane dividers!
General
I find it very disorienting when I select something (or deselect something) and where my eye and mouse are looking moves over an inch or two. It's such a busy screen that it's hard to find where I was. It's not the extra panes per se... is the way the existing ones move around, I'd rather have narrower panes that stayed put. This is fairly serious issue for me.
I like the colored header backgrounds identifying the type of pane. However, the code header background is brick red and the stack header background is dark red; these are similar enough that they can't be easily distinguished but still obviously different colors. The stack could be less dark and the code a tad darker.
Evaluator pane
I am not a shortcut user, I'm a right-click-menu person, and there is no right client menu with accept on it.
If I want to lookup the shortcut for accept, it's unreadable (light gray on sky blue)
I also don't mentally map "accept" as "evaluate" - any chance we could call this execute or something more logical?
the background color for selected text starts off as this blazing turquoise. If you change focus (say, to a browser where you are entered an issue in github) it turns into a blueish gray that is similar to but does not match the grayish blue of selection in the other fields. None of the other fields background colors change when focus is lost.
Code pane
the brilliant turquoise (or sometimes gray) background in the numbered column next to the method name was confusing, it looks like a header went missing. It's indicating what line of code you have selected. The brightness is much more distracting than whatever value it provides.., it shouldn't be that hard to see what line you are on in these narrow panes, the problem is more that the line numbers are so faint. At least maybe less bright.
I was distressed at first to see that if you select a bit of text, every occurrence of that text is highlighted. On looking at a more complicated method, I can see the value, though. However, I think making the matching-highlight a little more subtle would make the code less chaotic looking.