> On 26 Dec 2014, at 14:04, Tudor Girba <[email protected]> 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 <[email protected]> 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 <[email protected]>: >> >> 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 <[email protected]> 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"
