December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Old inspector and explorer

by Ben Coman

On Fri, Dec 26, 2014 at 8:18 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > What I cannot quite grasp is that while we pride ourselves with working on > a reflective language, when we have reflective tools, we seem to not be > able to take half an hour to build the tool that fits our needs. I am > still wondering what is needed to improve this. I think that it's a problem > of exercise or of communication, but it seems that just providing the > examples that I linked before is not enough and most people look at the > inspector still as a black box tool. > I am guilty :) I try now to think why this is and the word that seems most appropriate is "inertia". By that I mean, at times previous I think you've published some tutorials, but I've had too many things on my plate to check it out - then when it comes to needing something, it takes time to find the tutorial, so I push on working aroud it. Poor habit maybe.... but there you go :) Alternatively, sometimes I've done a tutorial a long time before I have an actual need for it, and by the time I need to use it, I've forgotten and can't find the reference. The best time for a tutorial is when you need to use it. I wonder if there could be a button that linked to a ProfStef type tutorial that described how to customise it. Perhaps a help button that flashes once in a new image - just to draw the eye to investigate it. Then at the time I want/need to do it, its there in the image, with the least friction to learning what I need to know at the time I need to do it. Now sorry I'm on a new computer for the xmas season and I'm having a problem getting PharoLauncher up an running** to check what I've said against what is currently shown on the tool. cheers -ben **see other thread. I will try to work on a tutorial to see if it gets better, but do you find > the moldability proposition not valuable or just unclear? > > >

Dec. 26, 2014

Re: [Pharo-dev] [Ann] a short Bloc demo

by Alain Plantec

> > Why does it open another window? (see screenshot, the left pharo windows opens after switching > to bloc world. Only the right window acts to mouse and keyboard (cmd+enter). The left window > looks like a "mirror", just shows what happens in the right window. ah, Iâve never tested it in windows. It should not open another window. Maybe itâs because of OSWindow that is used for the vm rendering. I will have a look. maybe have to not use OSWindow. Thanks Alain > > > > > > >> On 25 Dec 2014, at 20:57, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> I tried both, loadDevelopment and loadBleedingEdget, but >> I can not get it to work like in the video. >> For me, the keyboard input stop working as soon as I start the bloc world. >> And for me it opens another window in the background, what is it for? >> >> BTW how many developers working on bloc, just you two ? >> >> nicolai >> >> >> >> 2014-12-25 10:31 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >> >> Le 25/12/14 03:04, Ben Coman a Ã©crit : >> Really nice to see your progress. Now do you have some sketches that show how it relates to the components of the existing Morphic? What is being disposed of, what reimplemented, what ported? >> >> I'm writing class comments and soon a chapter. But it takes time because I have to also do a bit of reverse engineering. >> Now Bloc does not relate to Morphic :) Everything is rewritten from scratch and we will rewrite everything. >> We will try to reuse Spec. >> Now for default Morphic, rewritting all the morphs to use Athens >> is a huge tasks considered the current logic of certain morphic elements >> Since Bloc is fully athens-based, it may be better to only work on Bloc. >> Now the trick is that we can use the morphic elements. >> This would really help to understand where contributions might be useful. >> >> >> btw, with Build 40419, "ConfigurationOfBloc load" warns that >> it depends on BlEllipseShape which must be resolved before #drawOn: and #drawOnAthensCanvas: can be resolved. >> >> Yes this is normal, you should load bleedingEdge. >> >> >> "ConfigurationOfBlock loadDevelopment" works fine. >> >> cheer -ben >> >> Sven Van Caekenberghe wrote: >> Yes, a nice X-Mas present ! >> >> On 24 Dec 2014, at 15:41, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> Wow! Impressive!!! >> >> Alexandre >> >> >> On Dec 24, 2014, at 3:19 PM, Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>> wrote: >> >> Hello all, >> >> Iâve just uploaded a small demo of Bloc. >> http://vimeo.com/115336678 <http://vimeo.com/115336678> >> >> >> Cheers >> Alain >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > <pharo_bloc.png>

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Norbert Hartl

Doru, > Am 26.12.2014 um 14:38 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Norbert, > > My reply is inlined. > dito > On Wed, Dec 24, 2014 at 5:15 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >> Am 23.12.2014 um 22:46 schrieb Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >> >> The Raw view is a tree :) >> > It looks like shallow tree :) Maybe I miss the point but my appearance to this is something like that. Let's have a class > > Object subclass: #TTT > instanceVariableNames: 'col' > classVariableNames: '' > category: 'ZZZ' > > and > > TTT>>#initialize > col := OrderedCollection new addAll: (1 to: 10); yourself > > If I inspect "TTT new" I get > > > > With the intention to examine the elements of the collection I unfold (1) the col > > > > So instead of the elements I get the internal representation of OrderedCollection. Clicking array (2) > > > > I get a new column with the representation of array (same as on the left side). And here Clement is right because it would be helpful to see the elements in the right column. By clicking the "10 items" tab (3) and then an element (4) I can see the content of that. > So what I wanted to say is that I found it a lot of clicks necessary to get the information I want. I see it is a raw view and from that POV everything seems right. > > The tree interface works only for a few elements in a collection, but it will fail for most real collections because it does not scale (you will have a hard time finding anything). > > Nevertheless, here is a simplistic solution (it will have to be extended a bit). Adding this method: > > Collection>>gtInspectorVariableValuePairs > | pairs | > pairs := super gtInspectorVariableValuePairs. > self doWithIndex: [ :each :index | > index > 42 ifTrue: [ ^ pairs ]. > pairs add: (index asTwoCharacterString -> each) ]. > ^ pairs > > <collection-items-in-raw.png> > > In my opinion this makes the Raw view less "Raw". > Sure. I didn't mean to change the raw view because taken its name it is perfectly doing what it promises. It's just that in most of the cases I'm not really interested in a raw view but customized views that help examine/navigating (which is the point of having gt inspector in the first place, right?). Thanks for the code snippet. I'll take that as an entry point to play with it. Would have taken me some time to get that. > > Coming from the old tools it is not a point of getting used to it or not. This raw view is not an improvement over the old it is a completely different view. > As Ben sad it might good to think about providing a view compatible with the old explorer view (fast drill down). Having that view be a default could be left to the user as it could be a setting. > Does that makes sense? > > Your comparison is correct: the current Raw view does provide less than the old one. However, the raw view used to be the inspector, but now it is but one of the views in the inspector and it was not meant to replace or improve the old one. The inspector as a whole does want to improve on the old one, and I think this is where we should focus our comparisons on :). Nevertheless, let me know what you think about the extension proposed above. > > But, here is the other thing that the new inspector allows for. In the TTT class you can now add something like: > > TTT>>gtInspectorItemsIn: composite > <gtInspectorPresentationOrder: 0> > composite list > title: 'Col'; > display: [ col ] > > This is about as cheap as a printOn: and you get: > > <inspector-custom-col.png> > That's really good. I'm sure I gonna love it soon. > You might say that you do not want to stop your inspection to do this, but actually you should not stop. You can write this method directly in the Meta tab and the inspector updates live and you can continue from where you left off with a tiny detour. > > Norbert > > P.S.: Are the miller columns configurable. I want to play with amount of columns. Until now I preferred three columns if space is available. Any pointers to that would be great. > > There are two things: > 1. There is a setting to set the default amount of panes. > 2. The columns are adjustable dynamically by resizing the scrollbar at the bottom. Ok, I'll try all of that and then I return to 4.0. Thanks for the help! Norbert

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Norbert Hartl

> Am 26.12.2014 um 14:04 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Norbert, > > I must be missing something obvious, but fail to see how you are forced to extend the inspector. I think the inspector in 4.0 comes out of the box with many more capabilities than the one in 3.0. > > Even if there were things to improve, and I will reply soon to the other mail with a concrete solution, there seems to be no real issue in your specific case given that you could without any problems describing how to get to the item number "3" of the collection (which seemed to be the problem in the first place). Am I missing something? > There are two kind of problems. One is if something is not working/possible. The other is if it is too cumbersome to achieve something. From user point of view both problems are really close if not equal. Probably I need to rephrase my first mail. I was opting for having an alternative view than the raw view which is more like the old inspector and making it possible to have it as a default. Norbert > > Cheers, > Doru > > > On Fri, Dec 26, 2014 at 1:40 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > Doru, > > I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. > To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. > > So I think the only possibility is to "offer" a new way of doing things and give people time to adjust. > > Norbert > >> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >> >> Hi, >> >> I think there must be a misunderstanding. >> >> There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. >> >> There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. >> >> What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? >> >> But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. >> >> Cheers, >> Doru >> >> >> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> I will add basicInspect in Object so that we can get access to the old inspector. >> I like that people can choose their tools! >> I mentioned that 20 times but people do not care apparently. >> >> Stef >> >> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >> >> Is there a way to get the old tools via shortcut? >> >> I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. >> To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. >> >> Norbert >> >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi Sven, I concur with this point of view. Cheers, Doru On Fri, Dec 26, 2014 at 2:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, we did not have this choice problem when the eye inspectors were > introduced. > > I am against going along two paths. > > GT's main goal is easy customisation, we (together) must find ways to make > this the best inspector possible, and that can only happen by actually > using it. > > Everyone who is not happy should continue to voice their opinion. The > discussion should be constructive and informed - which also means that > everyone should give the new tools a fair chance. > > And I fully agree with the 'emergency inspector' idea. > > > On 26 Dec 2014, at 13:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > I think there must be a misunderstanding. > > > > There can be a good reason for having a basic inspector around, but I > think the reason is not because people cannot choose what to use. > > > > There is a toggle to enable/disable the GTInspector. But, even without > it, the main feature of the GTInspector is exactly to be extended the way > people want and not impose a fixed way. This is completely different from > what existed before. In fact, half a year ago there was no problem that > people could neither choose nor extend anything. In the meantime, we can > extend our workflows significantly. Adding the various flavors of browsing > objects is perhaps a couple of lines long and each of us can tweak it > because there is no higher entity that should decide anymore. > > > > What I cannot quite grasp is that while we pride ourselves with working > on a reflective language, when we have reflective tools, we seem to not be > able to take half an hour to build the tool that fits our needs. I am > still wondering what is needed to improve this. I think that it's a problem > of exercise or of communication, but it seems that just providing the > examples that I linked before is not enough and most people look at the > inspector still as a black box tool. I will try to work on a tutorial to > see if it gets better, but do you find the moldability proposition not > valuable or just unclear? > > > > But, as I said, there can still be a valid reason to enable a basic > inspector that relies on a minimal of libraries (so, definitely not the > Spec one) for the same reason we have an emergency debugger. > > > > Cheers, > > Doru > > > > > > On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: > > I will add basicInspect in Object so that we can get access to the old > inspector. > > I like that people can choose their tools! > > I mentioned that 20 times but people do not care apparently. > > > > Stef > > > > Le 23/12/14 11:50, Norbert Hartl a Ã©crit : > > > > Is there a way to get the old tools via shortcut? > > > > I started something new with pharo 4.0 today. I discovered a bug in > Nautilus where every rename or deletion of a method raises a debugger. I > tried finding the bug but struggled because to me the new inspector is > really confusing. If I "just" want to unfold a few levels of references to > get a glimpse of the structure the new tool prevents me from doing that. > There is just to much information in this window and too much happening to > me. > > To me it looks like a power tool you need to get used to. So it is > probably not the best tool for simple tasks and people new to this > environment might be overwhelmed. At least I would like to be able to use > the old tools. > > > > Norbert > > > > > > > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi Norbert, My reply is inlined. On Wed, Dec 24, 2014 at 5:15 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.12.2014 um 22:46 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > The Raw view is a tree :) > > It looks like shallow tree :) Maybe I miss the point but my appearance to > this is something like that. Let's have a class > > Object subclass: #TTT > instanceVariableNames: 'col' > classVariableNames: '' > category: 'ZZZ' > > and > > TTT>>#initialize > col := OrderedCollection new addAll: (1 to: 10); yourself > > If I inspect "TTT new" I get > > > With the intention to examine the elements of the collection I unfold (1) > the col > > > So instead of the elements I get the internal representation of > OrderedCollection. Clicking array (2) > > > I get a new column with the representation of array (same as on the left > side). And here Clement is right because it would be helpful to see the > elements in the right column. By clicking the "10 items" tab (3) and then > an element (4) I can see the content of that. > So what I wanted to say is that I found it a lot of clicks necessary to > get the information I want. I see it is a raw view and from that POV > everything seems right. > The tree interface works only for a few elements in a collection, but it will fail for most real collections because it does not scale (you will have a hard time finding anything). Nevertheless, here is a simplistic solution (it will have to be extended a bit). Adding this method: Collection>>gtInspectorVariableValuePairs | pairs | pairs := super gtInspectorVariableValuePairs. self doWithIndex: [ :each :index | index > 42 ifTrue: [ ^ pairs ]. pairs add: (index asTwoCharacterString -> each) ]. ^ pairs [image: Inline image 1] In my opinion this makes the Raw view less "Raw". Coming from the old tools it is not a point of getting used to it or not. > This raw view is not an improvement over the old it is a completely > different view. > As Ben sad it might good to think about providing a view compatible with > the old explorer view (fast drill down). Having that view be a default > could be left to the user as it could be a setting. > Does that makes sense? > Your comparison is correct: the current Raw view does provide less than the old one. However, the raw view used to be the inspector, but now it is but one of the views in the inspector and it was not meant to replace or improve the old one. The inspector as a whole does want to improve on the old one, and I think this is where we should focus our comparisons on :). Nevertheless, let me know what you think about the extension proposed above. But, here is the other thing that the new inspector allows for. In the TTT class you can now add something like: TTT>>gtInspectorItemsIn: composite <gtInspectorPresentationOrder: 0> composite list title: 'Col'; display: [ col ] This is about as cheap as a printOn: and you get: [image: Inline image 2] You might say that you do not want to stop your inspection to do this, but actually you should not stop. You can write this method directly in the Meta tab and the inspector updates live and you can continue from where you left off with a tiny detour. Norbert > > P.S.: Are the miller columns configurable. I want to play with amount of > columns. Until now I preferred three columns if space is available. Any > pointers to that would be great. > There are two things: 1. There is a setting to set the default amount of panes. 2. The columns are adjustable dynamically by resizing the scrollbar at the bottom. Cheers, Doru

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Sven Van Caekenberghe

Yes, we did not have this choice problem when the eye inspectors were introduced. I am against going along two paths. GT's main goal is easy customisation, we (together) must find ways to make this the best inspector possible, and that can only happen by actually using it. Everyone who is not happy should continue to voice their opinion. The discussion should be constructive and informed - which also means that everyone should give the new tools a fair chance. And I fully agree with the 'emergency inspector' idea. > On 26 Dec 2014, at 13:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I think there must be a misunderstanding. > > There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. > > There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. > > What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? > > But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. > > Cheers, > Doru > > > On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: > I will add basicInspect in Object so that we can get access to the old inspector. > I like that people can choose their tools! > I mentioned that 20 times but people do not care apparently. > > Stef > > Le 23/12/14 11:50, Norbert Hartl a Ã©crit : > > Is there a way to get the old tools via shortcut? > > I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. > To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. > > Norbert > > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Sven Van Caekenberghe

> On 26 Dec 2014, at 14:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Norbert, > > I must be missing something obvious, but fail to see how you are forced to extend the inspector. I think the inspector in 4.0 comes out of the box with many more capabilities than the one in 3.0. > > Even if there were things to improve, and I will reply soon to the other mail with a concrete solution, there seems to be no real issue in your specific case given that you could without any problems describing how to get to the item number "3" of the collection (which seemed to be the problem in the first place). Am I missing something? In terms of the GT Inspector, the problem is that the raw view shows 'what is really there', but combines that with a tree to give the old explorer functionality. But the old explorer functionality uses an items view for collection sub elements. I am not sure how we can solve that in a principled way. > Cheers, > Doru > > > On Fri, Dec 26, 2014 at 1:40 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Doru, > > I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. > To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. > > So I think the only possibility is to "offer" a new way of doing things and give people time to adjust. > > Norbert > >> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >> >> I think there must be a misunderstanding. >> >> There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. >> >> There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. >> >> What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? >> >> But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. >> >> Cheers, >> Doru >> >> >> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: >> I will add basicInspect in Object so that we can get access to the old inspector. >> I like that people can choose their tools! >> I mentioned that 20 times but people do not care apparently. >> >> Stef >> >> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >> >> Is there a way to get the old tools via shortcut? >> >> I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. >> To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. >> >> Norbert >> >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi Norbert, I must be missing something obvious, but fail to see how you are forced to extend the inspector. I think the inspector in 4.0 comes out of the box with many more capabilities than the one in 3.0. Even if there were things to improve, and I will reply soon to the other mail with a concrete solution, there seems to be no real issue in your specific case given that you could without any problems describing how to get to the item number "3" of the collection (which seemed to be the problem in the first place). Am I missing something? Cheers, Doru On Fri, Dec 26, 2014 at 1:40 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Doru, > > I think your intention is a good one but slightly misplaced. I really like > the idea of GTInspector. It surely is a great tool and maybe I'll start to > build my own inspector on my kind of things. > To me the difference is between "motivated to do" or "forced to do". Most > of the time we are trying hard to solve our own problems. If in that > progress other problems are forced upon us we get easily distracted and > frustrated. The same goes for new tools. If I'm forced to use these it just > means I have to deal with it first and only then I'm allowed to deal with > my own problem. As it was in that special case the bug in nautilus and the > new inspector made me shy away from developing something in 4.0 and now I'm > back on 3.0. > > So I think the only possibility is to "offer" a new way of doing things > and give people time to adjust. > > Norbert > > Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > I think there must be a misunderstanding. > > There can be a good reason for having a basic inspector around, but I > think the reason is not because people cannot choose what to use. > > There is a toggle to enable/disable the GTInspector. But, even without it, > the main feature of the GTInspector is exactly to be extended the way > people want and not impose a fixed way. This is completely different from > what existed before. In fact, half a year ago there was no problem that > people could neither choose nor extend anything. In the meantime, we can > extend our workflows significantly. Adding the various flavors of browsing > objects is perhaps a couple of lines long and each of us can tweak it > because there is no higher entity that should decide anymore. > > What I cannot quite grasp is that while we pride ourselves with working on > a reflective language, when we have reflective tools, we seem to not be > able to take half an hour to build the tool that fits our needs. I am > still wondering what is needed to improve this. I think that it's a problem > of exercise or of communication, but it seems that just providing the > examples that I linked before is not enough and most people look at the > inspector still as a black box tool. I will try to work on a tutorial to > see if it gets better, but do you find the moldability proposition not > valuable or just unclear? > > But, as I said, there can still be a valid reason to enable a basic > inspector that relies on a minimal of libraries (so, definitely not the > Spec one) for the same reason we have an emergency debugger. > > Cheers, > Doru > > > On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: > >> I will add basicInspect in Object so that we can get access to the old >> inspector. >> I like that people can choose their tools! >> I mentioned that 20 times but people do not care apparently. >> >> Stef >> >> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >> >> Is there a way to get the old tools via shortcut? >>> >>> I started something new with pharo 4.0 today. I discovered a bug in >>> Nautilus where every rename or deletion of a method raises a debugger. I >>> tried finding the bug but struggled because to me the new inspector is >>> really confusing. If I "just" want to unfold a few levels of references to >>> get a glimpse of the structure the new tool prevents me from doing that. >>> There is just to much information in this window and too much happening to >>> me. >>> To me it looks like a power tool you need to get used to. So it is >>> probably not the best tool for simple tasks and people new to this >>> environment might be overwhelmed. At least I would like to be able to use >>> the old tools. >>> >>> Norbert >>> >>> >>> >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 26, 2014

Re: [Pharo-dev] Old inspector and explorer

by Norbert Hartl

Doru, I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. So I think the only possibility is to "offer" a new way of doing things and give people time to adjust. Norbert > Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > I think there must be a misunderstanding. > > There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. > > There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. > > What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? > > But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. > > Cheers, > Doru > > > On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > I will add basicInspect in Object so that we can get access to the old inspector. > I like that people can choose their tools! > I mentioned that 20 times but people do not care apparently. > > Stef > > Le 23/12/14 11:50, Norbert Hartl a Ã©crit : > > Is there a way to get the old tools via shortcut? > > I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. > To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. > > Norbert > > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Dec. 26, 2014