Re: [Pharo-users] [Esug-list] [ann] gtspotter: a moldable interface for spotting objects
Hi, This is indeed a significant challenge. Until that point we need a couple of more features, of which the most important is the preview for the selected object. This will come and then we can consider what we can do with it. But, in the meantime, there are a lot of use cases nobody ever considered exactly because there was no easy way to consider them. Like finding all the methods from CodeHolder* that are annotated with <systemsettings>. Or like searching a Person in a Agenda model that someone develops. The cool thing is that you can program this yourself :). Cheers, Doru On Sun, Dec 7, 2014 at 4:05 PM, stephane ducasse <stephane.ducasse@gmail.com
wrote:
On 07 Dec 2014, at 06:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Thanks, Stef.
On Sun, Dec 7, 2014 at 2:35 PM, stephane ducasse < stephane.ducasse@gmail.com> wrote:
Truly excellent! I have to try :) I read the blog (I love the marketing efforts and the documentation effort) :) Now do you a shortcut for finding a - senders?
- a specific method of a class?
This first incarnation of the interface is meant to replace the top level search because that was easier. There is more to come, and we definitely will get to replace the senders, and integrate it even deeper in the workflow
A challenge that I would like to propose to the GTteam is the following one:
Often when I change code (for example, change the API of menus and want to make it clean) I look at all the senders and sender of senders and implementors and senders â¦. What I do is that I stack the browser in the stack where the top are the leaves that I should treat and the next elements are the user of the leavesâ¦. Then what I do I have a physical stack of senders/implementors and I start fixing the top of the stack and I pop.
So the old Omnibrowser based senders/implementors nevers worked to me because I could never understand what I was browsing (senders or implementers and where I was in the stack or search tree).
So my challenge is - how can we support mixing senders and implementors taxes (not mixing the two) - how can we support the navigation with the tree of such tasks.
Iâm not sure that it should be in GTSpotter and many having a tree structure could help.
Stef
Last time I found myself looking for the sender of x but only inside the implementor of y. and of course I wanted to refactored them. And the default message browser is not parametrized via an environment :_
Exactly. This problem exists in any IDE I know.
Really? Iâm surprised because it seems so obvious (if we had a couple million dollars⦠but we have cool guys)
Doru
Stef
On 07 Dec 2014, at 05:14, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit: GTSpotter, a novel interface for spotting objects.
GTSpotter has two goals: - Provide a uniform yet moldable interface that can work on any object, and - Handle searching through arbitrary levels of object nesting.
We think this will have a significant impact on the development workflow in Pharo.
Here is a couple of screenshots: <gtspotter-packages-classes.png> <gtspotter-dive-class-method-sender.png> <gtspotter-playground.png>
A trailer is available here: https://www.youtube.com/watch?v=PhSmjR3NOlU
A detailed description is available here: http://www.humane-assessment.com/blog/introducing-gtspotter
It works already in Pharo 3.0 and can be played with by following the instructions from: http://gt.moosetechnology.org
Please let us know what you think.
Enjoy, The Glamorous Team _______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
participants (1)
-
Tudor Girba