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. I find no value in the resizing that is done.
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.
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.
johnreed
----- Original Message ----- From: Chris Muller Sent: 01/27/14 09:51 AM To: squeak dev Subject: [squeak-dev] [ANN] Squeak 4.5 Release Candidate 1
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.
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net wrote:
- 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.
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.
- 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.
- 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.
On 27.01.2014, at 23:19, Chris Muller asqueaker@gmail.com wrote:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net 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.
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.
- 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 -
On Mon, Jan 27, 2014 at 2:38 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 27.01.2014, at 23:19, Chris Muller asqueaker@gmail.com wrote:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net 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.
- 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 -
On Mon, Jan 27, 2014 at 2:38 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 27.01.2014, at 23:19, Chris Muller asqueaker@gmail.com wrote:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net 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.
On 29.01.2014, at 00:52, Chris Muller asqueaker@gmail.com wrote:
On Mon, Jan 27, 2014 at 2:38 PM, Bert Freudenberg bert@freudenbergs.de wrote: On 27.01.2014, at 23:19, Chris Muller asqueaker@gmail.com wrote:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net 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.
Thanks for posting this video Tobias! This way I can explain WHAT is going on and WHY, so that hopefully leave you with a greater understanding and appreciation for it.
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.
Of course it does! How else could it do its job to minimize whitespace and maximize exposed information?
At sec 3, the [instance] button becomes illegible.
Drag the bar yourself, the same thing happens. It has _nothing_ at all to do with Smart-Splitters and simply a matter of the LayoutFrame's limits needing to be fixed (can't remember exactly which attribute..the one which causes the halt in the splitter when you try to drag it too far -- SS is only restricted by the same).
At sec 19, the protocol pane becomes too narrow…
All four panes are balanced w.r.t. the number of occluded characters. Why do you say only the protocol pane is too narrow? They're all too narrow. What do you expect the smart-splitters to do in this situation?
At sec 25, the right splitter collapsed completely.
Again, Smart-Splitters does not cause this bug, it simply exposed it. Drag the splitter manually yourself that way, and you'll see it collapses. We need to fix the limits specified in the LayoutFrame.
At sec 27, the code pane shrinks.
To expose more list without truncating anything in the code pane. That's the whole purpose of the feature. Had you waited a bit longer before your next click it would have shrunk to an exact-fit in the code-pane.
At sec 31, the splitter does not know whether to turn left or right.
Yes it does. When the protocol pane was empty, it knew to go right to expose more in the left panes. But you immediately selected StringSocket, causing the contents of the protocol pane to be filled, which causes Smart-Splitter to want to balance the number of occluded characters on either side.
It did exactly what it's supposed to.
At sec 49, selecting the method leads to its name in the message pane being illegible.
The video ended before it had a chance to readjust yet again to your frenetic clicking around. :)
---------
So, it might also help to understand the algorithm is entirely localized within each SplitterMorph. Each splitter morph looks only at the panes either side of it and makes a 1 or 2-pixel adjustment, +/- toward the more optimal, in its #step method.
So in browsers that stack panes greater than 3-wide, there will be some interactions between the adjustments. This is analagous to the animated morphs of an Etoys application responding to other animated Morphs in their surroundings. Smart-splitters already greatly softens this with internal stepTime delays, but apparently not enough for your taste. :-(
I'm doubtful such a localized algorithm will ever be able to meet your expectations. Which is unfortunate, because I'd be sorry if you missed out on something quite good simply because it's not quite perfect. Hopefully it can be tweaked it a little closer to perfection in 4.6. I already know a couple of things I want to improve.
Its worth noting, you chose the particular browser (besides the debugger) that is least-flattering for this feature because it stacks 4-panes wide, which means there will be some extra interactions between the optimizations made in the adjacent panes. Using a browser _designed_ for browsing the class-model (e.g. Hierarchy browsers), instead of the package-model, only stacks 3 panes wide, so no interactions!
HTH!
Chris,
I will give it a try when I can use MC Browser in 4.5 (will report but will take some time).
Right now I'm in experimenting state and spend most of the time in the debugger. Now my resizing rate is 2 in a debugger. I'll see how that changes.
But a newbie not having your explanation will be lost. And I think we can't afford to loose any newcomer right now.
Cheers,
Herbert
Am 27.01.2014 23:19, schrieb Chris Muller:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net wrote:
- 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.
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.
- 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.
- 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.
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
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.... - 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@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
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
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....
- 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@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
On 27-01-2014, at 4:12 PM, Chris Muller asqueaker@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim I do not fear computers. I fear the lack of them.
- 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.
On Mon, Jan 27, 2014 at 9:20 PM, Chris Muller ma.chris.m@gmail.com 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.
On Mon, Jan 27, 2014 at 8:35 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Jan 27, 2014 at 9:20 PM, Chris Muller ma.chris.m@gmail.com 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. :)
Why not use 3 pedals?
On Jan 27, 2014, at 7:35 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Jan 27, 2014 at 9:20 PM, Chris Muller ma.chris.m@gmail.com 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
+1 for thaïs
Envoyé du iPhone de Raymond
Le 2014-01-27 à 17:19, Chris Muller asqueaker@gmail.com a écrit :
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net wrote:
- 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.
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.
- 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.
- 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.
On 27 Jan 2014, at 22:19, Chris Muller asqueaker@gmail.com wrote:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net wrote:
- 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.
- 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.
- 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.
On 28.01.2014, at 09:36, Frank Shearar frank.shearar@gmail.com wrote:
On 27 Jan 2014, at 22:19, Chris Muller asqueaker@gmail.com wrote:
Hi John-Reed,
On Mon, Jan 27, 2014 at 3:23 PM, JohnReed Maffeo aldeveron@graffiti.net wrote:
- 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
Hello Chris,
On Tue, Jan 28, 2014 at 2:19 AM, Chris Muller asqueaker@gmail.com 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
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
charlie robert -
Chris Muller -
Chris Muller -
Colin Putney -
Eliot Miranda -
Frank Shearar -
Herbert König -
Jeff Gonis -
JohnReed Maffeo -
Nikolay Suslov -
Raymond Asselin -
tim Rowledge -
Tobias Pape