+ 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.
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]
<mailto:[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]
<mailto:[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 <http://www.tudorgirba.com/>
"Every thing has its own flow"
