Smalltalk › Pharo › Pharo Smalltalk Users

Alt-tab between windows

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

57 messages Options

123

Esteban A. Maringolo

Re: Alt-tab between windows

2015-05-19 11:41 GMT-03:00 Avdi Grimm <[hidden email]>:

> 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

kilon.alios

Re: Alt-tab between windows

In reply to this post by Avdi Grimm

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.

On Tue, May 19, 2015 at 5:42 PM Avdi Grimm <[hidden email]> wrote:

On Tue, May 19, 2015 at 3:53 AM, Dimitris Chloupis <[hidden email]> wrote:

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.

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

Re: Alt-tab between windows

On Tue, May 19, 2015 at 11:14 AM, Dimitris Chloupis <[hidden email]> wrote:

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.

kilon.alios

Re: Alt-tab between windows

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.

On Tue, May 19, 2015 at 6:28 PM, Avdi Grimm <[hidden email]> wrote:

On Tue, May 19, 2015 at 11:14 AM, Dimitris Chloupis <[hidden email]> wrote:
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

Re: Alt-tab between windows

In reply to this post by Ben Coman

On Tue, May 19, 2015 at 10:51 PM, Ben Coman <[hidden email]> wrote:

On Sat, May 16, 2015 at 5:35 PM, Esteban Lorenzano <[hidden email]> wrote:
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 :)

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.

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

^ KMKeymap

shortcut: $] command

action: [ World taskList selectNextTask. ]

TaskListGlobalShortcut>>selectPreviousTask

^ 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

EstebanLM

Re: Alt-tab between windows

In reply to this post by Esteban A. Maringolo

> On 19 May 2015, at 16:51, Esteban A. Maringolo <[hidden email]> wrote:
>
> 2015-05-19 11:41 GMT-03:00 Avdi Grimm <[hidden email]>:
>> 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
>

EstebanLM

Re: Alt-tab between windows

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

On 19 May 2015, at 19:11, Esteban Lorenzano <[hidden email]> wrote:

On 19 May 2015, at 16:51, Esteban A. Maringolo <[hidden email]> wrote:

2015-05-19 11:41 GMT-03:00 Avdi Grimm <[hidden email]>:
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

Re: Alt-tab between windows

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:

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

On Tue, May 19, 2015 at 1:40 PM, Esteban Lorenzano <[hidden email]> wrote:

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

On 19 May 2015, at 19:11, Esteban Lorenzano <[hidden email]> wrote:

On 19 May 2015, at 16:51, Esteban A. Maringolo <[hidden email]> wrote:

2015-05-19 11:41 GMT-03:00 Avdi Grimm <[hidden email]>:
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

Re: Alt-tab between windows

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

On Tue, May 19, 2015 at 3:04 PM, Avdi Grimm <[hidden email]> wrote:

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:

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

On Tue, May 19, 2015 at 1:40 PM, Esteban Lorenzano <[hidden email]> wrote:
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

On 19 May 2015, at 19:11, Esteban Lorenzano <[hidden email]> wrote:

On 19 May 2015, at 16:51, Esteban A. Maringolo <[hidden email]> wrote:

2015-05-19 11:41 GMT-03:00 Avdi Grimm <[hidden email]>:
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

Adventurer

Re: Alt-tab between windows

In reply to this post by Esteban A. Maringolo

> 2015-05-19 11:41 GMT-03:00 Avdi Grimm <[hidden email]>:
>> 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.

Ben Coman

Re: Alt-tab between windows

In reply to this post by Avdi Grimm

On Wed, May 20, 2015 at 3:04 AM, Avdi Grimm <[hidden email]> wrote:

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:

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

Re: Alt-tab between windows

On Wed, May 20, 2015 at 8:03 AM, Ben Coman <[hidden email]> wrote:

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

Re: Alt-tab between windows

In reply to this post by Ben Coman

Esteban A. Maringolo

2015-05-20 9:03 GMT-03:00 Ben Coman <[hidden email]>:

On Wed, May 20, 2015 at 3:04 AM, Avdi Grimm <[hidden email]> wrote:
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:

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.

It also provides you with a ready to select list of selectors in the selected method. E.g.:

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.

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

Re: Alt-tab between windows

On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo <[hidden email]> wrote:

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

Re: Alt-tab between windows

On Wed, May 20, 2015 at 11:04 PM, Avdi Grimm <[hidden email]> wrote:

On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo <[hidden email]> wrote:

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.

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

Re: Alt-tab between windows

On Wed, May 20, 2015 at 5:13 PM, Ben Coman <[hidden email]> wrote:

On Wed, May 20, 2015 at 11:04 PM, Avdi Grimm <[hidden email]> wrote:

On Wed, May 20, 2015 at 10:19 AM, Esteban A. Maringolo <[hidden email]> wrote:

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.

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

cheers -ben

Offray

Re: Alt-tab between windows

In reply to this post by Ben Coman

Hi,

Comments below.

El 20/05/15 a las 07:03, Ben Coman escribió:

>
>
> On Wed, May 20, 2015 at 3:04 AM, Avdi Grimm <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> 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:
>
> 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.

notebook.png (233K) Download Attachment

123