May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Alt-tab between windows

by Esteban A. Maringolo

Esteban A. Maringolo 2015-05-20 9:03 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > > On Wed, May 20, 2015 at 3:04 AM, Avdi Grimm <avdi(a)avdi.org> 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: >> >> [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.

May 20, 2015

Re: [Pharo-users] Alt-tab between windows

by Avdi Grimm

On Wed, May 20, 2015 at 8:03 AM, Ben Coman <btc(a)openinworld.com> 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

May 20, 2015

Re: [Pharo-users] Alt-tab between windows

by Ben Coman

On Wed, May 20, 2015 at 3:04 AM, Avdi Grimm <avdi(a)avdi.org> 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: > > [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

May 20, 2015

Alt-tab between windows

by Torsten Bergmann

>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: >... 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… 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.

May 20, 2015

Re: [Pharo-users] Smalltalkhub password reset

by mtk

Hi Esteban, I send you my username via email. Best Marcus -- View this message in context: http://forum.world.st/Smalltalkhub-password-reset-tp4827089p4827532.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 20, 2015

Re: [Pharo-users] Alt-tab between windows

by Craig Johnson

> 2015-05-19 11:41 GMT-03:00 Avdi Grimm <avdi(a)avdi.org>: >> 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.

May 19, 2015

Re: [Pharo-users] Spec - Columns Containing Rows Containing Columns

by Craig Johnson

and... it works. Thanks to all who replied. Putting the two columns into a RowLayout worked. Craig On 2015/05/19 07:41 PM, Nicolai Hess wrote: > I just saw there is are > SpecColumnLayout > SpecRowLayout > > classes. So you can use > > > defaultSpec > <spec: #default> > > ^SpecRowLayout composed > newColumn: [ :tcol | > tcol newRow:[:trow | trow add: #lblFolder ] height: 30. > ]; > > newColumn: [ :tcol | > tcol newRow:[:trow | > trow newColumn: [ :tcol2 | tcol2 add: #ddlfolder]; > newColumn: [ :tcol2 | tcol2 add: #txtFolder]. > ] height: 30. > ]. >

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by 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 On Tue, May 19, 2015 at 3:04 PM, Avdi Grimm <avdi(a)avdi.org> 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: > > [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 > > > On Tue, May 19, 2015 at 1:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > 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 <estebanlm(a)gmail.com> wrote: >> >> >> On 19 May 2015, at 16:51, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> 2015-05-19 11:41 GMT-03:00 Avdi Grimm <avdi(a)avdi.org>: >> >> 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 >> >> >> >

May 19, 2015

Re: [Pharo-users] Alt-tab between windows

by 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 On Tue, May 19, 2015 at 1:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> 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 <estebanlm(a)gmail.com> wrote: > > > On 19 May 2015, at 16:51, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > 2015-05-19 11:41 GMT-03:00 Avdi Grimm <avdi(a)avdi.org>: > > 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 > > >

May 19, 2015

Re: [Pharo-users] Spec - Columns Containing Rows Containing Columns

by Nicolai Hess

I just saw there is are SpecColumnLayout SpecRowLayout classes. So you can use defaultSpec <spec: #default> ^SpecRowLayout composed newColumn: [ :tcol | tcol newRow:[:trow | trow add: #lblFolder ] height: 30. ]; newColumn: [ :tcol | tcol newRow:[:trow | trow newColumn: [ :tcol2 | tcol2 add: #ddlfolder]; newColumn: [ :tcol2 | tcol2 add: #txtFolder]. ] height: 30. ]. 2015-05-19 19:35 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Indeed using a single top level container should be the best approach, > because "SpecLayout composed" doesn't have any layout - so adding multiple > items into it are just placed one over the other. > Arguably it might be better to add new methods "SpecLayout rows/SpecLayout > cols" or something like that so you have the base layout defined. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > view := DynamicComposableModel new. > models := #( > leftCol LabelModel > t11 LabelModel t12 LabelModel t13 LabelModel > t21 LabelModel t22 LabelModel t23 LabelModel > ). > view instantiateModels: models. > models pairsDo: [ :lbl :m | > (view perform: lbl asSymbol) label: lbl. > ]. > > layout := SpecLayout composed > newRow: [ :r | > r newColumn: [ :col | col add: #leftCol ]. > r newColumn: [ :col | > col > newRow: [ :row | > row > add: #t11; > add: #t12; > add: #t13 > ]; > newRow: [ :row | > row > add: #t21; > add: #t22; > add: #t23 > ] > ] > ]; > yourself. > view openWithSpecLayout: layout. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Peter > > > > On Tue, May 19, 2015 at 3:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-05-19 14:34 GMT+02:00 Craig Johnson <craig(a)hivemind.net>: >> >>> Hi, >>> >>> Spec has me tearing my hair out again. >>> >>> I'm using a composed layout with two columns in it. In the second >>> column I'd like to place some rows which in turn contain columns. >>> >>> There does not seem to be any way to do this. Everthing that I try only >>> renders one of the two main columns. >>> Guidance would be spreciated. >>> >> >> >> I don't know for sure, but I had a similar issue and solved it by using a >> single toplevel container >> (only one call newRow/newColumn after "SpecLayout composed") >> >> ^ SpecLayout composed >> newRow:[ :top | >> >> top >> newColumn: [ :tcol | >> tcol newRow:[:trow | trow add: #lblFolder ] height: 30. >> ]; >> >> newColumn: [ :tcol | >> tcol newRow:[:trow | >> trow newColumn: [ :tcol2 | tcol2 add: #ddlfolder]; >> newColumn: [ :tcol2 | tcol2 add: #txtFolder]. >> ] height: 30. >> ]. >> ] >> >> >> >>> >>> defaultSpec >>> <spec: #default> >>> >>> ^SpecLayout composed >>> newColumn: [ :tcol | >>> tcol newRow:[:trow | trow add: #lblFolder ] height: >>> 30. >>> ]; >>> >>> newColumn: [ :tcol | >>> tcol newRow:[:trow | >>> trow newColumn: [ :tcol2 | tcol2 add: >>> #ddlfolder]; >>> newColumn: [ :tcol2 | tcol2 add: >>> #txtFolder]. >>> ] height: 30. >>> ]. >>> >> >> >

May 19, 2015