[Pharo-users] Alt-tab between windows

[Avdi Grimm]

Hey folks! I've dabbled with smalltalk here and there over the years, but
recently I've settled in to learn Pharo in earnest. A few of you might have
seen the videos I've been putting up; they seem to be making the rounds on
Twitter. I just want to say I've felt really welcomed by all the people who
have commented with helpful tips, or offered to help with my exploration :-)

I've run into my first big blocker as a newcomer. Like many programmers I'm
a fan of keeping my hands on the keyboard. Now, I'm more flexible on this
than some. I recognize that Pharo is a visual environment, and it makes
sense to explore it with a mouse. And some interactions just make more
sense with a mouse.

That said, no matter what windowing environment I'm in, I find the ability
to quickly cycle between windows without leaving the keyboard pretty
crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or
Super-Tab. On MacOS it's Cmd-Tab.

I've been trying to figure out how to do this in Pharo. I've looked for
answers with Google, SO, and on IRC, and I've come up blank. I'm starting
to think it can't be done.

So, I've come here for your help. Is there a way to cycle between windows?
Or is anyone working on it? Or, perhaps, am I missing an element of the
Pharo programming workflow which renders it unneeded?

Many thanks,

--
Avdi

[Nicolai Hess]

Post by Avdi Grimm
Hey folks! I've dabbled with smalltalk here and there over the years, but
recently I've settled in to learn Pharo in earnest. A few of you might have
seen the videos I've been putting up; they seem to be making the rounds on
Twitter. I just want to say I've felt really welcomed by all the people who
have commented with helpful tips, or offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many programmers
I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on
this than some. I recognize that Pharo is a visual environment, and it
makes sense to explore it with a mouse. And some interactions just make
more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the ability
to quickly cycle between windows without leaving the keyboard pretty
crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or
Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've looked for
answers with Google, SO, and on IRC, and I've come up blank. I'm starting
to think it can't be done.
So, I've come here for your help. Is there a way to cycle between windows?
Or is anyone working on it? Or, perhaps, am I missing an element of the
Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi

I miss this too.

This worked in Pharo 1.4 (alt + left arrow / alt+right arrow).

I don't know why this was removed.

I often wanted to look at this and try to bring it back, but didn't find
the time.


nicolai

[Avdi Grimm]

Messing around, I've gotten the impression that Morphic doesn't really have
the concept of a window manager. I've even played with the "Tiling Window
Manager", but it isn't really a *manager* in the usual sense, it's more of
a collection of shortcuts for manually resizing windows.

Without having dove into the implementation yet, it feels like Morphic is
more a system where each window paints itself where it wants to be, and
there isn't a centralized controller or manager of windows. Is that
accurate?

Post by Nicolai Hess

Post by Avdi Grimm
Hey folks! I've dabbled with smalltalk here and there over the years, but
recently I've settled in to learn Pharo in earnest. A few of you might have
seen the videos I've been putting up; they seem to be making the rounds on
Twitter. I just want to say I've felt really welcomed by all the people who
have commented with helpful tips, or offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many programmers
I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on
this than some. I recognize that Pharo is a visual environment, and it
makes sense to explore it with a mouse. And some interactions just make
more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the
ability to quickly cycle between windows without leaving the keyboard
pretty crucial. One Windows or Ubuntu I would normally do this with Alt-Tab
or Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've looked for
answers with Google, SO, and on IRC, and I've come up blank. I'm starting
to think it can't be done.
So, I've come here for your help. Is there a way to cycle between
windows? Or is anyone working on it? Or, perhaps, am I missing an element
of the Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi

I miss this too.
This worked in Pharo 1.4 (alt + left arrow / alt+right arrow).
I don't know why this was removed.
I often wanted to look at this and try to bring it back, but didn't find
the time.
nicolai

[Carlo]

As far as I know you are correct in assumption of morphic windows; especially considering experiences playing with Self where it originated from.
TWM is a way of managing the multiple open windows.

Morphic objects are cool though especially in Squeak or Lively Kernel (Pharo less so) e.g. rotate a workspace or editor and you can edit it while rotated, or resizing it. In Squeak you could start an mpeg video in a morph and then rotate the window or duplicate it while continuing playback. Gimmicky but still cool to see what a few concepts interacting can do.

On 16 May 2015, at 1:05 AM, Avdi Grimm <***@avdi.org> wrote:

Messing around, I've gotten the impression that Morphic doesn't really have the concept of a window manager. I've even played with the "Tiling Window Manager", but it isn't really a *manager* in the usual sense, it's more of a collection of shortcuts for manually resizing windows.

Without having dove into the implementation yet, it feels like Morphic is more a system where each window paints itself where it wants to be, and there isn't a centralized controller or manager of windows. Is that accurate?

On Fri, May 15, 2015 at 6:58 PM Nicolai Hess <***@web.de <mailto:***@web.de>> wrote:


2015-05-16 0:52 GMT+02:00 Avdi Grimm <***@avdi.org <mailto:***@avdi.org>>:
Hey folks! I've dabbled with smalltalk here and there over the years, but recently I've settled in to learn Pharo in earnest. A few of you might have seen the videos I've been putting up; they seem to be making the rounds on Twitter. I just want to say I've felt really welcomed by all the people who have commented with helpful tips, or offered to help with my exploration :-)

I've run into my first big blocker as a newcomer. Like many programmers I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on this than some. I recognize that Pharo is a visual environment, and it makes sense to explore it with a mouse. And some interactions just make more sense with a mouse.

That said, no matter what windowing environment I'm in, I find the ability to quickly cycle between windows without leaving the keyboard pretty crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.

I've been trying to figure out how to do this in Pharo. I've looked for answers with Google, SO, and on IRC, and I've come up blank. I'm starting to think it can't be done.

So, I've come here for your help. Is there a way to cycle between windows? Or is anyone working on it? Or, perhaps, am I missing an element of the Pharo programming workflow which renders it unneeded?

Many thanks,

--
Avdi

I miss this too.

This worked in Pharo 1.4 (alt + left arrow / alt+right arrow).

I don't know why this was removed.

I often wanted to look at this and try to bring it back, but didn't find the time.


nicolai

[Carlo]

Hi

I see my earlier email was bounced again...


Ok, hacked and debugged my pharo 4 image and I've got ctrl- left or right working on my mac.

Two changes needed

TaskListMorph>>keyStroke: event needs to change as per below to add the ctrl left or right.

TaskListMorph>>keyStroke: event
"Process keys to switch task."
event keyCharacter = Character escape ifTrue: [^self delete].
event anyModifierKeyPressed ifFalse: [^self done].

event keyString = '<Ctrl-left>' ifTrue: [^self selectPreviousTask].
event keyString = '<Ctrl-right>' ifTrue: [^self selectNextTask].

event keyString = '<Opt-Shift-tab>' ifTrue: [^self selectPreviousTask].
event keyString = '<Opt-tab>' ifTrue: [^self selectNextTask]

Then TaskListMorph>>isNavigationEvent: aKeyboardEvent needs to change as per below:

isNavigationEvent: aKeyboardEvent
| validCombos |
validCombos := Array with: Character tab alt with: Character tab alt shift with: Character arrowLeft ctrl with: Character arrowRight ctrl .
^ validCombos contains: [:each | each = aKeyboardEvent asKeyCombination].

Ctrl-left or Ctrl-right works, and again you need to press any key to select the window on preview.

Cheers
Carlo

On 16 May 2015, at 1:05 AM, Avdi Grimm <***@avdi.org> wrote:

Messing around, I've gotten the impression that Morphic doesn't really have the concept of a window manager. I've even played with the "Tiling Window Manager", but it isn't really a *manager* in the usual sense, it's more of a collection of shortcuts for manually resizing windows.

Without having dove into the implementation yet, it feels like Morphic is more a system where each window paints itself where it wants to be, and there isn't a centralized controller or manager of windows. Is that accurate?

On Fri, May 15, 2015 at 6:58 PM Nicolai Hess <***@web.de <mailto:***@web.de>> wrote:


2015-05-16 0:52 GMT+02:00 Avdi Grimm <***@avdi.org <mailto:***@avdi.org>>:
Hey folks! I've dabbled with smalltalk here and there over the years, but recently I've settled in to learn Pharo in earnest. A few of you might have seen the videos I've been putting up; they seem to be making the rounds on Twitter. I just want to say I've felt really welcomed by all the people who have commented with helpful tips, or offered to help with my exploration :-)

I've run into my first big blocker as a newcomer. Like many programmers I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on this than some. I recognize that Pharo is a visual environment, and it makes sense to explore it with a mouse. And some interactions just make more sense with a mouse.

That said, no matter what windowing environment I'm in, I find the ability to quickly cycle between windows without leaving the keyboard pretty crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.

I've been trying to figure out how to do this in Pharo. I've looked for answers with Google, SO, and on IRC, and I've come up blank. I'm starting to think it can't be done.

So, I've come here for your help. Is there a way to cycle between windows? Or is anyone working on it? Or, perhaps, am I missing an element of the Pharo programming workflow which renders it unneeded?

Many thanks,

--
Avdi

I miss this too.

This worked in Pharo 1.4 (alt + left arrow / alt+right arrow).

I don't know why this was removed.

I often wanted to look at this and try to bring it back, but didn't find the time.


nicolai

[Sean P. DeNigris]

Post by Avdi Grimm
Messing around, I've gotten the impression that Morphic doesn't really have
the concept of a window manager.

Hee hee. Like most things in Smalltalk, there is much more here than meets
the eye! While pharo's main window looks like a desktop with windows, it is
actually a world of living objects. Morphic is in fact a simulation
framework based on the values of liveness and directness [1], which we are
using to simulate a window system :)

Two quick initial explorations:

Create a morph:
1. DoIt: Morph new openInWorld
2. Click on the Morph while pressing (on Mac) shift+alt to bring up the
Morph's "halo" (like a circular menu). From here, clicking the wrench (right
side, second from the top) and then "inspect morph" will open an inspector
on the object, and you can manipulate it like any other object. For example,
`self color: Color white` immediately turns it white.

As this doesn't seems to be your first rodeo, I'm sure you can quickly
imagine the power of having all one's live UI objects immediately responsive
on the same level as any other object without any context switch.

Treat a window as a Morph:
Repeat #2 above to get the same halos around the window. This is especially
cool when hacking on the IDE because you can bring up the halos on a button,
see what it's action is, and duplicate/modify it. One of the easiest cool
demos, which is actually so easy that it's extremely hard to grok the
implications of it, is to bring up the World menu, hover over a deeply
nested item, bring up the halos on the item, pick it up [2], drop it in the
world, and then click it. Of course it continues to work as if you had
clicked it right in the menu.

[1]
http://web.media.mit.edu/~jmaloney/papers/DirectnessAndLivenessInMorphic.pdf
[2] black button, middle-top, looks like a picker arm in one of those toy
grabbing games they have at diners



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Alt-tab-between-windows-tp4826593p4826731.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Carlo]

Hi Avdi

Enjoyed listening to your ruby rogues podcasts and tapas and now finally Smalltalk;)

Regarding your pain points on keyboard vs mouse; I've seen this come up before. There has been lot's of improvement, but still a way to go.
I tested cycling between windows on Pharo 3 on mac and Alt-tab is working. Pharo 4 looks like someone put a 'self halt' message on the preview window; so I'm assuming there is a newer way to cycle through windows. Removing the 'self halt' still works though.
Oh the alt-tab will bring up a preview window which you need to select window by pressing any other key; so 'alt-tab' until window comes up, then let it go and press any key to select it.

Cheers
Carlo

On 16 May 2015, at 12:52 AM, Avdi Grimm <***@avdi.org> wrote:

Hey folks! I've dabbled with smalltalk here and there over the years, but recently I've settled in to learn Pharo in earnest. A few of you might have seen the videos I've been putting up; they seem to be making the rounds on Twitter. I just want to say I've felt really welcomed by all the people who have commented with helpful tips, or offered to help with my exploration :-)

I've run into my first big blocker as a newcomer. Like many programmers I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on this than some. I recognize that Pharo is a visual environment, and it makes sense to explore it with a mouse. And some interactions just make more sense with a mouse.

That said, no matter what windowing environment I'm in, I find the ability to quickly cycle between windows without leaving the keyboard pretty crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.

I've been trying to figure out how to do this in Pharo. I've looked for answers with Google, SO, and on IRC, and I've come up blank. I'm starting to think it can't be done.

So, I've come here for your help. Is there a way to cycle between windows? Or is anyone working on it? Or, perhaps, am I missing an element of the Pharo programming workflow which renders it unneeded?

Many thanks,

--
Avdi

[Avdi Grimm]

Post by Carlo
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Carlo]

On my

Pharo4.0
Latest update: #40609

Pressing Alt-Tab brings up a debugger. Debugging the method shows:

newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.


On 16 May 2015, at 1:09 AM, Avdi Grimm <***@avdi.org> wrote:



On Fri, May 15, 2015 at 7:06 PM Carlo <***@gmail.com <mailto:***@gmail.com>> wrote:
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Avdi Grimm]

Thanks! Any idea where the keyboard shortcut is assigned? On the only
systems I have handy to test this, the OS catches Alt-Tab before it ever
gets to Pharo.

[stepharo]

Post by Avdi Grimm
Thanks! Any idea where the keyboard shortcut is assigned? On the only
systems I have handy to test this, the OS catches Alt-Tab before it
ever gets to Pharo.

We started to introduce KeyBinding a way to declare binding instead of
hard-coding then.
Now we need to finish to convert all the code to use keybinding.

Stef

[Nicolai Hess]

Post by Carlo
On my
Pharo4.0
Latest update: #40609

But this does not work for Pharo on Windows . On windows alt+tab always
switches between active applications.
There was some code on older versions of pharo, that uses alt+left
arrow/right arrow instead of alt+tab for
the windows vm

Post by Carlo
newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.

Post by Carlo
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Avdi Grimm]

I'd be totally cool with Alt-Left/Right. I just want *something* so I don't
have to lift my hand just to switch from e.g. Browser to Playground and
back.

Post by Nicolai Hess

Post by Carlo
On my
Pharo4.0
Latest update: #40609

But this does not work for Pharo on Windows . On windows alt+tab always
switches between active applications.
There was some code on older versions of pharo, that uses alt+left
arrow/right arrow instead of alt+tab for
the windows vm

Post by Carlo
newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.

Post by Carlo
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Carlo]

Was taking a look in my image and followed references to Character alt or ctrl and found the hooks, but changing them wasn't working.

Remembered now that there is a Keymap Browser under World/System/Keymap Browser
You could try looking at that or wait until someone that knows responds...

Cheers
Carlo




On 16 May 2015, at 1:32 AM, Avdi Grimm <***@avdi.org>

wrote:

I'd be totally cool with Alt-Left/Right. I just want *something* so I don't have to lift my hand just to switch from e.g. Browser to Playground and back.

On Fri, May 15, 2015 at 7:23 PM Nicolai Hess <***@web.de <mailto:***@web.de>> wrote:
2015-05-16 1:11 GMT+02:00 Carlo <***@gmail.com <mailto:***@gmail.com>>:
On my

Pharo4.0
Latest update: #40609

Pressing Alt-Tab brings up a debugger. Debugging the method shows:

But this does not work for Pharo on Windows . On windows alt+tab always switches between active applications.
There was some code on older versions of pharo, that uses alt+left arrow/right arrow instead of alt+tab for
the windows vm



newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.


On 16 May 2015, at 1:09 AM, Avdi G<Screenshot 2015:05:16, 1:11 AM.png>rimm <***@avdi.org <mailto:***@avdi.org>> wrote:



On Fri, May 15, 2015 at 7:06 PM Carlo <***@gmail.com <mailto:***@gmail.com>> wrote:
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Avdi Grimm]

Post by Carlo
Remembered now that there is a Keymap Browser under World/System/Keymap Browser
You could try looking at that or wait until someone that knows responds...

Yeah, there's no listing for Alt-Tab there, which was one of the things
that flummoxed me in the first place.

--
Avdi Grimm
http://avdi.org

[Carlo]

Hi

See my earlier email was bounced.
...

Ok, hacked and debugged my pharo 4 image and I've got ctrl- left or right working on my mac.

Two changes needed

TaskListMorph>>keyStroke: event needs to change as per below to add the ctrl left or right.

TaskListMorph>>keyStroke: event
"Process keys to switch task."
event keyCharacter = Character escape ifTrue: [^self delete].
event anyModifierKeyPressed ifFalse: [^self done].

event keyString = '<Ctrl-left>' ifTrue: [^self selectPreviousTask].
event keyString = '<Ctrl-right>' ifTrue: [^self selectNextTask].

event keyString = '<Opt-Shift-tab>' ifTrue: [^self selectPreviousTask].
event keyString = '<Opt-tab>' ifTrue: [^self selectNextTask]

Then TaskListMorph>>isNavigationEvent: aKeyboardEvent needs to change as per below:

isNavigationEvent: aKeyboardEvent
| validCombos |
validCombos := Array with: Character tab alt with: Character tab alt shift with: Character arrowLeft ctrl with: Character arrowRight ctrl .
^ validCombos contains: [:each | each = aKeyboardEvent asKeyCombination].

Ctrl-left or Ctrl-right works, and again you need to press any key to select the window on preview.

Cheers
Carlo



On 16 May 2015, at 1:32 AM, Avdi Grimm <***@avdi.org> wrote:

I'd be totally cool with Alt-Left/Right. I just want *something* so I don't have to lift my hand just to switch from e.g. Browser to Playground and back.

On Fri, May 15, 2015 at 7:23 PM Nicolai Hess <***@web.de <mailto:***@web.de>> wrote:
2015-05-16 1:11 GMT+02:00 Carlo <***@gmail.com <mailto:***@gmail.com>>:
On my

Pharo4.0
Latest update: #40609

Pressing Alt-Tab brings up a debugger. Debugging the method shows:

But this does not work for Pharo on Windows . On windows alt+tab always switches between active applications.
There was some code on older versions of pharo, that uses alt+left arrow/right arrow instead of alt+tab for
the windows vm



newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.


On 16 May 2015, at 1:09 AM, Avdi G<Screenshot 2015:05:16, 1:11 AM.png>rimm <***@avdi.org <mailto:***@avdi.org>> wrote:



On Fri, May 15, 2015 at 7:06 PM Carlo <***@gmail.com <mailto:***@gmail.com>> wrote:
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Dimitris Chloupis]

does not work for me in macos. Ctrl+left/right is reserved by MACOS for
switching workspaces but even other key combinations i tried do not work at
all. Alt+Tab is also reserved in macos.

Post by Carlo
Hi
See my earlier email was bounced.
...
Ok, hacked and debugged my pharo 4 image and I've got ctrl- left or right
working on my mac.
Two changes needed
TaskListMorph>>keyStroke: event needs to change as per below to add the
ctrl left or right.
TaskListMorph>>keyStroke: event
"Process keys to switch task."
event keyCharacter = Character escape ifTrue: [^self delete].
event anyModifierKeyPressed ifFalse: [^self done].
event keyString = '<Ctrl-left>' ifTrue: [^self selectPreviousTask].
event keyString = '<Ctrl-right>' ifTrue: [^self selectNextTask].
event keyString = '<Opt-Shift-tab>' ifTrue: [^self selectPreviousTask].
event keyString = '<Opt-tab>' ifTrue: [^self selectNextTask]
isNavigationEvent: aKeyboardEvent
| validCombos |
validCombos := Array with: Character tab alt with: Character tab alt shift
with: Character arrowLeft ctrl with: Character arrowRight ctrl .
^ validCombos contains: [:each | each = aKeyboardEvent asKeyCombination].
Ctrl-left or Ctrl-right works, and again you need to press any key to
select the window on preview.
Cheers
Carlo
I'd be totally cool with Alt-Left/Right. I just want *something* so I
don't have to lift my hand just to switch from e.g. Browser to Playground
and back.

Post by Nicolai Hess

Post by Carlo
On my
Pharo4.0
Latest update: #40609

But this does not work for Pharo on Windows . On windows alt+tab always
switches between active applications.
There was some code on older versions of pharo, that uses alt+left
arrow/right arrow instead of alt+tab for
the windows vm

Post by Carlo
newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.
On 16 May 2015, at 1:09 AM, Avdi G<Screenshot 2015:05:16, 1:11 AM.png>rimm

Post by Carlo
Removing the 'self halt' still works though.

Can you give me a little more detail about where to find this? Thanks!

[Esteban Lorenzano]

my answer on stackoverflow:

well... you hit one of our weaker spots :)

Keybindings are not in his best shape, but:

- Actually, alt+tab is already set to "switch window" activity. The problem is that does not work all the time (for example, it does not work on Playground).
- This is because there are some hardcoded logic there, who we are removing slowly from the system (some of those parts have more than 15yrs since they come from before Pharo has born).
- Someone (probably in a failed attempt to fix the playground, or the hardcodes) forget a halt in the method who creates a new preview window... so even if you reach that part of the system, you will have a debugger. Of course, you will be able to restore correct behaviour by just removing the breakpoint, but that will not correct the fact "switch windows" will not be available everywhere.
- I opened a bug entry for it: https://pharo.fogbugz.com/f/cases/15546, in case you want to follow the issue (you will need an account there, I'm sorry for that).

In any case, we are moving out this hardcode stuff, and you can check all currently available settings going to **World Menu/System/Keymap Browser** (they are a lot, we are also playing with ideas on how to show better this combinations... emacs style, popup notifications, etc.)

Esteban

ps: I will like to have a solution for this, if anyone can help a bit in this area
 but it has to be a solution using the keybindings framework. I will deny integration to any hardcoded solution :)

does not work for me in macos. Ctrl+left/right is reserved by MACOS for switching workspaces but even other key combinations i tried do not work at all. Alt+Tab is also reserved in macos.
Hi
See my earlier email was bounced.
...
Ok, hacked and debugged my pharo 4 image and I've got ctrl- left or right working on my mac.
Two changes needed
TaskListMorph>>keyStroke: event needs to change as per below to add the ctrl left or right.
TaskListMorph>>keyStroke: event
"Process keys to switch task."
event keyCharacter = Character escape ifTrue: [^self delete].
event anyModifierKeyPressed ifFalse: [^self done].
event keyString = '<Ctrl-left>' ifTrue: [^self selectPreviousTask].
event keyString = '<Ctrl-right>' ifTrue: [^self selectNextTask].
event keyString = '<Opt-Shift-tab>' ifTrue: [^self selectPreviousTask].
event keyString = '<Opt-tab>' ifTrue: [^self selectNextTask]
isNavigationEvent: aKeyboardEvent
| validCombos |
validCombos := Array with: Character tab alt with: Character tab alt shift with: Character arrowLeft ctrl with: Character arrowRight ctrl .
^ validCombos contains: [:each | each = aKeyboardEvent asKeyCombination].
Ctrl-left or Ctrl-right works, and again you need to press any key to select the window on preview.
Cheers
Carlo
I'd be totally cool with Alt-Left/Right. I just want *something* so I don't have to lift my hand just to switch from e.g. Browser to Playground and back.
On my
Pharo4.0
Latest update: #40609
But this does not work for Pharo on Windows . On windows alt+tab always switches between active applications.
There was some code on older versions of pharo, that uses alt+left arrow/right arrow instead of alt+tab for
the windows vm
newPreviewMorph
"Answer a new preview holder."
self halt.
^ Morph new
color: Color transparent;
extent: self defaultPreviewExtent;
yourself.
Removing the 'self halt' still works though.
Can you give me a little more detail about where to find this? Thanks!

[Ben Coman]

Post by Esteban Lorenzano
well... you hit one of our weaker spots :)
- Actually, alt+tab is already set to "switch window" activity. The
problem is that does not work all the time (for example, it does not work
on Playground).
- This is because there are some hardcoded logic there, who we are
removing slowly from the system (some of those parts have more than 15yrs
since they come from before Pharo has born).
- Someone (probably in a failed attempt to fix the playground, or the
hardcodes) forget a halt in the method who creates a new preview window...
so even if you reach that part of the system, you will have a debugger. Of
course, you will be able to restore correct behaviour by just removing the
breakpoint, but that will not correct the fact "switch windows" will not be
available everywhere.
- I opened a bug entry for it: https://pharo.fogbugz.com/f/cases/15546,
in case you want to follow the issue (you will need an account there, I'm
sorry for that).
In any case, we are moving out this hardcode stuff, and you can check all
currently available settings going to **World Menu/System/Keymap Browser**
(they are a lot, we are also playing with ideas on how to show better this
combinations... emacs style, popup notifications, etc.)
Esteban
ps: I will like to have a solution for this, if anyone can help a bit in
this area
 but it has to be a solution using the keybindings framework. I
will deny integration to any hardcoded solution :)

I thought I'd have a look at this (a reason to dip my toe into the
keybindings framework for the first time). Not sure if I'm heading down the
right track, but the first part of just responding to key presses was much
easier than I thought it might be, so I thought there might be general
interest. So far I've just done...

KMCategory subclass: #TaskListGlobalShortcut
instanceVariableNames: ''
classVariableNames: ''
category: 'Morphic-Widgets-Taskbar'

TaskListGlobalShortcut >> isGlobalCategory
^true

TaskListGlobalShortcut >> cycleLeft
<shortcut>
^ KMKeymap
shortcut: $[ command
action: [ self inform: 'cycle window left' ]

TaskListGlobalShortcut >> cycleRight
<shortcut>
^ KMKeymap
shortcut: $] command
action: [ self inform: 'cycle window right' ]

KMRepository reset.

</feeling='small sense of achievement'>

cheers -ben

[Ben Coman]

Post by Ben Coman

Post by Esteban Lorenzano
well... you hit one of our weaker spots :)
- Actually, alt+tab is already set to "switch window" activity. The
problem is that does not work all the time (for example, it does not work
on Playground).
- This is because there are some hardcoded logic there, who we are
removing slowly from the system (some of those parts have more than 15yrs
since they come from before Pharo has born).
- Someone (probably in a failed attempt to fix the playground, or the
hardcodes) forget a halt in the method who creates a new preview window...
so even if you reach that part of the system, you will have a debugger. Of
course, you will be able to restore correct behaviour by just removing the
breakpoint, but that will not correct the fact "switch windows" will not be
available everywhere.
- I opened a bug entry for it: https://pharo.fogbugz.com/f/cases/15546,
in case you want to follow the issue (you will need an account there, I'm
sorry for that).
In any case, we are moving out this hardcode stuff, and you can check all
currently available settings going to **World Menu/System/Keymap Browser**
(they are a lot, we are also playing with ideas on how to show better this
combinations... emacs style, popup notifications, etc.)
Esteban
ps: I will like to have a solution for this, if anyone can help a bit in
this area
 but it has to be a solution using the keybindings framework. I
will deny integration to any hardcoded solution :)

I thought I'd have a look at this (a reason to dip my toe into the
keybindings framework for the first time). Not sure if I'm heading down the
right track, but the first part of just responding to key presses was much
easier than I thought it might be, so I thought there might be general
interest.

Here it is fully working. Note the correction moving #isGlobal to the
class-side.

Post by Ben Coman
KMCategory subclass: #TaskListGlobalShortcut
instanceVariableNames: ''
classVariableNames: ''
category: 'Morphic-Widgets-Taskbar'
TaskListGlobalShortcut class >> isGlobalCategory "<---whoops,
correction"
^true

I discovered that to match existing method names, #selectNextTask was
better than #cycleLeft.

TaskListGlobalShortcut>>selectNextTask
<shortcut>
^ KMKeymap
shortcut: $] command
action: [ World taskList selectNextTask. ]


TaskListGlobalShortcut>>selectPreviousTask
<shortcut>
^ KMKeymap
shortcut: $[ command
action: [ World taskList selectPreviousTask. ]


NullTaskList>>selectNextTask
self openTaskList selectNextTask


NullTaskList>>selectPreviousTask
self openTaskList selectPreviousTask


NullTaskList>>openTaskList
^ world theme openTaskListIn: world.
" Adapted from NullTaskList >> handleEvent: "


UITheme>>openTaskListIn: worldMorph
| taskListMorph |
taskListMorph := TaskListMorph new.
taskListMorph openAsIsIn: worldMorph.
^ taskListMorph
"Adapted from UITheme >> openTaskListIn:from: "


KMRepository reset.


This was developed on Pharo 4, but I
uploaded SLICE-Issue-15546-alttab-does-not-work-correctly-BenComan.2 to
Pharo5Inbox per policy to integrate there first. I guess since this is
not mission critical it might be queued for a while for Pharo 4.

Nicolai, I didn't see your slice until after. I've left some comments on
fogbugz comparing the both slices.

cheers -ben

[stepharo]

Post by Carlo
Hi Avdi
Enjoyed listening to your ruby rogues podcasts and tapas and now finally Smalltalk;)
Regarding your pain points on keyboard vs mouse; I've seen this come up before. There has been lot's of improvement, but still a way to go.
I tested cycling between windows on Pharo 3 on mac and Alt-tab is working. Pharo 4 looks like someone put a 'self halt' message on the preview window; so I'm assuming there is a newer way to cycle through windows. Removing the 'self halt' still works though.
Oh the alt-tab will bring up a preview window which you need to select window by pressing any other key; so 'alt-tab' until window comes up, then let it go and press any key to select it.

Can you open a bug entry with a nice description if there is something
that we should do?

Stef

Post by Carlo
Cheers
Carlo
Hey folks! I've dabbled with smalltalk here and there over the years, but recently I've settled in to learn Pharo in earnest. A few of you might have seen the videos I've been putting up; they seem to be making the rounds on Twitter. I just want to say I've felt really welcomed by all the people who have commented with helpful tips, or offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many programmers I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on this than some. I recognize that Pharo is a visual environment, and it makes sense to explore it with a mouse. And some interactions just make more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the ability to quickly cycle between windows without leaving the keyboard pretty crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've looked for answers with Google, SO, and on IRC, and I've come up blank. I'm starting to think it can't be done.
So, I've come here for your help. Is there a way to cycle between windows? Or is anyone working on it? Or, perhaps, am I missing an element of the Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi

[Laurent]

Hi Avdi,

you may be interested in
http://smalltalkhub.com/#!/~LaurentLaffont/TilingWindowManager that
offers more keyboard control (Emacs inspired) on window management.

Regards,

Laurent Laffont

Post by Avdi Grimm
Hey folks! I've dabbled with smalltalk here and there over the years,
but recently I've settled in to learn Pharo in earnest. A few of you
might have seen the videos I've been putting up; they seem to be
making the rounds on Twitter. I just want to say I've felt really
welcomed by all the people who have commented with helpful tips, or
offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many
programmers I'm a fan of keeping my hands on the keyboard. Now, I'm
more flexible on this than some. I recognize that Pharo is a visual
environment, and it makes sense to explore it with a mouse. And some
interactions just make more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the
ability to quickly cycle between windows without leaving the keyboard
pretty crucial. One Windows or Ubuntu I would normally do this with
Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've looked
for answers with Google, SO, and on IRC, and I've come up blank. I'm
starting to think it can't be done.
So, I've come here for your help. Is there a way to cycle between
windows? Or is anyone working on it? Or, perhaps, am I missing an
element of the Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi

[stepharo]

Post by Avdi Grimm
Hey folks! I've dabbled with smalltalk here and there over the years,
but recently I've settled in to learn Pharo in earnest. A few of you
might have seen the videos I've been putting up; they seem to be
making the rounds on Twitter. I just want to say I've felt really
welcomed by all the people who have commented with helpful tips, or
offered to help with my exploration :-)

Welcome

Post by Avdi Grimm
I've run into my first big blocker as a newcomer. Like many
programmers I'm a fan of keeping my hands on the keyboard. Now, I'm
more flexible on this than some. I recognize that Pharo is a visual
environment, and it makes sense to explore it with a mouse. And some
interactions just make more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the
ability to quickly cycle between windows without leaving the keyboard
pretty crucial. One Windows or Ubuntu I would normally do this with
Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've looked
for answers with Google, SO, and on IRC, and I've come up blank. I'm
starting to think it can't be done.
So, I've come here for your help. Is there a way to cycle between
windows? Or is anyone working on it? Or, perhaps, am I missing an
element of the Pharo programming workflow which renders it unneeded?

I'm not really happy with the state of the keybindings but too busy to
be able to fix anything for now on this part.
Now if people wants to help they are more then welcome.

Stef

[Tudor Girba]

Hi Avdi,

Welcome.

As the others mentioned, this part of Pharo is not at all ideal. Please
bare with us.

Cheers,
Doru

Post by Avdi Grimm
Hey folks! I've dabbled with smalltalk here and there over the years, but
recently I've settled in to learn Pharo in earnest. A few of you might have
seen the videos I've been putting up; they seem to be making the rounds on
Twitter. I just want to say I've felt really welcomed by all the people who
have commented with helpful tips, or offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many programmers
I'm a fan of keeping my hands on the keyboard. Now, I'm more flexible on
this than some. I recognize that Pharo is a visual environment, and it
makes sense to explore it with a mouse. And some interactions just make
more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the ability
to quickly cycle between windows without leaving the keyboard pretty
crucial. One Windows or Ubuntu I would normally do this with Alt-Tab or
Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've looked for
answers with Google, SO, and on IRC, and I've come up blank. I'm starting
to think it can't be done.
So, I've come here for your help. Is there a way to cycle between windows?
Or is anyone working on it? Or, perhaps, am I missing an element of the
Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi

[j***@objektfabrik.de]

Avdi,

I mostly work in other Smalltalk environments than Pharo, like VA
Smalltalk. It has native windows and so the ability to switch between
windows using alt-tab is there. I must admit that there is a certain
threshold in the number of open windows when this is not really helpful
any more. I tend to hit that number pretty fast in a typical Smalltalk
coding/debugging sessions.

Things have changed in Win 7, because there I can use the window manager
to close the windows right in the window switcher. That makes perfect
sense if you have 15 inspectors open, none of which shows current data
or instances any more. Or if one of them does, I can't decide which one ;-)

So sometimes I wish for features like "close all windows of this kind"
to kill all inspectors, for example.

What I want to say with this that I am not really using alt-tab to
switch between windows, but rather to kill a few to come down to a
sensible number ;-) But I understand why you miss it. For Pharo, there
is a special problem: it is its own windowing environment, so it should
probably better not use the O/S' key combination to switch its windows,
right?

Joachim

Post by Laurent
Hi Avdi,
Welcome.
As the others mentioned, this part of Pharo is not at all ideal.
Please bare with us.
Cheers,
Doru
Hey folks! I've dabbled with smalltalk here and there over the
years, but recently I've settled in to learn Pharo in earnest. A
few of you might have seen the videos I've been putting up; they
seem to be making the rounds on Twitter. I just want to say I've
felt really welcomed by all the people who have commented with
helpful tips, or offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many
programmers I'm a fan of keeping my hands on the keyboard. Now,
I'm more flexible on this than some. I recognize that Pharo is a
visual environment, and it makes sense to explore it with a mouse.
And some interactions just make more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the
ability to quickly cycle between windows without leaving the
keyboard pretty crucial. One Windows or Ubuntu I would normally do
this with Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've
looked for answers with Google, SO, and on IRC, and I've come up
blank. I'm starting to think it can't be done.
So, I've come here for your help. Is there a way to cycle between
windows? Or is anyone working on it? Or, perhaps, am I missing an
element of the Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"

[Avdi Grimm]

Post by j***@objektfabrik.de
I mostly work in other Smalltalk environments than Pharo, like VA
Smalltalk. It has native windows and so the ability to switch between
windows using alt-tab is there. I must admit that there is a certain
threshold in the number of open windows when this is not really helpful any
more. I tend to hit that number pretty fast in a typical Smalltalk
coding/debugging sessions.
Things have changed in Win 7, because there I can use the window manager
to close the windows right in the window switcher. That makes perfect sense
if you have 15 inspectors open, none of which shows current data or
instances any more. Or if one of them does, I can't decide which one ;-)
So sometimes I wish for features like "close all windows of this kind" to
kill all inspectors, for example.
What I want to say with this that I am not really using alt-tab to switch
between windows, but rather to kill a few to come down to a sensible number
;-) But I understand why you miss it. For Pharo, there is a special
problem: it is its own windowing environment, so it should probably better
not use the O/S' key combination to switch its windows, right?

Just as some food for thought for anyone contemplating this problem:

Sometimes problems like this are indicative of deeper usability issues.
Decades ago, it was just sort of assumed that the "right" way to deal with
windows was to have a dedicated window for every "thing" in your system. To
some degree, Mac OS, Wind95, and OS/2 all took this point of view. For
instance, every folder you double-clicked on would open up a new file
manager window, and this got to be such a mess that some OSes included
"secret" shortcuts for killing them all at once.

Then the web started to take off, and UX designers started rethinking the
whole paradigm. They started keeping things in the same window, but adding
back/forward buttons, and navigation histories, and sidebars, and address
bars, and tabs, and other affordances to make it easier to switch between
"things" without necessarily adding more windows.

These days, most IDEs and editors have followed suit. I can't think of a
single editor in common use among the programmers I know which encourages
multiple windows. Whether it's Vim, Emacs, Sublime, IntelliJ, while you
*can* open lots of windows if you really want to, they all focus on making
it easy to manage lots of buffers in a single window rather than
encouraging lots of windows.

Personally, I'm a fan of this trend. I'm much happier typing a few
characters to auto-complete the buffer I want to return to in Emacs, than I
am hunting around in an OS window list for it.

This is all a long-winded way of saying: just because this is currently a
problem, doesn't mean it's the *right* problem. It would be interesting to
see what a "fewer windows" approach to Smalltalk development might look
like.

--
Avdi Grimm
http://avdi.org

[Ben Coman]

Post by Avdi Grimm

Post by j***@objektfabrik.de
I mostly work in other Smalltalk environments than Pharo, like VA
Smalltalk. It has native windows and so the ability to switch between
windows using alt-tab is there. I must admit that there is a certain
threshold in the number of open windows when this is not really helpful any
more. I tend to hit that number pretty fast in a typical Smalltalk
coding/debugging sessions.
Things have changed in Win 7, because there I can use the window manager
to close the windows right in the window switcher. That makes perfect sense
if you have 15 inspectors open, none of which shows current data or
instances any more. Or if one of them does, I can't decide which one ;-)
So sometimes I wish for features like "close all windows of this kind" to
kill all inspectors, for example.
What I want to say with this that I am not really using alt-tab to switch
between windows, but rather to kill a few to come down to a sensible number
;-) But I understand why you miss it. For Pharo, there is a special
problem: it is its own windowing environment, so it should probably better
not use the O/S' key combination to switch its windows, right?

Sometimes problems like this are indicative of deeper usability issues.
Decades ago, it was just sort of assumed that the "right" way to deal with
windows was to have a dedicated window for every "thing" in your system. To
some degree, Mac OS, Wind95, and OS/2 all took this point of view. For
instance, every folder you double-clicked on would open up a new file
manager window, and this got to be such a mess that some OSes included
"secret" shortcuts for killing them all at once.
Then the web started to take off, and UX designers started rethinking the
whole paradigm. They started keeping things in the same window, but adding
back/forward buttons, and navigation histories, and sidebars, and address
bars, and tabs, and other affordances to make it easier to switch between
"things" without necessarily adding more windows.
These days, most IDEs and editors have followed suit. I can't think of a
single editor in common use among the programmers I know which encourages
multiple windows. Whether it's Vim, Emacs, Sublime, IntelliJ, while you
*can* open lots of windows if you really want to, they all focus on making
it easy to manage lots of buffers in a single window rather than
encouraging lots of windows.
Personally, I'm a fan of this trend. I'm much happier typing a few
characters to auto-complete the buffer I want to return to in Emacs, than I
am hunting around in an OS window list for it.
This is all a long-winded way of saying: just because this is currently a
problem, doesn't mean it's the *right* problem. It would be interesting to
see what a "fewer windows" approach to Smalltalk development might look
like.

This is an interesting UI area to explore. As a step in this direction,
the Window Menu (small arrow in title bar) item "Create window group" may
provide part of the behaviour you are looking for.
cheers -ben

[Avdi Grimm]

As a step in this direction, the Window Menu (small arrow in title
bar) item "Create window group" may provide part of the behaviour you are
looking for.

Interesting! How does one add more than one window to the group? Is there
more info on this somewhere?

--
Avdi Grimm
http://avdi.org

[Laurent]

Post by Avdi Grimm

As a step in this direction, the Window Menu (small arrow in title
bar) item "Create window group" may provide part of the behaviour
you are looking for.

Interesting! How does one add more than one window to the group? Is
there more info on this somewhere?

This work comes from TilingWindowManager and has been reified into
GroupWindowMorph in Pharo3. With TWM comes TWMDockingWindowMorph with
opens a docking panel where you can put windows.

See https://vimeo.com/26346973 and open it with: TWMDockingWindowMorph
new openInWorld

Laurent

Post by Avdi Grimm
--
Avdi Grimm
http://avdi.org

[Dimitris Chloupis]

As you linked in your blog post there are my video tutorials , one of them
are about window groups

About general GUI and UI designs its not any less nightmarish to open
multiple windows in Pharo than it is to open multiple buffers in emacs. The
diffirence between the two is that with emacs you have the nightmare of
lack of any GUI while in pharo you have the lack of sophisticated editing.

My personal opinion on UIs is that I look around and all I see is a huge
mess. The modern effort to turn to minimalism and try to minimise this
phenomenon , fails miserably. Web is even messier because of fragmentation
and lack of cohesion you ending up with a billion different UIs that fail
the same way. What the modern world needs is not minimalism but rather I
high complex system that can deal with complexity and extremely varied
demands. That would require a large body of developers to sit down and do
thorough research to solve the problem of ever increasingly complex
software.

I work with 3d graphics that are notorious for their inherit complexity,
the situation has been getting so bad lately , that age of "one software to
rule them all" has come to pass and we see more and more fragmentation that
makes life even more difficult.

Pharo is doing some good work on this area but realistically , the
community is too small to solve such a huge problem even with pharo ease of
use.

Post by Avdi Grimm

As a step in this direction, the Window Menu (small arrow in title
bar) item "Create window group" may provide part of the behaviour you are
looking for.

Interesting! How does one add more than one window to the group? Is there
more info on this somewhere?
--
Avdi Grimm
http://avdi.org

[Avdi Grimm]

Post by Dimitris Chloupis
About general GUI and UI designs its not any less nightmarish to open
multiple windows in Pharo than it is to open multiple buffers in emacs. The
diffirence between the two is that with emacs you have the nightmare of
lack of any GUI while in pharo you have the lack of sophisticated editing.

With respect, this is manifestly untrue. Buffer management is a solved
problem in Emacs. In fact, it's been solved and re-solved many times over,
to the point where it can suit anyone's tastes. Whether you want:

* To simply toggle between the last few buffers
* To list, sort, and filter buffers quickly until you find the one you want
* To do fuzzy-completed searches on buffers
* To manage buffers in tabs and tab groups
* To have sidebars listing open buffers
* To kill or operate on many buffers at once based on what project they are
in or some other criteria
* To have a fully window-managed interface that can save, reload, and
switch between different window configurations for different contexts at a
keypress
* To forget about buffers completely, and just navigate to the thing you
want to see (and let Emacs worry about what buffers happen to be in memory)

(And lest anyone say that buffer management is a different problem from
window management, remember that Emacs is an application environment, and
that a "buffer" may be a full application window, such as an IRC channel or
even a Smalltalk-style browser.)

Whether you want any of these features or many others, there are mature and
well-tests solutions for all of them. Whereas as many longtime users have
confirmed in this thread, Smalltalk environments don't even have the window
management to match the Emacs built-in features, let alone the mature
extension ecosystem.

I made my original seven-minute Pharo video with the intent of getting
traditionally IDE-averse Ruby programmers to realize some of the things
they are missing. It's way too easy to say "oh, no one else has solved
this any better". And as a result, a number of people said "wow, I usually
hate IDEs but I need to check this out". But this cuts both ways.

Post by Dimitris Chloupis
Pharo is doing some good work on this area but realistically , the
community is too small to solve such a huge problem even with pharo ease of
use.

This I agree with completely.

My favorite OS for programming is Linux. In linux, window management is a
problem that has been solved many times over. There are dozens of window
managers (hundreds, if you count inactive projects). There are high-tech
compositing window managers that can do MacOS-style Expose zoom-out for
quickly locating windows. There are WMs that rigidly control where windows
show up, based on a policy you decide. There are all kinds of different
aids for quickly listing and navigating between windows.

It took thousands of programmers decades of work in many different
languages to create this variety. I'd hate to see the smaller Pharo
community pour tons of effort into re-inventing these solutions.

Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been
solved many times over. Do you really want to do it yet again? I suspect
that with some careful examination of Pharo coding workflows, you could
find a way to obviate the need for zillions of windows, and solve a simpler
problem instead.

[Esteban A. Maringolo]

It took thousands of programmers decades of work in many different languages
to create this variety. I'd hate to see the smaller Pharo community pour
tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been solved
many times over. Do you really want to do it yet again? I suspect that with
some careful examination of Pharo coding workflows, you could find a way to
obviate the need for zillions of windows, and solve a simpler problem
instead.

+1

Esteban A. Maringolo

[Esteban Lorenzano]

Post by Esteban A. Maringolo

It took thousands of programmers decades of work in many different languages
to create this variety. I'd hate to see the smaller Pharo community pour
tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been solved
many times over. Do you really want to do it yet again? I suspect that with
some careful examination of Pharo coding workflows, you could find a way to
obviate the need for zillions of windows, and solve a simpler problem
instead.

+1

+1

Esteban

ps: (and two Esteban’s counts exponentially :P)
pps: but there are also other problems to take into account, and that’s also community culture. I know many people finds the amount of windows opened somekind stressing when they arrive to our little world… but it actually fits a purpose and change it to other solutions just because “everybody else does it” can probably do not work. A suitable solution for LISP does not need to be a suitable solution to Pharo, just out of the box. Which of course does not means I would not want to explore more efficient workflows.
ppps: And of course, there is the effort that starting in other direction goes… even copying an existing IDE workflow would be a lot of work for us, so sometimes is better just to incrementally enhance, even if that means we will keep some metaphors during more time than desired.
pppps: as I always say in this list, human-computer interaction is not an easy field and is very studied, so is not easily solvable with our always subjective opinion. In that sense, I completely share the feeling that we need to keep studying and experimenting with other communities experiences until we find something that we can reengineer into something we need/want.
ppppps: I ran out of “ps”, but I couldn’t resist to put five “p" in a line :)

Post by Esteban A. Maringolo
Esteban A. Maringolo

[Esteban Lorenzano]

ah, couple of things more (out of ps :P)

I do believe Spotter will play a fundamental role in the enhancement of our IDE, but I was also thinking on some kind of “emacs style menus”, in the sense of some guiding menus that you open with a key and you have an idea of which options you look. This could also be something integrated in the spotter in the way unity of ubuntu is going (you type “save” and you have the options, etc.)
Anyway
 nothing that I found the time to test for the moment, but I will.

And none of this options will heal our “windowitis” decease
 and honestly I do not have any idea how we can enhance that. To hide infinite windows into infinite tabs (or buffers) does not feels like the correct solution for me (I remember beck in my java days, I sually kept more than 20 tabs open all the time
 same with browsers here in pharo, but now I also open inspectors, playgrounds and debuggers
 so
 is a complicated issue).

Or maybe I’m wrong, and maybe just reducing the visual contamination is already a big step forward
 who knows. Actually, we will not know until we try it
 just saying “no” is not a very constructive opinion.

But in that case, the question is “who will bell the cat” :)

Esteban

Post by Esteban Lorenzano

Post by Esteban A. Maringolo

It took thousands of programmers decades of work in many different languages
to create this variety. I'd hate to see the smaller Pharo community pour
tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been solved
many times over. Do you really want to do it yet again? I suspect that with
some careful examination of Pharo coding workflows, you could find a way to
obviate the need for zillions of windows, and solve a simpler problem
instead.

+1

+1
Esteban
ps: (and two Esteban’s counts exponentially :P)
pps: but there are also other problems to take into account, and that’s also community culture. I know many people finds the amount of windows opened somekind stressing when they arrive to our little world
 but it actually fits a purpose and change it to other solutions just because “everybody else does it” can probably do not work. A suitable solution for LISP does not need to be a suitable solution to Pharo, just out of the box. Which of course does not means I would not want to explore more efficient workflows.
ppps: And of course, there is the effort that starting in other direction goes
 even copying an existing IDE workflow would be a lot of work for us, so sometimes is better just to incrementally enhance, even if that means we will keep some metaphors during more time than desired.
pppps: as I always say in this list, human-computer interaction is not an easy field and is very studied, so is not easily solvable with our always subjective opinion. In that sense, I completely share the feeling that we need to keep studying and experimenting with other communities experiences until we find something that we can reengineer into something we need/want.
ppppps: I ran out of “ps”, but I couldn’t resist to put five “p" in a line :)

Post by Esteban A. Maringolo
Esteban A. Maringolo

[Avdi Grimm]

I dunno if this is useful to anyone, but I was rolling around concepts in
my mind and this is something I came up with:

[image: Inline image 1]

This takes some queues from modern IDEs, but it also differs in that it
doesn't make the assumption that you want to see just one "buffer" at a
time, and that "split window mode" isn't sufficiently powerful to handle
the need for lots of windows open on lots of little methods.

--
Avdi Grimm
http://avdi.org

Post by Esteban Lorenzano
ah, couple of things more (out of ps :P)
I do believe Spotter will play a fundamental role in the enhancement of
our IDE, but I was also thinking on some kind of “emacs style menus”, in
the sense of some guiding menus that you open with a key and you have an
idea of which options you look. This could also be something integrated in
the spotter in the way unity of ubuntu is going (you type “save” and you
have the options, etc.)
Anyway
 nothing that I found the time to test for the moment, but I will.
And none of this options will heal our “windowitis” decease
 and honestly
I do not have any idea how we can enhance that. To hide infinite windows
into infinite tabs (or buffers) does not feels like the correct solution
for me (I remember beck in my java days, I sually kept more than 20 tabs
open all the time
 same with browsers here in pharo, but now I also open
inspectors, playgrounds and debuggers
 so
 is a complicated issue).
Or maybe I’m wrong, and maybe just reducing the visual contamination is
already a big step forward
 who knows. Actually, we will not know until we
try it
 just saying “no” is not a very constructive opinion.
But in that case, the question is “who will bell the cat” :)
Esteban
It took thousands of programmers decades of work in many different languages
to create this variety. I'd hate to see the smaller Pharo community pour
tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been solved
many times over. Do you really want to do it yet again? I suspect that with
some careful examination of Pharo coding workflows, you could find a way to
obviate the need for zillions of windows, and solve a simpler problem
instead.
+1
+1
Esteban
ps: (and two Esteban’s counts exponentially :P)
pps: but there are also other problems to take into account, and that’s
also community culture. I know many people finds the amount of windows
opened somekind stressing when they arrive to our little world
 but it
actually fits a purpose and change it to other solutions just because
“everybody else does it” can probably do not work. A suitable solution for
LISP does not need to be a suitable solution to Pharo, just out of the box.
Which of course does not means I would not want to explore more efficient
workflows.
ppps: And of course, there is the effort that starting in other direction
goes
 even copying an existing IDE workflow would be a lot of work for us,
so sometimes is better just to incrementally enhance, even if that means we
will keep some metaphors during more time than desired.
pppps: as I always say in this list, human-computer interaction is not an
easy field and is very studied, so is not easily solvable with our always
subjective opinion. In that sense, I completely share the feeling that we
need to keep studying and experimenting with other communities experiences
until we find something that we can reengineer into something we need/want.
ppppps: I ran out of “ps”, but I couldn’t resist to put five “p" in a line
:)
Esteban A. Maringolo

[Avdi Grimm]

Note that what I didn't have time to address in that mockup is the idea
that pop-ups like the Spotter would be the principle way to add new morphs
to the central list. Also, I don't think that the list should necessarily
be constrained to JUST the code half a of browser window; there could be
debuggers in there, extra playgrounds, etc.

--
Avdi Grimm
http://avdi.org

Post by Avdi Grimm
I dunno if this is useful to anyone, but I was rolling around concepts in
[image: Inline image 1]
This takes some queues from modern IDEs, but it also differs in that it
doesn't make the assumption that you want to see just one "buffer" at a
time, and that "split window mode" isn't sufficiently powerful to handle
the need for lots of windows open on lots of little methods.
--
Avdi Grimm
http://avdi.org

Post by Esteban Lorenzano
ah, couple of things more (out of ps :P)
I do believe Spotter will play a fundamental role in the enhancement of
our IDE, but I was also thinking on some kind of “emacs style menus”, in
the sense of some guiding menus that you open with a key and you have an
idea of which options you look. This could also be something integrated in
the spotter in the way unity of ubuntu is going (you type “save” and you
have the options, etc.)
Anyway
 nothing that I found the time to test for the moment, but I will.
And none of this options will heal our “windowitis” decease
 and honestly
I do not have any idea how we can enhance that. To hide infinite windows
into infinite tabs (or buffers) does not feels like the correct solution
for me (I remember beck in my java days, I sually kept more than 20 tabs
open all the time
 same with browsers here in pharo, but now I also open
inspectors, playgrounds and debuggers
 so
 is a complicated issue).
Or maybe I’m wrong, and maybe just reducing the visual contamination is
already a big step forward
 who knows. Actually, we will not know until we
try it
 just saying “no” is not a very constructive opinion.
But in that case, the question is “who will bell the cat” :)
Esteban
It took thousands of programmers decades of work in many different languages
to create this variety. I'd hate to see the smaller Pharo community pour
tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been solved
many times over. Do you really want to do it yet again? I suspect that with
some careful examination of Pharo coding workflows, you could find a way to
obviate the need for zillions of windows, and solve a simpler problem
instead.
+1
+1
Esteban
ps: (and two Esteban’s counts exponentially :P)
pps: but there are also other problems to take into account, and that’s
also community culture. I know many people finds the amount of windows
opened somekind stressing when they arrive to our little world
 but it
actually fits a purpose and change it to other solutions just because
“everybody else does it” can probably do not work. A suitable solution for
LISP does not need to be a suitable solution to Pharo, just out of the box.
Which of course does not means I would not want to explore more efficient
workflows.
ppps: And of course, there is the effort that starting in other direction
goes
 even copying an existing IDE workflow would be a lot of work for us,
so sometimes is better just to incrementally enhance, even if that means we
will keep some metaphors during more time than desired.
pppps: as I always say in this list, human-computer interaction is not an
easy field and is very studied, so is not easily solvable with our always
subjective opinion. In that sense, I completely share the feeling that we
need to keep studying and experimenting with other communities experiences
until we find something that we can reengineer into something we need/want.
ppppps: I ran out of “ps”, but I couldn’t resist to put five “p" in a
line :)
Esteban A. Maringolo

[Ben Coman]

Post by Avdi Grimm
I dunno if this is useful to anyone, but I was rolling around concepts in
[image: Inline image 1]
This takes some cues from modern IDEs, but it also differs in that it
doesn't make the assumption that you want to see just one "buffer" at a
time, and that "split window mode" isn't sufficiently powerful to handle
the need for lots of windows open on lots of little methods.

Interesting idea. It might be better to use a breadcrumb rather than the
three pulldowns and I think Playground tends to need more room.

One idea I've contemplated, since often my many open windows result from
following some path investigating senders/implementors of other
senders/implementors, is that it would be useful to have a tree structure
docked to the side that records that hierarchical path of investigation.
This would help in cases when I want to back up a few steps to investigate
another path but usually I've lost the needed window (so I just open
another one). This would also help when it came time to prune an
investigation, since windows often hang around longer than needed since its
hard to remember which windows below to which path of investigation.
Ideally you might collapse the middle items of a path.

cheers -ben

[Avdi Grimm]

Post by Ben Coman
Interesting idea. It might be better to use a breadcrumb rather than the
three pulldowns and I think Playground tends to need more room.

Yeah I'm actually not so sure about having that part be interactive at all.
The whole concept of the scrolling list of views is to embrace workflows
where you open new windows rather than re-using old ones. So it might be
better to have that area just be an indicator of what that view is looking
at, rather than a way to re-focus it.

--
Avdi Grimm
http://avdi.org

[Esteban A. Maringolo]

Esteban A. Maringolo

Post by Ben Coman

Post by Avdi Grimm
I dunno if this is useful to anyone, but I was rolling around concepts in
[image: Inline image 1]
This takes some cues from modern IDEs, but it also differs in that it
doesn't make the assumption that you want to see just one "buffer" at a
time, and that "split window mode" isn't sufficiently powerful to handle
the need for lots of windows open on lots of little methods.

Interesting idea. It might be better to use a breadcrumb rather than the
three pulldowns and I think Playground tends to need more room.
One idea I've contemplated, since often my many open windows result from
following some path investigating senders/implementors of other
senders/implementors, is that it would be useful to have a tree structure
docked to the side that records that hierarchical path of investigation.
This would help in cases when I want to back up a few steps to investigate
another path but usually I've lost the needed window (so I just open
another one). This would also help when it came time to prune an
investigation, since windows often hang around longer than needed since its
hard to remember which windows below to which path of investigation.
Ideally you might collapse the middle items of a path.

That is exactly what Dolphin Smalltalk X6 has implemented a decade ago.
Once you start looking for senders/implementors the "method explorer" let
you navigate through them in a single window, filtering by hierarchy too.


[image: Imágenes integradas 2]


It also provides you with a ready to select list of selectors in the
selected method. E.g.:
[image: Imágenes integradas 3]


Regarding a tab based environment, Dolphin X6 also included that in a
concept called "Idea Space", you can open as many idea spaces as you want,
and as you browse classes, inspect objects or look for references, all the
usual new windows will open inside the idea space where the command was
issued. There also was the option to save the open tabs, to restore them
later. And you could move between tabs using only the keyboard; in fact you
could do everything without a mouse.

[image: Imágenes integradas 4]

If you look at the screenshots you'll see a white text input in the
toolbars, it was like a quicksilver/spotter like input, you could search
for classes and methods as you type with a blazing UI speed.

Smalltalk used to be ahead of the mainstream, we cannot afford to have
other smalltalks to be ahead of the time of Smalltalk itself. I'm not
advocating the use of Dolphin over Pharo, but I think we don't even have to
look outside our Smalltalk world to find better implementations of the same
paradigm tools (browsers/implementors/inspectors).

Regards!


Esteban A. Maringolo

ps: The product documentation explains some of these tools (
http://www.object-arts.com/downloads/docs/index.html), however if you have
a Windows environment you can try it for yourself.

[Avdi Grimm]

Post by Esteban A. Maringolo
Regarding a tab based environment, Dolphin X6 also included that in a
concept called "Idea Space", you can open as many idea spaces as you want,
and as you browse classes, inspect objects or look for references, all the
usual new windows will open inside the idea space where the command was
issued. There also was the option to save the open tabs, to restore them
later. And you could move between tabs using only the keyboard; in fact you
could do everything without a mouse.

For the record, I find tabs to be almost as much of a UI dead-end as myriad
windows. They are often incompatible with the need to see several things at
once, and they become unmanageable past a dozen or so.

Personally I prefer environments where the number of windows/tabs/buffers
is a non-issue, something managed by the environment. All I care about is:

a) Navigating back and forth between the thing I'm looking at now and the
last ~10 things I looked at; and
b) Quickly finding and foregrounding new things by whatever searchable
aspect I can remember about them.

I don't want to think or care about how many old things I once looked at
the environment keeps open; it is welcome to manage that on its own.

Incidentally, this is exactly what it's like to use RubyMine with tabs
turned off. I can navigate backwards and forwards through history, and I
can find things by name, and it worries about how many buffers to keep open
in the background. If I go "back" to a buffer it has closed, it re-opens it.

This is complemented by the fact that it auto-saves. Having high-quality
"Undo" is far more important than manually controlling when things are
saved, in my experience. In the RubyMine case, it is able to visually show
and undo every change that has been made since the last Git commit.

--
Avdi Grimm
http://avdi.org

[Ben Coman]

On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo <

Post by Esteban A. Maringolo
Regarding a tab based environment, Dolphin X6 also included that in a
concept called "Idea Space", you can open as many idea spaces as you want,
and as you browse classes, inspect objects or look for references, all the
usual new windows will open inside the idea space where the command was
issued. There also was the option to save the open tabs, to restore them
later. And you could move between tabs using only the keyboard; in fact you
could do everything without a mouse.

For the record, I find tabs to be almost as much of a UI dead-end as
myriad windows. They are often incompatible with the need to see several
things at once, and they become unmanageable past a dozen or so.
Personally I prefer environments where the number of windows/tabs/buffers
a) Navigating back and forth between the thing I'm looking at now and the
last ~10 things I looked at; and
b) Quickly finding and foregrounding new things by whatever searchable
aspect I can remember about them.

GTSpotter has a "history" category (not that I've used it so far, perhaps
time to try).

It might be an interesting experiment for GTSpotter to have an "open
window" category.

cheers -ben

[Andrei Chis]

Post by Ben Coman

On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo <

Post by Esteban A. Maringolo
Regarding a tab based environment, Dolphin X6 also included that in a
concept called "Idea Space", you can open as many idea spaces as you want,
and as you browse classes, inspect objects or look for references, all the
usual new windows will open inside the idea space where the command was
issued. There also was the option to save the open tabs, to restore them
later. And you could move between tabs using only the keyboard; in fact you
could do everything without a mouse.

For the record, I find tabs to be almost as much of a UI dead-end as
myriad windows. They are often incompatible with the need to see several
things at once, and they become unmanageable past a dozen or so.
Personally I prefer environments where the number of windows/tabs/buffers
a) Navigating back and forth between the thing I'm looking at now and the
last ~10 things I looked at; and
b) Quickly finding and foregrounding new things by whatever searchable
aspect I can remember about them.

GTSpotter has a "history" category (not that I've used it so far, perhaps
time to try).
It might be an interesting experiment for GTSpotter to have an "open
window" category.

Interesting idea.
Could be easily done :)

Cheers,
Andrei

Post by Ben Coman
cheers -ben

[Offray Vladimir Luna Cárdenas]

Hi,

Comments below.

I dunno if this is useful to anyone, but I was rolling around concepts in my
Inline image 1
This takes some cues from modern IDEs, but it also differs in that it
doesn't make the assumption that you want to see just one "buffer" at a
time, and that "split window mode" isn't sufficiently powerful to handle the
need for lots of windows open on lots of little methods.
Interesting idea. It might be better to use a breadcrumb rather than the three
pulldowns and I think Playground tends to need more room.
One idea I've contemplated, since often my many open windows result from
following some path investigating senders/implementors of other
senders/implementors, is that it would be useful to have a tree structure docked
to the side that records that hierarchical path of investigation. This would
help in cases when I want to back up a few steps to investigate another path but
usually I've lost the needed window (so I just open another one). This would
also help when it came time to prune an investigation, since windows often hang
around longer than needed since its hard to remember which windows below to
which path of investigation. Ideally you might collapse the middle items of a path.
cheers -ben

Attached is an screenshot[*] of my mockup for a tree-like explorative
computing, which I think is in the same lines of Ben's "tree structure
docked to the side that records that hierarchical path of
investigation". It's wrote on Smalltalk itself and modelled as a
document expressed like a tree, which can contain nested nodes of code
playgrounds and documentation wrote light markup language (markdown).
Its an attempt to make concrete the ideas in an old blog post[1] and I
don't know how well is suited for programmers/coders (I'm not one
myself), but is more about people which writes and interchanges code
with prose (which is my case).

[1]
http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexity-of-ipython-documents.html

I remember finding Smalltalk in 2005 and having difficulties to be
comfortable there, kind of a bittersweet sensation (still there today
but in less proportion). On one hand is was a concretion of older ideas
of mine about what computation could be (maleable and cognitive
empowering), but on the other it was so difficult to connect with my
previous experiences with documentation and scripting: The browser
hierarchy and "the everything is an object" imposed to much
order/paradigm for me. 10 years later, after Pharo, Moose, Leo[2],
IPython[3] and others, I'm finding my place again, trying to mix the
emergent nature of the tree/document/script with the more structured
browser and class and object paradigm.

[2] http://leoeditor.com/
[3] http://ipython.org/

If user interface is about experience, we could try to search in sharing
our own experiences and mockups what Pharo could be for growing and
diverse number of people, even going beyond programmers as a key about
this future experience we would like to have.

Cheers,

Offray

[*] In the screenshot you see the tree and 10 open windows, but mostly I
go from playgrounds to the document tree to the class browser,
switching/cycling tree windows to most of my experience.

[Craig Johnson]

It took thousands of programmers decades of work in many different languages
to create this variety. I'd hate to see the smaller Pharo community pour
tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been solved
many times over. Do you really want to do it yet again? I suspect that with
some careful examination of Pharo coding workflows, you could find a way to
obviate the need for zillions of windows, and solve a simpler problem
instead.

Some ramblings:
1. I quite like the way the alt-browser allows you to navigate through
your code by clicking on
methods and classes in a tree to see the code in the right-hand
pane. Take that one step further by
having the browser open a tab for each method that you click on, or
switch to the tab -
if there is one open already, and you will have taken a giant step
towards most modern
IDEs[1].

2. One way to solve the alt-tab issue is to use the OS 's window
manager, instead of managing the
windows in the image. This also has the added benefit of
incorporating the OS window manager's
features and look and feel into Pharo for free. The ability to
drag a tab out of the image window
onto it's own display in a multi-headed setup would be very welcome
to me.

Craig

1. My reference points here are M/S Visual Studio which I use daily and
Netbeans which I use for
mobile(Andriod) work.

[Dimitris Chloupis]

The shortcut based interface has been tried and has failed. It works well
for medium size complexity but to rely the whole functionality of a very
complex application to shortcuts is not anything shorter than insane. So
shortcuts are without any doubt useful and should be used by all apps but
they can go so far.

Add to that the emacs shortctus are mess , a huge mess. Many of them make
zero logical sense with some really weird keyboard combinations. Emacs has
not solve the problem of UI it has made severely worse and the same story
goes for Vim. Both projects rely on the obsession of coders with relying on
command line interfaces. Command line are of course much simpler to
customise and produce but design wise they come with some inherit weakness.

The thought that I need to search for a buffer, setup buffer groups ,
create tabs , use a weird complex shortcut etc when I just can use my mouse
and in one second click the window I want is a no brainer for me. Its not
just simple , its better.

Bare in mind, I come from Emacs, actually it was Emacs people (at #emacs in
irc) that introduced me to squeak and then to pharo. Without emacs I would
not be here . I still use #emacs to edit files because is such a great
editor. I love emacs . But a good UI ? Nope, definitely not in my book.
Actually Emacs for me is proof why text based UIs will never be able to
compete with GUIs because emacs is one of the best and still very difficult
to use.

Do I want some of the emacs buffer management tools in Pharo ? Sure
Will they improve the workflow ? Absolutely
Will they solve the problem ? Nope

I think Spotter can play a very good role in the management of windows to
implement functionality similar to Emacs. But no I wont trade the Pharo
mess for the Emacs mess not even in a 1 million years. I was raised with
text based interfaces and command lines since 1988 and I always had and
will forever hate them.

For me at least the future is AI GUIs , GUIs that watch user actions ,
understand his habbits and automate the workflow with minimum amount of
manual customization. There was a tool once promoted here that watched the
usage of windows and the ones least used were closed which I think is a
step towards the right direction but its definitely a very long road ahead.

Post by Avdi Grimm

Post by Dimitris Chloupis
About general GUI and UI designs its not any less nightmarish to open
multiple windows in Pharo than it is to open multiple buffers in emacs. The
diffirence between the two is that with emacs you have the nightmare of
lack of any GUI while in pharo you have the lack of sophisticated editing.

With respect, this is manifestly untrue. Buffer management is a solved
problem in Emacs. In fact, it's been solved and re-solved many times over,
* To simply toggle between the last few buffers
* To list, sort, and filter buffers quickly until you find the one you want
* To do fuzzy-completed searches on buffers
* To manage buffers in tabs and tab groups
* To have sidebars listing open buffers
* To kill or operate on many buffers at once based on what project they
are in or some other criteria
* To have a fully window-managed interface that can save, reload, and
switch between different window configurations for different contexts at a
keypress
* To forget about buffers completely, and just navigate to the thing you
want to see (and let Emacs worry about what buffers happen to be in memory)
(And lest anyone say that buffer management is a different problem from
window management, remember that Emacs is an application environment, and
that a "buffer" may be a full application window, such as an IRC channel or
even a Smalltalk-style browser.)
Whether you want any of these features or many others, there are mature
and well-tests solutions for all of them. Whereas as many longtime users
have confirmed in this thread, Smalltalk environments don't even have the
window management to match the Emacs built-in features, let alone the
mature extension ecosystem.
I made my original seven-minute Pharo video with the intent of getting
traditionally IDE-averse Ruby programmers to realize some of the things
they are missing. It's way too easy to say "oh, no one else has solved
this any better". And as a result, a number of people said "wow, I usually
hate IDEs but I need to check this out". But this cuts both ways.

Post by Dimitris Chloupis
Pharo is doing some good work on this area but realistically , the
community is too small to solve such a huge problem even with pharo ease of
use.

This I agree with completely.
My favorite OS for programming is Linux. In linux, window management is a
problem that has been solved many times over. There are dozens of window
managers (hundreds, if you count inactive projects). There are high-tech
compositing window managers that can do MacOS-style Expose zoom-out for
quickly locating windows. There are WMs that rigidly control where windows
show up, based on a policy you decide. There are all kinds of different
aids for quickly listing and navigating between windows.
It took thousands of programmers decades of work in many different
languages to create this variety. I'd hate to see the smaller Pharo
community pour tons of effort into re-inventing these solutions.
Which is why I'm suggesting that it may be more helpful to re-frame the
problem. General purpose window management is a problem that has been
solved many times over. Do you really want to do it yet again? I suspect
that with some careful examination of Pharo coding workflows, you could
find a way to obviate the need for zillions of windows, and solve a simpler
problem instead.

[Avdi Grimm]

Post by Dimitris Chloupis
The shortcut based interface has been tried and has failed.
The thought that I need to search for a buffer, setup buffer groups ,
create tabs , use a weird complex shortcut etc when I just can use my mouse
and in one second click the window I want is a no brainer for me. Its not
just simple , its better.

You clearly have different tastes than mine, and that's fine. However, if
you're going to deal with that by saying that my experiences are invalid,
and compound it by talking about things you clearly haven't actually tried
(what does "create tabs" or "setup buffer groups" even mean?) I'm not going
to bother responding to you anymore.

[Dimitris Chloupis]

No reason to be offended.

I am merely stated my opinion on the subject , obviously personal taste
plays a role . I never said your experiences are invalid, I can assure you
if that was my intention you will be clearly reading it inside my text.
Afterall I was the one that recommended you in IRC to bring this discussion
about Alt+TAB in the mailing list to find a solution to your problem. I do
however disagree with the idea that emacs has a good interface and I am far
from the only one. Again we come down to personal opinion. But of course
you are welcome to disagree, I have no problem with that nor I am here to
convince people that my opinion is valid and their own is invalid.

I am familiar with some of the features you described as I already said , I
am an emacs users for quite some time now. Not an emacs power user , just a
guy that loves to use emacs from time to time. Because of the opinion I
have expressed, I try to keep as few windows or buffers open as possible.

The remark on shortcuts is not just ranting, I use Blender for 3d graphics
on daily basis and shortcuts have become a serious issue. The application
has grown so large that is unmaintainable to demand from user to memorise
1000 shortcuts so there is a very active discussion between Blender
developers how to deal with this problem. A recent addition was pie menus,
right click menus that use mouse gestures to navigate as quickly as a
shortcut but with no demand on memorization. Its not an easy problem to
solve by any means, so yes when you said that emacs has solved it, I have
to confess I wished that it was that easy for me . But I do value your
opinion and your experience even If I disagree.

Its important to have such discussion , if people say "emacs way of doing
things is great" then so be it. Let's copy these Emacs features right away,
I am all for it. Pharo is not just for me, but for all of us. I do also
want more people to use Pharo and find it more user friendly.

Post by Avdi Grimm

Post by Dimitris Chloupis
The shortcut based interface has been tried and has failed.
The thought that I need to search for a buffer, setup buffer groups ,
create tabs , use a weird complex shortcut etc when I just can use my mouse
and in one second click the window I want is a no brainer for me. Its not
just simple , its better.

You clearly have different tastes than mine, and that's fine. However, if
you're going to deal with that by saying that my experiences are invalid,
and compound it by talking about things you clearly haven't actually tried
(what does "create tabs" or "setup buffer groups" even mean?) I'm not going
to bother responding to you anymore.

[Ben Coman]

Post by Avdi Grimm

As a step in this direction, the Window Menu (small arrow in title
bar) item "Create window group" may provide part of the behaviour you are
looking for.

Interesting! How does one add more than one window to the group? Is there
more info on this somewhere?

I see kilon linked to a nice video, but I just wanted to add... one nice
enhancement for this would be to emulate behaviour of chrome where, while
still dragging, hovering over the tab area temporarily fits the window into
the group.
cheers -ben

[Cyril Ferlicot]

Oh, thank you for this one !
Maybe we could add a little paragraph about it on UPBE! That's really usefull

Post by Avdi Grimm

Post by j***@objektfabrik.de
I mostly work in other Smalltalk environments than Pharo, like VA
Smalltalk. It has native windows and so the ability to switch between
windows using alt-tab is there. I must admit that there is a certain
threshold in the number of open windows when this is not really helpful any
more. I tend to hit that number pretty fast in a typical Smalltalk
coding/debugging sessions.
Things have changed in Win 7, because there I can use the window manager
to close the windows right in the window switcher. That makes perfect sense
if you have 15 inspectors open, none of which shows current data or
instances any more. Or if one of them does, I can't decide which one ;-)
So sometimes I wish for features like "close all windows of this kind" to
kill all inspectors, for example.
What I want to say with this that I am not really using alt-tab to switch
between windows, but rather to kill a few to come down to a sensible number
it is its own windowing environment, so it should probably better not use
the O/S' key combination to switch its windows, right?

Sometimes problems like this are indicative of deeper usability issues.
Decades ago, it was just sort of assumed that the "right" way to deal with
windows was to have a dedicated window for every "thing" in your system. To
some degree, Mac OS, Wind95, and OS/2 all took this point of view. For
instance, every folder you double-clicked on would open up a new file
manager window, and this got to be such a mess that some OSes included
"secret" shortcuts for killing them all at once.
Then the web started to take off, and UX designers started rethinking the
whole paradigm. They started keeping things in the same window, but adding
back/forward buttons, and navigation histories, and sidebars, and address
bars, and tabs, and other affordances to make it easier to switch between
"things" without necessarily adding more windows.
These days, most IDEs and editors have followed suit. I can't think of a
single editor in common use among the programmers I know which encourages
multiple windows. Whether it's Vim, Emacs, Sublime, IntelliJ, while you
*can* open lots of windows if you really want to, they all focus on making
it easy to manage lots of buffers in a single window rather than encouraging
lots of windows.
Personally, I'm a fan of this trend. I'm much happier typing a few
characters to auto-complete the buffer I want to return to in Emacs, than I
am hunting around in an OS window list for it.
This is all a long-winded way of saying: just because this is currently a
problem, doesn't mean it's the *right* problem. It would be interesting to
see what a "fewer windows" approach to Smalltalk development might look
like.

This is an interesting UI area to explore. As a step in this direction, the
Window Menu (small arrow in title bar) item "Create window group" may
provide part of the behaviour you are looking for.
cheers -ben

[j***@objektfabrik.de]

Avdi,

I wrote a series of articles on th etopic back in 2009: you can find the
first article here:
https://joachimtuchel.wordpress.com/2009/07/02/whats-in-a-smalltalk-browser-anyway-part-1/

Back then, I tried to share my thoughts on what I think A Smalltalk IDE
should look like these days (well, those days ;-) ). I've seen some of
the ideas presented and taken further at ESUG/IWST talks over the years,
some of which I really liked, but - as far as I can tell - none of these
projects went anywhere. None of the commercial vendors made any attempts
to work on window clutter or streamlining their IDEs. Smalltalk Browsers
are still the same as they were in 1981, all that's been added is a
little bit of colourful button bars here and there and tabbing (most
implementations even managed to get that wrong).

I think the conclusion I came to was that a Smalltalk IDE has two main
tasks: navgating code and editing code
Actually three: debugging which adds some stuff on top of the other two.

I think we all can agree on that Smalltalk's editing facilities mostly
sucked for decades. The lame excuse was that real Smalltalkers write
methods of no more than 6 lines. Fortnunately, we seem to have accepted
that either the assumption about real Smalltalkers was wrong or that
even 6 lines of code are worth syntax highlighting, code completion and
all kinds of assistance for the developer.

I also think that navigating code is extremely important. The fact that
each browser comes with its own navigation area that takes up about 50
percent of the real estate of the browser, however, is just plain wrong.

We are missing clever navigation facilities in Smalltalk. I think the GT
Tools are a great start in improving things and they are much better
than anything we have had for 40 years now, but it is just a step on a
long stairway. Other Smalltalk implementations literally have nothing in
this area that wasn't there in the 80ies.

On the other hand, what Smalltalk has offered for code navigation and
retrieval in the 80ies, was about 25-30 years ahead of the mainstream.
So I am not saying Smalltalk's environment is bad per se. It could just
be a lot better if more research or experimentation was done in the
area. The GT tools show that it is worth it and can boost Smalltalk
developers' productivity a lot.

Joachim

Post by j***@objektfabrik.de
I mostly work in other Smalltalk environments than Pharo, like VA
Smalltalk. It has native windows and so the ability to switch
between windows using alt-tab is there. I must admit that there is
a certain threshold in the number of open windows when this is not
really helpful any more. I tend to hit that number pretty fast in
a typical Smalltalk coding/debugging sessions.
Things have changed in Win 7, because there I can use the window
manager to close the windows right in the window switcher. That
makes perfect sense if you have 15 inspectors open, none of which
shows current data or instances any more. Or if one of them does,
I can't decide which one ;-)
So sometimes I wish for features like "close all windows of this
kind" to kill all inspectors, for example.
What I want to say with this that I am not really using alt-tab to
switch between windows, but rather to kill a few to come down to a
sensible number ;-) But I understand why you miss it. For Pharo,
there is a special problem: it is its own windowing environment,
so it should probably better not use the O/S' key combination to
switch its windows, right?
Sometimes problems like this are indicative of deeper usability
issues. Decades ago, it was just sort of assumed that the "right" way
to deal with windows was to have a dedicated window for every "thing"
in your system. To some degree, Mac OS, Wind95, and OS/2 all took this
point of view. For instance, every folder you double-clicked on would
open up a new file manager window, and this got to be such a mess that
some OSes included "secret" shortcuts for killing them all at once.
Then the web started to take off, and UX designers started rethinking
the whole paradigm. They started keeping things in the same window,
but adding back/forward buttons, and navigation histories, and
sidebars, and address bars, and tabs, and other affordances to make it
easier to switch between "things" without necessarily adding more windows.
These days, most IDEs and editors have followed suit. I can't think of
a single editor in common use among the programmers I know which
encourages multiple windows. Whether it's Vim, Emacs, Sublime,
IntelliJ, while you *can* open lots of windows if you really want to,
they all focus on making it easy to manage lots of buffers in a single
window rather than encouraging lots of windows.
Personally, I'm a fan of this trend. I'm much happier typing a few
characters to auto-complete the buffer I want to return to in Emacs,
than I am hunting around in an OS window list for it.
This is all a long-winded way of saying: just because this is
currently a problem, doesn't mean it's the *right* problem. It would
be interesting to see what a "fewer windows" approach to Smalltalk
development might look like.
--
Avdi Grimm
http://avdi.org

[Avdi Grimm]

The fact that each browser comes with its own navigation area that takes
up about 50 percent of the real estate of the browser, however, is just
plain wrong.

I was just thinking about this the other day. I don't think there's
anything fundamentally wrong with the four-pane approach (although there
are other perfectly valid approaches as well). But once you've found what
you're looking for, the panes take up *way* more screen space than is
necessary just to remind you where you are. It would be neat to see a
version where the panes fold away down to a "location" bar when you're not
actively navigating to a new method.

--
Avdi Grimm
http://avdi.org

[Stephan Eggermont]

Post by Avdi Grimm
Then the web started to take off,

throwing UI design back two decades ;),

Post by Avdi Grimm
and UX designers started rethinking
the whole paradigm. They started keeping things in the same window, but
adding back/forward buttons, and navigation histories, and sidebars, and
address bars, and tabs, and other affordances to make it easier to
switch between "things" without necessarily adding more windows.

We found that what works well for browsing and reading text not
necessarily works for code. I regularly have 80 tabs open in 10 windows
of more or less interesting stuff to read. Having a lot of edited
buffers open at the same time is a problem, if only because "save all"
might run into dependency issues. The current design stimulates working
in short cycles, and keeping code well-organized. I'd like not to lose
that aspect of the UI. And I also like a navigation history.

Post by Avdi Grimm
These days, most IDEs and editors have followed suit. I can't think of a
single editor in common use among the programmers I know which
encourages multiple windows.

Which seems like a mistake, as displays keep growing in size and the
IDEs and editors in common use have no way to use the space a 4K display
offers.

Post by Avdi Grimm
Whether it's Vim, Emacs, Sublime, IntelliJ,
while you *can* open lots of windows if you really want to, they all
focus on making it easy to manage lots of buffers in a single window
rather than encouraging lots of windows.

That actually sounds like a really bad idea when you have a large
display. I want to see all relevant code at the same time. Switching is
slow.

Post by Avdi Grimm
Personally, I'm a fan of this trend. I'm much happier typing a few
characters to auto-complete the buffer I want to return to in Emacs,
than I am hunting around in an OS window list for it.

I would welcome an auto-complete based navigation to one of my open
windows.

Post by Avdi Grimm
This is all a long-winded way of saying: just because this is currently
a problem, doesn't mean it's the *right* problem. It would be
interesting to see what a "fewer windows" approach to Smalltalk
development might look like.

A simple first step is Hopscotch.

On a small-screen device like an iPad I like the approach taken by
Cel: http://cel.inf.usi.ch/
And have you seen Gaucho?
http://www.inf.usi.ch/faculty/lanza/Downloads/Oliv2013a.pdf
Stephan

[Sebastian Heidbrink]

See,

this is why I love Smalltalk....
Tell me a different environment where you can actually have such discussion.

To make this a little clearer.
Pharo and Squeak are solely open source. So one might say,.... well this
can be done/extended/changed in Eclipse, too.

How about VW and VAST?
Well, you can change the development environment and it's behavior
according to your needs, too.
Want a putton to print something out for development purpose? Just add
it :-D

Try this with Visual Studio and xCode on that level.

Avdi if you think the things you have seen so far are cool?! Well, that
is just the beginning and you actually can make your environment easily
even cooler,... once you have taken the first hurdles.

With GlamourToolKit, Pharo community is even bringing this to a more
abstract level and I love playing with it.

I wish I was deeper into Pharo already.
Isn't there somebody who could just hack a small .st file to file-in the
desired behavior that Avdi is looking for?
A temporary hack?

Cheers!
Sebastian

Post by Laurent
Hi Avdi,
Welcome.
As the others mentioned, this part of Pharo is not at all ideal.
Please bare with us.
Cheers,
Doru
Hey folks! I've dabbled with smalltalk here and there over the
years, but recently I've settled in to learn Pharo in earnest. A
few of you might have seen the videos I've been putting up; they
seem to be making the rounds on Twitter. I just want to say I've
felt really welcomed by all the people who have commented with
helpful tips, or offered to help with my exploration :-)
I've run into my first big blocker as a newcomer. Like many
programmers I'm a fan of keeping my hands on the keyboard. Now,
I'm more flexible on this than some. I recognize that Pharo is a
visual environment, and it makes sense to explore it with a mouse.
And some interactions just make more sense with a mouse.
That said, no matter what windowing environment I'm in, I find the
ability to quickly cycle between windows without leaving the
keyboard pretty crucial. One Windows or Ubuntu I would normally do
this with Alt-Tab or Super-Tab. On MacOS it's Cmd-Tab.
I've been trying to figure out how to do this in Pharo. I've
looked for answers with Google, SO, and on IRC, and I've come up
blank. I'm starting to think it can't be done.
So, I've come here for your help. Is there a way to cycle between
windows? Or is anyone working on it? Or, perhaps, am I missing an
element of the Pharo programming workflow which renders it unneeded?
Many thanks,
--
Avdi
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"

[Joachim Tuchel]

We're in agreement here. It is nog about the panes per se. It's about the fact that once you reached an artefact to read or edit, there is no need for the navigation to cover a lot of space on screen. Multiplied by the number of open browsers. Until you commence your journey through your code.

Then there is the problem of navigation being much more than just packages and class hierarchies. There is the question of why and how did I get here? That area is uncovered in most IDEs - not only Smalltalk.

Another problem area is the longevity of a need to have some artefact open. How often do we close 10, 15, 20 inspectors at once, because we don't need them any more? When we look for the place where something started, we travel from implementor to implementor, via some senders until we finally get to where we can answer our question af hand. Sometimes we reach a dead end, need to go back a step or two and try another branch. But does it really mean we need each stop of the path as an open window? Forever? Or are there better ways to navigate?

I am getting so off-topic it hurts, but these questions need an answer, and the Smalltalk community should be one that can solve them much more easily than others because our language lets us concen

[Avdi Grimm]

I gotta say, I was *very* happy to see the Spotter in Pharo 4. This
approach, the grand unified auto-completing fuzzy find-by-anything box, is
one of the greatest programming UX advances in recent memory. There's a
reason there's now a version of it in every editor or IDE I know of.

That's not to say there's no place for a Browser approach. But what's
interesting to me is that I think the Spotter represents the 80% case. 80%
of the time, we have a good idea of what we're looking for and we just want
to get to it quickly. Browsers are more helpful for the 20% of the time
when we're new to the code and we're exploring.

Post by Joachim Tuchel
We're in agreement here. It is nog about the panes per se. It's about the
fact that once you reached an artefact to read or edit, there is no need
for the navigation to cover a lot of space on screen. Multiplied by the
number of open browsers. Until you commence your journey through your code.
Then there is the problem of navigation being much more than just packages
and class hierarchies. There is the question of why and how did I get here?
That area is uncovered in most IDEs - not only Smalltalk.
Another problem area is the longevity of a need to have some artefact
open. How often do we close 10, 15, 20 inspectors at once, because we don't
need them any more? When we look for the place where something started, we
travel from implementor to implementor, via some senders until we finally
get to where we can answer our question af hand. Sometimes we reach a dead
end, need to go back a step or two and try another branch. But does it
really mean we need each stop of the path as an open window? Forever? Or
are there better ways to navigate?
I am getting so off-topic it hurts, but these questions need an answer,
and the Smalltalk community should be one that can solve them much more
easily than others because our language lets us concentrate on the problem.
Joachim

[Sean P. DeNigris]

Post by Joachim Tuchel
once you reached an artefact to read or edit, there is no need for the
navigation to cover a lot of space on screen. Multiplied by the number of
open browsers

It's Morphic - pull up the halos and drag the source pane out ;)

p.s. kidding... but not. Although it's not exactly that simple because a)
you'll have to click a few extra times because the frontmost Morphs are not
locked, and b) the MultipleMethodsEditor will initially fill the world
because it is #spaceFill, but that could probably be addressed without too
much effort. We always complain about Morphic, but forget how much power is
hiding behind our GUI



-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Alt-tab-between-windows-tp4826593p4827312.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Torsten Bergmann]

Post by Avdi Grimm
I dunno if this is useful to anyone, but I was rolling around concepts in
...

Reminds me a lot onto the old Whsiker browser we had back in the days in
Squeak Smalltalk:

http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Packages/Tools/Whisker/

Havent done much with Squeak after we forked into Pharo but it may be that it
is still running in a recent Squeak version out of the box. But one can try squeak.org
or ask on squeak-dev list.

Bye
T.