[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