Smalltalk › Squeak › Squeak - Dev

[ANN] Squeak 4.5 Release Candidate 1

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

42 messages Options

123

Chris Muller-3

Re: [ANN] Squeak 4.5 Release Candidate 1

> As an aside for later consideration, we’ve really lost something somewhere
> with regard to debugging. Just where can one go from an open dialogue like
> that to trace back to the cause of the problem? You can’t hit the break
> key-combo because that just gets you to the event loop. Exploring the
> morph(s) of the dialogue seems to go nowhere that I can find.
>
>
> Cmd-dot worked for me. And as suspected, it's the effing MC proxy stuff, yet
> again.

I knew about this bug a long time ago, but forgot about it.

> I'm sorry Chris, I am not ever going to like it. And I will vote for
> shipping 4.5 with *full* ancestry information. And *not* turning on the
> proxyfication.

Given the bug and the timing, no problem, but...

> You can do that in your own image, but please do not force it
> onto the rest of us. The release must be self-contained, and not having to
> call back to the mothership whenever it feels like it.

.. there is not much logic to this argument. Calling back to the
mothership happens when you do any of a number of operations in
Squeak.

Bert, it's fine to not like the implementation, but please tell me you
also don't like the ever-growing unsustainable ancestry model, right?

I'm not beholden to this solution with Proxy's. Come up with a
different solution that solves the problem in 4.6 along with the
problem of always reading _all versions_ of all packages in Trunk for
virtually _every_ single operation we do. Make it backward compatible
and, oh, make sure everyone _likes_ your solution too..

In the meantime, trunk has become virtually unusable by its being
bogged down with so many versions needing constantly downloaded, again
and again.

Chris Muller-3

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Jeff Gonis-2

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 <[hidden email]> 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
>
>
>

Jeff Gonis-2

Re: [ANN] Squeak 4.5 Release Candidate 1

Hi Chris,

I just wanted to follow up my previous email with a +1 for the overall idea of splitters. You are right, I should have offered more feedback at the time you first pushed it or, even better, some code! I think that with a bit of work this feature could be a big boon for the 4.6 release, and I agree that it can really help at times with resizing.

Anyway, I know that open source can at times feel thankless, so I just wanted to send a quick email saying that all of your work on squeak is appreciated by the community, and definitely all of the hard work you are doing managing this release.

Here's to a great 4.5 release and an even better 4.6!

Thanks,

Jeff

Herbert König

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

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 <[hidden email]> 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
>>
>>
>>

timrowledge

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

On 27-01-2014, at 4:12 PM, Chris Muller <[hidden email]> wrote:

> - I expected more thoughtful critique from the guy redoing Scratch
> than premature "flummery" dismissal.

‘Scuse me? Inappropriate conflation combined with a sort of inverted ad hominem? That’s an interesting approach to debate…

I don’t like UI elements that wiggle around. Two reasons
a) confusion. confusion and surprise. confusion, surprise and indignation. Ok, that’s three there.
b) Clippy. Nuff said.

Not to mention that on slower machines these assorted animations, syntax prettifiers, ‘helpful assistance’ etc widgets too often turn out to suck up all the cpu and at the very least go choppy and distracting.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I do not fear computers. I fear the lack of them.

Chris Muller-4

Re: [ANN] Squeak 4.5 Release Candidate 1

>> - I expected more thoughtful critique from the guy redoing Scratch
>> than premature "flummery" dismissal.
>
> ‘Scuse me? Inappropriate conflation combined with a sort of inverted ad hominem? That’s an interesting approach to debate…
>
> I don’t like UI elements that wiggle around. Two reasons
> a) confusion. confusion and surprise. confusion, surprise and indignation. Ok, that’s three there.
> b) Clippy. Nuff said.
>
> Not to mention that on slower machines these assorted animations, syntax prettifiers, ‘helpful assistance’ etc widgets too often turn out to suck up all the cpu and at the very least go choppy and distracting.

The higher gear of a bike is harder to pedal, but uses the added
leverage to go farther.

Colin Putney-3

Re: [ANN] Squeak 4.5 Release Candidate 1

On Mon, Jan 27, 2014 at 9:20 PM, Chris Muller <[hidden email]> wrote:

> The higher gear of a bike is harder to pedal, but uses the added
> leverage to go farther.

Yup. It's great until you have to climb a hill. Then it's a good idea
to downshift.

Chris Muller-3

Re: [ANN] Squeak 4.5 Release Candidate 1

On Mon, Jan 27, 2014 at 8:35 PM, Colin Putney <[hidden email]> wrote:
> On Mon, Jan 27, 2014 at 9:20 PM, Chris Muller <[hidden email]> wrote:
>
>> The higher gear of a bike is harder to pedal, but uses the added
>> leverage to go farther.
>
> Yup. It's great until you have to climb a hill. Then it's a good idea
> to downshift.

LOL!! Yes, true. :)

charlie robert

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Colin Putney-3

Why not use 3 pedals?

On Jan 27, 2014, at 7:35 PM, Colin Putney <[hidden email]> wrote:

On Mon, Jan 27, 2014 at 9:20 PM, Chris Muller <[hidden email]> wrote:

The higher gear of a bike is harder to pedal, but uses the added
leverage to go farther.

Yup. It's great until you have to climb a hill. Then it's a good idea
to downshift.

- charlie

Frank Shearar-3

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

On 27 Jan 2014, at 22:19, Chris Muller <[hidden email]> wrote:

> Hi John-Reed,
>
> On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo <[hidden email]> wrote:
>> 1. There is an interesting (and to me, unnerving) new feature in Squeak Squeak4.5-13663.
>>
>> Automatic pane resizing in System Browser.
>>
>> When I mouse around in a newly opened window, the panes resize their height and width in seemingly random ways.
>
> It's not random at all. The philosophy of the horizontal-splitter
> algorithm is to 1) only expose additional information but, 2) don't
> truncate any information to accomplish that, e.g., only encroach on
> whitespace.

I showed this off last night at the UK Smalltalk user group, to a positive response. That may have been aided by me explaining why things were resizing. Nick Ager pointed me to Josh Gargus' Cassowary project from a while ago, which does constraint solving for UI layout.

It took me a while to get used to the resizing, but as Chris says, it does alleviate the need to move splitters around so you can see your text. One thing that would help for me is speeding up Morphic, because on my low power laptop, if there are a few windows open things get too slow for my liking. (And on my laptop slowing things even a tiny bit hits the 'too slow' threshold quite quickly.)

But really, give Chris' tweak a good try. Setting the Preference on by default at least gives the algorithm and UX a good whacking.

frank

> For vertical bars; the bars between lists will automatically
> reposition themselves to encroach on whitespace in one pane to expose
> more information in adjacent panes. It will balance the number of
> characters occluded on either side of the bar, if necessary.
>
> For either, if a particular splitter is manually positioned, it will
> remain still at the dragged location. To reactivate
> automatic-positioning, yellow-click it.
>
>> I find no value in the resizing that is done.
>
> A lot of thoughtful consideration, design, and implementation work
> went into it. It's a major productivity boost. It alleviates 90% of
> manual sizing otherwise required by the user in a typical day.
>
> Everyone should give this chance for at least one full day's work
> before judging it. I struggled with the animation distraction for a
> day or two, but now when I open a window, I simply let them do their
> work while I put the window where I want. I'm 90% liberated from
> manual twiddling, positioning and scrolling. I've noticed even the
> _need_ to resize windows is reduced too.
>
>> 2. Comment: From an experienced user perspective, I appreciate the clean look when I first open Squeak.
>>> From a new user perspective, I appreciate the introductory screens.
>
> I want to deliver a clean-look this time. If a new user is presented
> with nothing but a clean desktop, they have no choice but to
> "explore". I don't to want to fool new users into getting comfortable
> by thinking those workspaces have everything they need to do useful
> things with Squeak. I want them in the "drivers seat" from the get
> go.
>
>> 3. Presenter(Object)>>doesNotUnderstand: #associatedMorph
>> a. Open Squeak
>> b. Open a new morphic project
>> c. Return to previous project
>> d. Select red X, close this window.
>> d. MNU Really delete the icon
>> and remove the project
>> 'Unnamed' from Etoys?
>> (file will still be saved on disk.
>>
>> Thats all from my lunch break.
>
> Shit, we should fix that.
>
> Thanks.
>

Tobias Pape

Re: [ANN] Squeak 4.5 Release Candidate 1

On 28.01.2014, at 09:36, Frank Shearar <[hidden email]> wrote:

> On 27 Jan 2014, at 22:19, Chris Muller <[hidden email]> wrote:
>
>> Hi John-Reed,
>>
>> On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo <[hidden email]> wrote:
>>> 1. There is an interesting (and to me, unnerving) new feature in Squeak Squeak4.5-13663.
>>>
>>> Automatic pane resizing in System Browser.
>>>
>>> When I mouse around in a newly opened window, the panes resize their height and width in seemingly random ways.
>>
>> It's not random at all. The philosophy of the horizontal-splitter
>> algorithm is to 1) only expose additional information but, 2) don't
>> truncate any information to accomplish that, e.g., only encroach on
>> whitespace.
>
> I showed this off last night at the UK Smalltalk user group, to a positive response. That may have been aided by me explaining why things were resizing. Nick Ager pointed me to Josh Gargus' Cassowary project from a while ago, which does constraint solving for UI layout.
>
> It took me a while to get used to the resizing, but as Chris says, it does alleviate the need to move splitters around so you can see your text. One thing that would help for me is speeding up Morphic, because on my low power laptop, if there are a few windows open things get too slow for my liking. (And on my laptop slowing things even a tiny bit hits the 'too slow' threshold quite quickly.)
>
> But really, give Chris' tweak a good try. Setting the Preference on by default at least gives the algorithm and UX a good whacking.

We really should, but not for this very release, I think.
I personally don’t like it, but this is not the point.
Perhaps it is very useful when all the knobs are tuned,
but please let’s delay that just a tad.

Best
-Tobias

signature.asc (1K) Download Attachment

ccrraaiigg

re: Squeak 4.5 Release Candidate 1

In reply to this post by Bert Freudenberg

Hi Chris--

Thanks for all your work on this!

This sort of testing is the best reason I have for using virtual
machines a la Parallels etc. I grab a virgin system (ideally with a
guest OS which is different from the one I use for primary development)
and do a fresh install as an end-user would.

And if you use a cloud-based host (EC2, Azure, Google Cloud, etc.)
then we can share results easily.

thanks again,

-C

--
Craig Latta
www.netjam.org/resume
+ 1 510 984 8117
+31 20 893 2796

Eliot Miranda-2

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Bert Freudenberg

On Mon, Jan 27, 2014 at 2:38 PM, Bert Freudenberg <[hidden email]> wrote:

On 27.01.2014, at 23:19, Chris Muller <[hidden email]> wrote:

Hi John-Reed,

On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo <[hidden email]> wrote:

I find no value in the resizing that is done.

A lot of thoughtful consideration, design, and implementation work
went into it. It's a major productivity boost. It alleviates 90% of
manual sizing otherwise required by the user in a typical day.

Chris, I appreciate the things you add to Squeak. But as a release manager, you have to wear a different hat. Now, a couple of days before the release, is not a good time to introduce a major UI change. That needs to be done at the beginning of a release cycle, not at the end of it.

+1.

And I *hate* it ;-). It would be sort-of if it resized once, on opening. But it resizes all the time which I find horribly horribly distracting. Please, please Chris, wear your release manager's hat and take this out. Introduce it for 4.6 (as a preference).

and +1 to one open workspace that says welcome and point to e.g. the Help menu.

Everyone should give this chance for at least one full day's work
before judging it.

Hear hear. All the more reason to not squeeze this in at the last minute.

2. Comment: From an experienced user perspective, I appreciate the clean look when I first open Squeak.

From a new user perspective, I appreciate the introductory screens.

I want to deliver a clean-look this time. If a new user is presented
with nothing but a clean desktop, they have no choice but to
"explore". I don't to want to fool new users into getting comfortable
by thinking those workspaces have everything they need to do useful
things with Squeak. I want them in the "drivers seat" from the get
go.

I'm not sure which way is better - having things thrown in your face, or invite exploration. So I wouldn't be opposed in trying your way (and at least as an experienced developer I won't have to close all the annoying windows).

What may be detrimental though is said exploratory experience right now. Pretending to be a newbie, I just clicked on Help, then "Terse Guide to Squeak" which sounded inviting. The very first item looks like this:

The advantage we have with a few pre-opened windows is that we get to choose what a user sees first. Since first impressions do count, this might be advantageous. Unfortunately I don't think we have the time now to fix everything to make it nicely explorable -- although that is a very important goal we should pursue, in general.

So ... thanks for your release work, just be a bit more conservative, okay? Integrate, not innovate. Innovation can rush in again when this package is shipped :)

- Bert -

--
best,

Eliot

Chris Muller-3

Re: [ANN] Squeak 4.5 Release Candidate 1

On Mon, Jan 27, 2014 at 2:38 PM, Bert Freudenberg <[hidden email]> wrote:

On 27.01.2014, at 23:19, Chris Muller <[hidden email]> wrote:

Hi John-Reed,

On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo <[hidden email]> wrote:

I find no value in the resizing that is done.

A lot of thoughtful consideration, design, and implementation work
went into it. It's a major productivity boost. It alleviates 90% of
manual sizing otherwise required by the user in a typical day.

Chris, I appreciate the things you add to Squeak. But as a release manager, you have to wear a different hat. Now, a couple of days before the release, is not a good time to introduce a major UI change. That needs to be done at the beginning of a release cycle, not at the end of it.

+1.

And I *hate* it ;-).

(You guys are really adept at souring my mood today!)

It would be sort-of if it resized once, on opening.

That won't work, because as soon as your pane-state changes in the already-opened window, you'll have truncated info again.

But it resizes all the time

No, it does NOT do that. If it did, I wouldn't use it myself.

Eliot, just hold still for 5 seconds after opening a window. Let it do its work to settle in and find the optimal sizes. Is it still moving after 5 seconds? I doubt it.

This is why I used my higher bike-gear analogy yesterday. Because when I see others working in demo videos and in person, I notice a kind of "freneticism" about their mousing and clicking (like trying to go fast on a bike in 1st gear). Hyper-clicking around. Doing tons of input work while the machine sits there as if basking on the beach.

You have to learn to slow down, let the machine some work, and harness that work. Only then will you be in the higher bike gear and going faster with less effort.

which I find horribly horribly distracting.

Yes, it was distracting for me for 2 or 3 days. Then, something amazing happened -- my style of working, perhaps subconciously, "adjusted itself". As if my body "learned" about when the optimizations would happen (e.g., opening a window, selecting a method, etc.), and then learning how to let that _amplify_ connection to the UI, rather than letting myself be distracted by it.

It's not something that can be understood in just an hour of trying it. Sorry.

Please, please Chris, wear your release manager's hat

I take exception to you and Bert suggesting that I haven't been. As I explained yesterday, my reason for turning this on was FOR the release..

and take this out.

..but it was already taken out today because of everyone's personal negative reactions. Hey, so maybe that proves my intuitions about turning it on are wrong.

Introduce it for 4.6 (as a preference).

It is already a preference.

marcel.taeumel (old)

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

Hi Chris,

nice to see that we are on a good way to release Squeak 4.5. Many bug fixes, many code cleanups... and some not that "polished" new features there. :)

Let me explain my concern with those "Smart Pane Splitters". Automatic, content-aware layouting is a nice idea and many applications out there try to minimize the time that users have to spend for just organizing information on screen. Despite all efforts that go into those neat approaches, we still need to follow up on some basic usability heuristics.

You do not want to slow the user down. Users will accommodate to the pace of the interface. Having to wait some seconds until the layout manager got its work done is not acceptable. This is something even expert users cannot optimize (besides turning that feature off at all). Such layouting is a very frequent action that has to complete as fast as possible. At most 100ms I suppose. (Would have to look up for some response time models such as that from Ben Shneiderman).

I think that predictability of user interactions is even more important. This layout algorithm (and the way you can watch it work) seems unpredictable. Even random. You try to think about what the user wants to see in, for example, the system browser but you actually have no idea whether pane resizing is an issue for the particular programming task at all. In these situations, this layouting gets in the way of users' productivity.

I appreaciate the work that you have done here but this feature of having "Smart Pane Splitters" is not ready to be released and needs more rethinking from a usability perspective: What are the benefits? What are the liabilities? Is it for experts only? Is it for novices only? What is the actual (killer) use case where such a feature can support the programmer?

I do not just vote for turning off the preference by default but for removing its code from the 4.5 image and provide a simple Metacello-Script for loading aftewards. :)

Best,
Marcel

Tobias Pape

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

On 29.01.2014, at 00:52, Chris Muller <[hidden email]> wrote:

> On Mon, Jan 27, 2014 at 2:38 PM, Bert Freudenberg <[hidden email]> wrote:
> On 27.01.2014, at 23:19, Chris Muller <[hidden email]> wrote:
>
>> Hi John-Reed,
>>
>> On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo <[hidden email]> wrote:
>>
>>> I find no value in the resizing that is done.
>>
>> A lot of thoughtful consideration, design, and implementation work
>> went into it. It's a major productivity boost. It alleviates 90% of
>> manual sizing otherwise required by the user in a typical day.
>
> Chris, I appreciate the things you add to Squeak. But as a release manager, you have to wear a different hat. Now, a couple of days before the release, is not a good time to introduce a major UI change. That needs to be done at the beginning of a release cycle, not at the end of it.
>
> +1.
>
> And I *hate* it ;-).
>
> (You guys are really adept at souring my mood today!)
>
> It would be sort-of if it resized once, on opening.
>
> That won't work, because as soon as your pane-state changes in the already-opened window, you'll have truncated info again.
>
> But it resizes all the time
>
> No, it does NOT do that. If it did, I wouldn't use it myself.

Well it does, watch: http://netshed.de/split.mov
It moves the splitter everytime I select some different pane.

At sec 3, the [instance] button becomes illegible.
At sec 19, the protocol pane becomes too narrow…
At sec 25, the right splitter collapsed completely.
At sec 27, the code pane shrinks.
At sec 31, the splitter does not know whether to turn left or right.
At sec 49, selecting the method leads to its name in the message pane being illegible.

>
> Eliot, just hold still for 5 seconds after opening a window. Let it do its work to settle in and find the optimal sizes. Is it still moving after 5 seconds? I doubt it.
>
> This is why I used my higher bike-gear analogy yesterday. Because when I see others working in demo videos and in person, I notice a kind of "freneticism" about their mousing and clicking (like trying to go fast on a bike in 1st gear). Hyper-clicking around. Doing tons of input work while the machine sits there as if basking on the beach.
>
> You have to learn to slow down, let the machine some work, and harness that work. Only then will you be in the higher bike gear and going faster with less effort.
>
> which I find horribly horribly distracting.
>
> Yes, it was distracting for me for 2 or 3 days. Then, something amazing happened -- my style of working, perhaps subconciously, "adjusted itself". As if my body "learned" about when the optimizations would happen (e.g., opening a window, selecting a method, etc.), and then learning how to let that _amplify_ connection to the UI, rather than letting myself be distracted by it.
>
> It's not something that can be understood in just an hour of trying it. Sorry.
>
> Please, please Chris, wear your release manager's hat
>
> I take exception to you and Bert suggesting that I haven't been. As I explained yesterday, my reason for turning this on was FOR the release..
>
> and take this out.
>
> ..but it was already taken out today because of everyone's personal negative reactions. Hey, so maybe that proves my intuitions about turning it on are wrong.
>
> Introduce it for 4.6 (as a preference).
>
> It is already a preference.
>

signature.asc (1K) Download Attachment

Nikolay Suslov

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

Hello Chris,

On Tue, Jan 28, 2014 at 2:19 AM, Chris Muller <[hidden email]> wrote:

A lot of thoughtful consideration, design, and implementation work
went into it. It's a major productivity boost. It alleviates 90% of
manual sizing otherwise required by the user in a typical day.

As for me, manual sizing and having a lot of opened code browser windows in quit different visual, geometry forms, defined by own is one of the things that improves my development productivity.

So, that you could think "visually and tactile", when your interaction with windows remains invariant and saved. May be, auto-layout (cassowary ect.) could be activated while resizing the windows, preventing from destruction effect, but not after that. Thinking, that automatically reposition is more suitable to one-window-browser development environments, but Squeak from the beginning is famous for its high creative abilities in manual morph transformation (rotate browser to the angle of 90 and program in it .)

So, the idea is great! But, may be not for all Squeakers to be activated by default.

Regards,

Nikolay

marcel.taeumel (old)

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by marcel.taeumel (old)

Some minor remarks:

- The red text cursor/caret with triangles at both ends feels to prominent in the interface
- The input box for entering MC repository information is too small by default
- The public SqueakSource MetacelloRepository could be added to the list of Monticello repositories
- There are some "cmm" left in repository information that should be removed ;)

Best,
Marcel

Tobias Pape

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by Chris Muller-3

Hey all,

On 27.01.2014, at 17:51, Chris Muller <[hidden email]> wrote:

> It's ready for your final testing and scrutiny!
>
> http://ftp.squeak.org/4.5alpha/Squeak4.5-13663.zip
>
> Please bang on this! Test it with your apps. Test it in Windows,
> iOS, Linux. Interpreter and Cog.
>
> Unless we hit any show-stoppers, this will be the one we can call "done."
>
> Thanks to this great community of brilliant developers for making 4.5
> a superb release.

I have the feeling that the IPv6 support is not yet working right.
I wanted to use our local SqueakSource, which is primarily available via IPv6
though the HPI.

The first time, I got a “connection refused” error, Socket
was unable to open a connection to our site.

I tried this (low-level connect)
(SocketAddressInformation forHost: '2001:638:807:204::8d59:e178' service: '80'
flags: 0
addressFamily: SocketAddressInformation addressFamilyINET6
socketType: SocketAddressInformation socketTypeStream
protocol: 0) first connect
And it worked.

Then I tried monticello again, and it worked.
Then again, the “connection refused” error.

Since the error is spontaneous, I don’t know how to debug :(

Best
-Tobias

signature.asc (1K) Download Attachment

Frank Shearar-3

Re: [ANN] Squeak 4.5 Release Candidate 1

In reply to this post by marcel.taeumel (old)

Just remember that the point of the 4.5 release candidate is not to
fix every single existing bug/issue in Squeak. By all means raise
these issues (and bonus points if they're recorded in bugs.squeak.org
so volunteers can easily find things to do), but it's largely Chris'
call as to what will actually go into 4.5.

frank

On 29 January 2014 12:14, Marcel Taeumel
<[hidden email]> wrote:

> Some minor remarks:
>
> - The red text cursor/caret with triangles at both ends feels to prominent
> in the interface
> - The input box for entering MC repository information is too small by
> default
> - The public SqueakSource MetacelloRepository could be added to the list of
> Monticello repositories
> - There are some "cmm" left in repository information that should be removed
> ;)
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/ANN-Squeak-4-5-Release-Candidate-1-tp4739706p4740082.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

123