Kilon, You are right that tools will not satisfy "everyone" but I think Doru's point is we want the default tools to satisfy the majority. However the tool is new and there are _some_ gaps that _can_ be filled if people push the use case, so they want people to push back (even if sometimes it tends towards complaining).
Now I wonder if the old inspector could somehow be embedded as a tab in GTInspector. Then rather than the Preference turning GTInspector off, it just changes the default view to the old inspector. So those people feeling the need for the old inspector still get exposed to GTInspector and become familiar with it in a progressive way. Doru, As I understand it, each tab is matched to a method definition on the object. So what about enhancing the explorability of the definitions for the existing tabs. Like a right click on the tab to open the definition for that tab. cheers -ben On Sat, Dec 27, 2014 at 4:56 AM, kilon alios <[email protected]> wrote: > I have acknowledge the fact that after I mentioned things I missed from > old workspace you were quick to integrate them back to Playground (copy, > paste, implementors, senders etc). You dont understand my premise. My > premise that in the end a tool can only satisfy some people but not all of > them. To deny that is to deny the fabric of our reality. So my belief is > that the answer to the question that Sven asked and I was replying it to > ". So what is best, we all together use and make the best tools, or we all > work with different tools ?" is "both". We as a community help GT te > familiar with it in a progressive way.ools evolve with our contributions > (certainly I would love to contribute at some point too) and this > is definitely the start of a long term evolution but also on the other hand > individual of groups of pharo coder may create their own tools to fill the > gaps and satisfy needs the existing tools do not . > > Afterall one does not bother to use a fairly unpopular language / IDE that > is easy to hack if he does not intend to at least do some hacking with it. > The ease of building custom IDE tools with Pharo is what makes Pharo so > much fun. > > On Fri, Dec 26, 2014 at 10:13 PM, Tudor Girba <[email protected]> > wrote: > >> Hi Kilon, >> >> Your premise is incorrect. Since two months we are gathering feedback and >> actively incorporating it in the tools. Quite some changes happened exactly >> because of this exercise, and they will continue to happen. Tools do get >> redesigned when there are enough arguments. >> >> You do not have to "suck it up". I have no interest in building something >> for my own needs only. I can do that by myself without going through all >> the trouble of asking people. >> >> We need to make explicit what does not work and the design emerges out of >> that. Your points of view matter. Your opinions will not be blindly >> incorporated and the final decision remains with the team that builds these >> tools, but the majority of times the design was agreed by everyone. This >> can work. >> >> I understand that it can be slightly inconvenient at times, but we want >> to get far fast, and for that we need everyone's help at least as feedback. >> If we keep the other tools around, the incentive to fall back on the >> existing habit is too great and feedback does not happen. Please put a bit >> more trust in us and we'll try to live up to your expectations. >> >> Cheers, >> Doru >> >> >> >> >> On Fri, Dec 26, 2014 at 7:40 PM, kilon alios <[email protected]> >> wrote: >> >>> Why cant be both ? Why it has to be black and white ? What if we , I, >>> someone does not like the design of a tool at a fundamental level ? >>> >>> If you dont like a tool then you dont like a tool, its not as if the >>> tool itself will be redesigned to fit your own needs . You have two choices >>> a) suck it up and compromise with what you have b) suck it up go through >>> the pain / pleasure of creating your own solution. One thing I learned with >>> coding is that for other codes its usually "use the right tool for the >>> right job" but for me is "the right tools for the right coder". >>> >>> "Personal Preferences" is the name of the game. Plus I disagree that >>> without variation of effort we can have high quality tools. Take a look at >>> the software landscape , there is extremely variation out there, why you >>> think Pharo is immune to that ? >>> >>> On Fri, Dec 26, 2014 at 8:14 PM, Sven Van Caekenberghe <[email protected]> >>> wrote: >>> >>>> >>>> > On 26 Dec 2014, at 17:42, stepharo <[email protected]> wrote: >>>> > >>>> > + 10000 >>>> > >>>> > Debugging the rendering loops of Athens was such an example. In Bloc >>>> I get some race conditions with MC forked process... another fun one. >>>> > Let people decide!!! >>>> > >>>> > Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! >>>> > I WANT to DECIDE WHEN. I control my agenda and my own schedule and my >>>> list is huge. >>>> >>>> OK, I understand, but how is this different from any other radical >>>> changes that we did ? >>>> >>>> When we introduced the Eye inspectors we did not offer two options at >>>> the same time (and I can give 10s of examples). So what is best, we all >>>> together use and make the best tools, or we all work with different tools ? >>>> >>>> > Stef >>>> >> 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 >>>> >>>
