[squeak-dev] [ANN] Squeak 4.5 Release Candidate 1
Herbert König
herbertkoenig at gmx.net
Tue Jan 28 00:54:24 UTC 2014
Hi Chris,
aside from the timing of introduction of the feature, the more I use it
the more I appreciate it. I still dislike that it makes the code pane in
a browser too small for all but the smallest methods. I resize
inspectors all the time, so that's ok.
And yes, I would never have considered trying the feature if it hadn't
been thrown at me. So I guess you choose the right way in presenting it
(I don't like to admit that :-)).
And the thought of a modern UI that feels alive makes me think. I just
come from sketching some ideas by dropping some morphs and texts and
appreciating that in a different language I would have fired up some
painting or CAD program and think about how to link the graph to the
code. So let me try to get used to a self moving UI.
Have to get some sleep
Cheers,
Herbert
Am 28.01.2014 01:12, schrieb Chris Muller:
> Sigh. Okay guys, you win. But the reasons I'm frustrated:
>
> - I was looking for feedback about it last September.
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-September/173162.html.
> - Notice I left it OFF at that time (I shouldn't have!), because I
> was thinking about y'all and not "first impressions" of new users.
> - Now I'm thinking about first impressions of new modern users who
> appreciate a modern UI that feels "alive", and catering to their need
> to see information, not feeling like a cumbersome dinosaur UI from the
> 1990's.
> - I expected more thoughtful critique from the guy redoing Scratch
> than premature "flummery" dismissal.
>
> Herbert correctly points out the debugger is the most dramatically
> affected because each step into code causes new contents in all panes
> which means constant pane-size optimization. I intend to address this
> in 4.6.
>
> But, after using it every day since September, it's goodness far
> outweighs its badness. I'm never going back. The one or two bad
> cases are easily alleviated by a simple repositioning of the splitter,
> something that otherwise must be done a hundred times per day, along
> with scrolling and resizing of windows, than when the pref is off.
>
> That's why I feel it should be On by default for 4.5 release, but will
> of course respect the vote of the community.
>
>
> On Mon, Jan 27, 2014 at 5:05 PM, Jeff Gonis <jeff.gonis at gmail.com> wrote:
>> Hi Chris,
>>
>> I'll echo what others are saying here and cast my vote for not having the
>> pane resizing feature in the 4.5 release. I do think that it could be a
>> really nice feature for 4.6 but I think it needs a little time to bake.
>>
>> My own 2 cents would be to make resizing occur without redraw until an
>> optimal size is found and then do the resizing all at once to reduce the
>> visual distraction that occurs by having the panes "swim" as I browse
>> through different classes. I also think it needs a little but more time to
>> bake as I have found the same thing the Herbert did above, namely that the
>> pane resizing can make associated buttons too small.
>>
>> I think that this could be a really nice feature with some refinement, but
>> for this release I don't think it is ready to go. Count this as my vote for
>> putting it in the 4.6 development cycle and letting people bang on it during
>> that time.
>>
>> Thanks,
>> Jeff
>>
>>
>>
More information about the Squeak-dev
mailing list
|