[ann] gtspotter: a moldable interface for spotting objects

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?

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 :_

Stef

On 07 Dec 2014, at 05:14, Tudor Girba <[hidden email]> 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
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Thanks, Stef.

On Sun, Dec 7, 2014 at 2:35 PM, stephane ducasse <[hidden email]> wrote:

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.

Doru

 

Stef

On 07 Dec 2014, at 05:14, Tudor Girba <[hidden email]> 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
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

--

www.tudorgirba.com

"Every thing has its own flow"

On 07 Dec 2014, at 06:56, Tudor Girba <[hidden email]> wrote:

Thanks, Stef.

On Sun, Dec 7, 2014 at 2:35 PM, stephane ducasse <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

--

www.tudorgirba.com

"Every thing has its own flow"

Cool.

Interesting. I recognize some of the patterns I use, but in a slightly different form.

The widget look very nice and clean. I'd worry about having a very long top-level list, and I know that some of the search patterns are a bit less efficient than what I use today.

I'm impressed by the amount of work going into that.

Thierry

2014-12-07 14:14 GMT+01:00 Tudor Girba <[hidden email]>:

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:

  

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

Doru,

One of the things/aspects that I miss a bit is the 'objects' part. In your overall description/presentation you talk about 'objects', but right now I would say it are mainly 'code objects' like classes & methods and friends, and some IDE artefacts, like menus.

What about arbitrary (user) objects ?

Literal constants, like 123, 'some string' ?
Globals like the Transcript ?
Singletons accessible by class side accessors, like announcers ?
An evaluation functionality, just type an expression ?
Examples ?
The clipboard (contents), open windows, processes, ...

Anyway, I am sure you get the idea ;-)

Sven

> On 07 Dec 2014, at 19:07, Tudor Girba <[hidden email]> wrote:
>
> Hi Sven,
>
> Thanks for the kind words. Indeed, having the current selection is one of the things we should keep in mind. For that we need to go to the next step and integrate the interface in the overall environment. This will certainly come.
>
> Cheers,
> Doru
>
>
>
> On Sun, Dec 7, 2014 at 6:57 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
> > On 07 Dec 2014, at 14:14, Tudor Girba <[hidden email]> wrote:
> >
> > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the Glamorous Toolkit:
> > GTSpotter, a novel interface for spotting objects.
>
> Excellent work, all around. Congratulations to the team. Thank you for pushing things like this, for thinking differently.
>
> Yes, I want this in Pharo 4 too, ASAP (especially since the main shortcut is different from the old one, cmd+Enter vs. shift+Enter).
>
> The presentation is again very well done too: excellent article, super movie. You are putting the bar very high for the rest of us ;-)
>
> A suggestion/idea: would it be possible to take the current selection anywhere and feed it into Spotter ? That way there would be very good way to make it replace all the other shortcuts: you would get implementers, senders, references almost for free.
>
> Sven
>
>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

Hi,

On Sun, Dec 7, 2014 at 3:52 PM, Thierry Goubier <[hidden email]> wrote:

Cool.

Interesting. I recognize some of the patterns I use, but in a slightly different form.

Could you detail? I am asking because I am interesting in search use cases to see if they can be expressed in terms of Spotter of if we need to extend the interface in some way. GTSpotter is supposed to be moldable thus, it is important for it to handle as many use cases as possible.

 

The widget look very nice and clean. I'd worry about having a very long top-level list, and I know that some of the search patterns are a bit less efficient than what I use today.

What do you mean by long top-level lists?

Do you refer to categories for which a query can show many results? In this case, our interface always limits the amount per category to 5. After reaching 5 items, the rest is being computed in a process with lower priority so as not to mess too much with the responsiveness of the UI. If you want to see more than 5, you can always dive in the category and then you focus only on that category. It seems to work well enough.

You should also take into account that most widgets you see are hand-made in a lighter Morphic (called Brick) created by Alex Syrel. The goal of this one is to be fast and scalable.

Does that answer the question?

I'm impressed by the amount of work going into that.

Thanks. Indeed, the work was quite intensive and we went through 3 major variations of the implementations.

Cheers,

Doru

 

Thierry

2014-12-07 14:14 GMT+01:00 Tudor Girba <[hidden email]>:

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:

  

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

--

www.tudorgirba.com

"Every thing has its own flow"

2014-12-07 20:19 GMT+01:00 Tudor Girba <[hidden email]>:

Hi,

On Sun, Dec 7, 2014 at 3:52 PM, Thierry Goubier <[hidden email]> wrote:

Cool.

Interesting. I recognize some of the patterns I use, but in a slightly different form.

Could you detail? I am asking because I am interesting in search use cases to see if they can be expressed in terms of Spotter of if we need to extend the interface in some way. GTSpotter is supposed to be moldable thus, it is important for it to handle as many use cases as possible.

Well, the hierarchical, drill-down type of recursive searches is something I do regularly, so I can relate. They are not as general; they revolve as a cascading sequence of implementors/finder/senders/accesses/package/class searches, but from inside the browser (but, since a search result is given in a browser, then you can keep drilling down).

 

 

The widget look very nice and clean. I'd worry about having a very long top-level list, and I know that some of the search patterns are a bit less efficient than what I use today.

What do you mean by long top-level lists?

Do you refer to categories for which a query can show many results? In this case, our interface always limits the amount per category to 5. After reaching 5 items, the rest is being computed in a process with lower priority so as not to mess too much with the responsiveness of the UI. If you want to see more than 5, you can always dive in the category and then you focus only on that category. It seems to work well enough.

Ok. I see how you are targetting that. I was thinking of what would happen if you have many extensions going into the root items.

You should also take into account that most widgets you see are hand-made in a lighter Morphic (called Brick) created by Alex Syrel. The goal of this one is to be fast and scalable.

Cool. It's an issue for many things, and its great to see someone tackling speed issues.

I dropped some type of Morphs for that reason.

 

Does that answer the question?

Yes, it did.

 

I'm impressed by the amount of work going into that.

Thanks. Indeed, the work was quite intensive and we went through 3 major variations of the implementations.

What was I told about Smalltalk the very first time I had to use it as a student? "the language where you can break and redo all your code in a very short time.".

Thierry

 

Cheers,

Doru

 

Thierry

2014-12-07 14:14 GMT+01:00 Tudor Girba <[hidden email]>:

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:

  

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

--

www.tudorgirba.com

"Every thing has its own flow"

Hi Doru and all,

Great work. All these tools are really moving the development experience a step forward :)

I will try it ASAP.

At this time, I just wonder if it is possible to search text in method sources. It is often useful.

Another related thing I don't know how to do, is to refactor a set of methods (could be some methods to 20 or more). In these methods, I send a specific message. Now, I just want to remove the message implementation (it is not a rename) and I have to update the code accordingly. Sometimes, I could do that by just a search/replace (text) functionality (would be cool to use patterns there) in methods source code but I cannot find a way do that for now. So I do it by hand.

I wonder if it already exists a way to do that or if GTSpotter could address this issue.

Christophe.

Le 7 déc. 2014 à 14:14, Tudor Girba a écrit :

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