Hi Chris, stop messing with the windows please (was Re: [squeak-dev] The Trunk: Morphic-cmm.344.mcz)

While the changes to opening MC are dubious (in my book) but relatively
harmless, applying the same process to hierarchy browsers stinks.

As I use hierarchy browsers quite a lot, I absolutely DO NOT appreciate
having one that gets reused, losing my previous selection - example:

from the class browser open HB on Array
in the HB, select another class, say ArrayedCollection
in the original class browser, hit the hierarchy button again
and watch the HB being reused and switched to look at Array

I don't advocate writing even more 'smart' code trying to figure out when
to reuse a browser and when not. Just give me a new one, easy.

I'd like to know
1) why you think these changes are good
2) why you push them onto the general mankind(*)
3) why is this not a preference (turned off by default)
4) where will this stop? one window to rule them all? :p

Regards, rado

(*) as I understand it, the trunk process is there for easy pushing of
bugfixes or enhacements to the core squeak, not for aligning core squeak
with one's personal preferences so that they don't have to be
loaded/patched when starting with a new image

On Mon, 15 Feb 2010, [hidden email] wrote:

Hi,

I uploaded Morphic-kb.346 to The Inbox, which adds a preference
controlling the window reusing behaviour. It's disabled by default.

Balázs

Hi radoslav, I thought everyone would cheering with gratitude for this
change!  I'm pretty surprised and sorry you don't like it.

The purpose of the change is to offload work from the user/developer
to the computer by reducing unnecessary window proliferation.  I've
been enjoying the enhanced productivity since 2002.

> While the changes to opening MC are dubious (in my book) but relatively
> harmless, applying the same process to hierarchy browsers stinks.

Wow, dubious?  Why?

> As I use hierarchy browsers quite a lot,

Bravo, I thought I was the only one!  Seems everyone else likes the
"Package" browser; as you said, "one window to rule them all".

> I absolutely DO NOT appreciate
> having one that gets reused, losing my previous selection - example:
>
> from the class browser open HB on Array
> in the HB, select another class, say ArrayedCollection
> in the original class browser, hit the hierarchy button again
> and watch the HB being reused and switched to look at Array

Ok, well, you've described the behavior again, but you haven't told me
WHY you don't like it.  So let me start by describing why I like it.
Basically, any time I find myself fumbling around on the desktop to
"look for a window", I am:

  1) wasting time
  2) wasting energy
  3) getting distracted by contents of the other windows I'm trying to
move "out of the way"
  4) forgetting my train of thought

The point of this enhancement, in combination with the other recent
alternativeBrowseIt improvements is to provide a *straight-line
navigation* from code-to-code.  IOW, the computer takes you from where
you are, to where you want to go, without you having to fish around
for windows.  For me, it has resulted in a much more stream-lined and
productive browsing experience.

A nice side-effect is that I also don't waste time closing the 5700
windows that accumulate due to the systems' dumb opening of new,
redundant, windows all the time.

> I don't advocate writing even more 'smart' code trying to figure out when to
> reuse a browser and when not. Just give me a new one, easy.

I absolutely agree with your principle, but "smart" is giving this way
too much credit.  It's not "trying to figure out" anything; it employs
simple rules that have been used and enjoyed for 8 years.

> I'd like to know
> 1) why you think these changes are good

See above.

> 2) why you push them onto the general mankind(*)

Because I know what's good for you!  :)  Ok, just kidding!  Seriously,
I'm really surprised you don't like it!  If wish I knew better about
why..

> 3) why is this not a preference (turned off by default)

I can't imagine why anyone wouldn't want this.  Reduce window
profileration, reduce work.  Some people like strong modality, or
"click for focus".  These things are pure insanity to me, but then
when it comes to working with softwares, I like to be the punisher,
not the punishee.

> 4) where will this stop? one window to rule them all? :p

What the hell are you talking about?

> (*) as I understand it, the trunk process is there for easy pushing of
> bugfixes or enhacements to the core squeak, not for aligning core squeak
> with one's personal preferences so that they don't have to be loaded/patched
> when starting with a new image

Yep, that's my understanding too.

Regards,
  Chris

Looks good, thanks.  I've copied it to the trunk.

Regardless of how right or wrong I think something is, I should
remember that we establish cerebellum-level connections to software
that need to be treated with consideration.  My apologies.

 - Chris

On Mon, Feb 15, 2010 at 4:19 AM, Balázs Kósi <[hidden email]> wrote:
> Hi,
>
> I uploaded Morphic-kb.346 to The Inbox, which adds a preference
> controlling the window reusing behaviour. It's disabled by default.
>
> Balázs
>
>

On Mon, 15 Feb 2010, Chris Muller wrote:

As I said in the other email (reply to Tobias' message), the fact that
other tools don't reuse windows and MC does is inconsistent, which makes
it a dubious change. I value consistency.

And why I don't like these changes - back when 14" monitors were the norm,
smalltalk IDEs could indeed get quite crowded with all the opened windows,
but nowadays with all the screen estate we have I have no problem keeping
dozens of windows open at the same time/stacked somewhere. For me having
lots of windows is a feature not an annoyance. I routinely change the
color on my windows to group them by "mental context" - red windows
mean stuff I must look at before I close them (say, inserting halts
and such), blue windows might be centered around researching one problem,
and yellow windows for looking at another area etc etc. With such
system, it's highly disruptive when a window in one "context" gets
reused for another context and its original content is lost.

>> 4) where will this stop? one window to rule them all? :p
>
> What the hell are you talking about?

I mean - do you plan to adjust other types of browsers/tools to reuse
existing instances?

Regards, rado

Okay, thanks to both of you.

Regards, rado


On Mon, 15 Feb 2010, Chris Muller wrote:

>>>>> "radoslav" == radoslav hodnicak <[hidden email]> writes:

radoslav> And why I don't like these changes - back when 14" monitors were the
radoslav> norm, smalltalk IDEs could indeed get quite crowded with all the
radoslav> opened windows, but nowadays with all the screen estate we have I
radoslav> have no problem keeping dozens of windows open at the same
radoslav> time/stacked somewhere. For me having lots of windows is a feature
radoslav> not an annoyance.

Do we have something like "Exposé for the mac" for Squeak yet, where I can
push a button and everything slides into sensible non-overlapping reduced
versions and I can select one of them to bring it to the top?  That'd rock.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

I'm running Squeak on an Eee 1005HAB (the latest,) and once I got
Windows 7 Started Edition off it (seriously? DRM on the desktop
wallpaper?) in favour of Ubuntu Netbook Remix, it makes a damned fine
modern Interim Dynabook.

Screen real estate, it doesn't have. We should keep in mind the idea
of a small, portable machine that can change minds and thus, the
future. That said, we should also be careful about changing things
that developers have come to expect about their interactions with the
system.

Chris: awesome! Window clutter is a living hell on a small screen. I
like this much better.

rado: thanks for reminding us that we should tread carefully when we
make assumptions about the way that people interact with the system.

Balázs: thanks for putting in a preference and defaulting it to the
classic behavior! I think this is a very responsible decision.

Everyone wins:)

On Monday, February 15, 2010, Balázs Kósi <[hidden email]> wrote:
> Hi,
>
> I uploaded Morphic-kb.346 to The Inbox, which adds a preference
> controlling the window reusing behaviour. It's disabled by default.
>
> Balázs
>
>


--
Ron

OMG Randal WINS. We do need better window management, especially when
it comes to small screens. The taskbar idea sort of works, but since
we seem largely committed to modelessness, you can't easily group
system windows in meaningful ways (if I'm wrong about this, please
school me.) In any event, without an autohide feature, the task bars
of e.g. Polymorph really detract on small screens. Something like
Exposé would *rock.*

+1

On Monday, February 15, 2010, Randal L. Schwartz <[hidden email]> wrote:
--
Ron

On 15 Feb 2010, at 21:28, Ronald Spengler wrote:

> OMG Randal WINS. We do need better window management, especially when
> it comes to small screens. The taskbar idea sort of works, but since
> we seem largely committed to modelessness, you can't easily group
> system windows in meaningful ways (if I'm wrong about this, please
> school me.) In any event, without an autohide feature, the task bars
> of e.g. Polymorph really detract on small screens. Something like
> Exposé would *rock.*
>

I wrote Scripter for moving windows about and automating stuff

www.squeaksource.com/Scripter

Keith

> Do we have something like "Exposé for the mac" for Squeak yet, where I can
> push a button and everything slides into sensible non-overlapping reduced
> versions and I can select one of them to bring it to the top?  That'd rock.

I haven't seen Exposé, but it sounds like it has the same problem
though.  First that the user is forced to visually scan through a
bunch of windows to answer the following questions.

  1)  "Do I already have a window (minimized or not) that meets my needs?"
  2)  "Is the state of the window such that it can be browsed freely
or is it one in which I've got some unaccepted edits?

Besides being instrusive and distracting, to me, it is just wrong,
fundamentally, for a human to be burdened with such questions that the
machine is able to so easily answer.

Secondly, that if the window _isn't_ there, then you've wasted time
looking and now you have to backtrack (at least mentally) and go find
how to open it.  Shouldn't the just do all of this for me?

But hey, I'll bet Apple gave it a really neato graphical effect on
that Mac!   ;-)

What I want, and what the Reuse Windows preference provides, is a
continuous train-of-thought uninterrupted by fiddling with windows and
widgets..

 - Chris

Exposé is pretty smart. It isn't looking for the things that are
interesting to Squeakers, but it works wonderfully for the mac.

Basically there are hotkeys to fan out:

- all open windows
- all of the current applications windows
- get all the windows out of the way so you can see the desktop

It doesn't sound all that phenominal, except when the windows scale
back, they're still live, and you can see what's going on in them, and
most portantly, drag and drop works fabulously with it. It makes
things you'd have to do some serious window management manuevering on
other systems quite easy and convenient.

On Monday, February 15, 2010, Chris Muller <[hidden email]> wrote:
--
Ron

Long post, bear with me on this one.

On 16 February 2010 05:10, Chris Muller <[hidden email]> wrote:
> Hi radoslav, I thought everyone would cheering with gratitude for this
> change!  I'm pretty surprised and sorry you don't like it.

If this change does what I think it does, then as a completely novice
coder, I'd loathe it too. There's a reason. At my current level of
experience, I don't LIKE to do context switches within one window. For
me, context switches are:
* When I have to choose another function's code to look at, removing
the original source code from view
* Changing tasks (obvious in this case)

I avoid context switches in the first case by opening another window
when I want to compare functions from two separate categories. Will
this change help me to compare code side-by-side? If not, what will
help me?

> The purpose of the change is to offload work from the user/developer
> to the computer by reducing unnecessary window proliferation.  I've
> been enjoying the enhanced productivity since 2002.

And no doubt you're probably a professional coder who holds a
miniature (say, seven-deep) stack of stuff you're following, in your
head. I can't do that, so I resort to using multiple windows instead.
This change sounds like it'd remove all that. For firefox, they had
the sense to at least make tabs. I love tabbed browsing, because even
though there's only one main window, I can switch between sub-windows
without really thinking about it. But this change doesn't sound like
the "tabbed window" kind of thing that firefox et al gives us.


>> While the changes to opening MC are dubious (in my book) but relatively
>> harmless, applying the same process to hierarchy browsers stinks.
>
> Wow, dubious?  Why?
>
>> As I use hierarchy browsers quite a lot,
>
> Bravo, I thought I was the only one!  Seems everyone else likes the
> "Package" browser; as you said, "one window to rule them all".

While I use the Package browser most of all, sometimes I just need to
know what the heck the parent to a particular function is. There, only
a hierarchy browser will do. And sometimes if I'm following two or
three threads of code, then I expect I'd probably use two or three
hierarchy browsers, just to keep all the code sane. Hey, I've got two
screens, I can span all windows over both screens.

Just as a note, I switch between two computers here, using a KVM. Only
one of the computers has two screens, the other computer only has one
screen plugged in (the one I'm switching over each time). On that
system, I'd still prefer to have multiple windows, even though I
haven't got the screen estate to keep it straight.

And is of no use when you want to compare two hierarchies side by
side. If your piece of code is in action, then to get a second
hierarchy browser, I'd have to have TWO package browsers open, and
select a hierarchy browser from each of them. That makes for a total
of ... gee, four windows already. I realise that at this stage, I
could run from the HBs and dispense with the Package browsers...but
there's something about a Package browser that HB doesn't give me... a
list of everything on the system, unless I'm just not using the HB
right.

> A nice side-effect is that I also don't waste time closing the 5700
> windows that accumulate due to the systems' dumb opening of new,
> redundant, windows all the time.

Somewhat true, but again, I'm used to it.

Anyhow, that's my take on it, as a totally amateur coder. Please don't
make my job any harder than it already is. Not unless you're able to
build me a miniature stack inside my head.

Regards, The Viking
(Dr Smokey)

My 2p's worth...

+1 for tabbed browsing plus a browser-like history would be great.

I often have to sideline one issue to deal with another, usually
recursively, but don't like to close or reuse any browsers/ workspaces/
inspectors/ etc associated with a particular issue. In these cases if
windows of any type could be arbitrarily grouped and min/max'ed as a
group then dealing with the natural recursion that happens during
development would be a lot less painful. In the past I used projects for
this purpose but they tend to proliferate quickly and the "project"
concept does not fit well when there is really only one project on the
go. Another problem with projects is rearranging their hierarchy was
never easy.

PS: whatever happened to Whisker Browser?

-D

On 16/02/2010 04:22, Eric Gillespie wrote:
> Long post, bear with me on this one.
>
(... long post thoughtlessly and severely chopped, sorry! ...)
>
> Regards, The Viking
> (Dr Smokey)
>

Dear Dr. Smokey,

> While I use the Package browser most of all, sometimes I just need to
> know what the heck the parent to a particular function is. There, only
> a hierarchy browser will do.

Or, you can select the (i)nheritance option from the methods list.

No, opening a second package browser has no effect on the behavior;
e.g., it would not spawn a second hierarchy browser using the browse
command, because the existing one meets the critieria, it would simply
re-top that one.

Any window is easily duplicated in Squeak via the "duplicate" halo
command.  Just use that to look at multiple codes side-by-side.

 - Chris