Alt-tab between windows
Locked
123
123
 
|
Le 16/5/15 01:22, Avdi Grimm a écrit :
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 |
|
|
In reply to this 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 > > 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? be able to fix anything for now on this part. Now if people wants to help they are more then welcome. Stef |
|
|
In reply to this post by Avdi Grimm
Hi Avdi, Welcome. As the others mentioned, this part of Pharo is not at all ideal. Please bare with us. Cheers, Doru On Sat, May 16, 2015 at 12:52 AM, Avdi Grimm <[hidden email]> wrote:
|
|
|
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 Am 16.05.15 um 22:11 schrieb Tudor Girba:
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
Re: Alt-tab between windows
|
|
In reply to this post by Tudor Girba-2
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 On 2015-05-16 1:11 PM, Tudor Girba
wrote:
|
|
|
In reply to this post by jtuchel
On Sat, May 16, 2015 at 4:23 PM, [hidden email] <[hidden email]> wrote:
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. |
|
|
On Tue, May 19, 2015 at 7:08 AM, Avdi Grimm <[hidden email]> wrote:
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 |
|
|
In reply to this post by Avdi Grimm
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 Am 19.05.15 um 01:08 schrieb Avdi Grimm:
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
|
|
In reply to this post by Ben Coman
On Mon, May 18, 2015 at 11:06 PM, Ben Coman <[hidden email]> wrote: 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? |
|
|
In reply to this post by jtuchel
On Mon, May 18, 2015 at 11:41 PM, [hidden email] <[hidden email]> wrote: 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. |
|
|
In reply to this post by Avdi Grimm
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 |
|
|
In reply to this post by 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. On Tue, May 19, 2015 at 12:42 AM Joachim Tuchel <[hidden email]> wrote:
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. |
|
|
In reply to this post by Ben Coman
Oh, thank you for this one !
Maybe we could add a little paragraph about it on UPBE! That's really usefull On 19 May 2015 at 05:06, Ben Coman <[hidden email]> wrote: > > On Tue, May 19, 2015 at 7:08 AM, Avdi Grimm <[hidden email]> wrote: >> >> >> On Sat, May 16, 2015 at 4:23 PM, [hidden email] >> <[hidden email]> wrote: >>> >>> 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. >> > > 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 -- Cheers Cyril Ferlicot |
|
|
In reply to this post by Avdi Grimm
Le mar. 19 mai 2015 à 5:45, Avdi Grimm <[hidden email]> a écrit :
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 |
|
In reply to this post by Avdi Grimm
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. https://www.youtube.com/watch?v=GGJZeajjWGU On Tue, May 19, 2015 at 6:46 AM Avdi Grimm <[hidden email]> wrote:
|
|
Administrator
|
In reply to this post by jtuchel
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 |
|
|
In reply to this post by Avdi Grimm
On Tue, May 19, 2015 at 11:45 AM, Avdi Grimm <[hidden email]> wrote:
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 |
Re: Alt-tab between windows
|
|
In reply to this post by Avdi Grimm
On 19-05-15 01:08, Avdi Grimm wrote:
> Then the web started to take off, throwing UI design back two decades ;), > 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. > 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. > 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. > 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. > 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. https://youtu.be/d6tj6KQtD1s 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 |
|
|
In reply to this post by kilon.alios
On Tue, May 19, 2015 at 3:53 AM, Dimitris Chloupis <[hidden email]> wrote:
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.
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. |
|
|
In reply to this post by EstebanLM
On Sat, May 16, 2015 at 5:35 PM, Esteban Lorenzano <[hidden email]> wrote:
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 |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |