Implementors / Senders browser improvements

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementors / Senders browser improvements

jtuchel
Hi,

I remember there once was some addon/freebie that replaced the usual senders/implementors browser stuff. The great thing about it was that if you were searching for senders/implementors of a fragment of a method name (like 'print*') it opened a Browser where you had a list of all possible hits (method names) on the left and could select each of them to browser the respective method(s).

I forgot about it, but I am now on a project where I have to learn most of what the code is about by reading it (no colleagues or paper at hand), so the tools of VAST out of the box just annoy me and steal lots of my time.

Why? Because if I go to Transcript->Tools->Browse Implementors and enter a method name fragment, I get a prompter presenting me all possible (and some non-existent) candidates for the method name fragment. I can choose one of them and then all the other candidates are forgotten. If I find out the fragment I chose was not the one I was actually looking for, I have to start all over again. This costs lots of seconds and brain power (plus a few extra seconds for being upset about how stupid this thing is) every single time.

So I actually have two questions:

  • Does anybody know which freebie that was and do you happen to know if it still runs on the current 8.6-versions and where I can get it (Maybe it's even shipped with VAST?) ?
  • Do others also feel the need for far better search capabilities in VAST? Is this an area of improvement that we should try to convince Instantiations to work on? To me it seems like the work done on the code completion tools is a good basis for  much better search support in VAST

Thanks for reading


Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Wayne Johnston
Not what you specifically are asking for (fragment of a method name), but...
I think a great way to browse code is via the TrailBlazer browser.  Yes maybe it has fallen out of favor.  But it is great for looking at chains of implementors & senders - without multiple windows.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Louis LaBrunda
In reply to this post by jtuchel
Hi Joachim,

Sorry, I have no answer for your first question.  As for wanting better method search capabilities, I'm all for it.  I have had the same feelings (not quite as bad) often and would love a browser window where one could choose from the different matches and view the method.  It would also be nice to easily tell what class and side (instance/class) the method is in.

Lou



On Wednesday, October 5, 2016 at 2:59:02 AM UTC-4, Joachim Tuchel wrote:
Hi,

I remember there once was some addon/freebie that replaced the usual senders/implementors browser stuff. The great thing about it was that if you were searching for senders/implementors of a fragment of a method name (like 'print*') it opened a Browser where you had a list of all possible hits (method names) on the left and could select each of them to browser the respective method(s).

I forgot about it, but I am now on a project where I have to learn most of what the code is about by reading it (no colleagues or paper at hand), so the tools of VAST out of the box just annoy me and steal lots of my time.

Why? Because if I go to Transcript->Tools->Browse Implementors and enter a method name fragment, I get a prompter presenting me all possible (and some non-existent) candidates for the method name fragment. I can choose one of them and then all the other candidates are forgotten. If I find out the fragment I chose was not the one I was actually looking for, I have to start all over again. This costs lots of seconds and brain power (plus a few extra seconds for being upset about how stupid this thing is) every single time.

So I actually have two questions:

  • Does anybody know which freebie that was and do you happen to know if it still runs on the current 8.6-versions and where I can get it (Maybe it's even shipped with VAST?) ?
  • Do others also feel the need for far better search capabilities in VAST? Is this an area of improvement that we should try to convince Instantiations to work on? To me it seems like the work done on the code completion tools is a good basis for  much better search support in VAST

Thanks for reading


Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Seth Berman
+1 to all feedback.

The underlying query architecture of code completion was designed for global search of different kinds so that is where I would start.
There is so much more potential information and contexts than present in method-level code completion that async queries would be required...unless one is comfortable with their whole image freezing
while the all the information is queried...which I am not.
The engine has the concepts of an "asynchronous query", but it's unused and I doubt I could just plug one in with no code changes....but I think it would be close.

I've experimented with having a search box show up inline with your cursor. or at the upper right of each browser window.  And then played around to see if I liked the usability.
The presentation here is actually really important since global search contains so many different contexts, there's nothing to really analyze beforehand (except your history) for it to
identify the context so there needs to be a way to present all the different (potentially pluggable) contexts as you type.  

So I agree with the desires that have been presented...I experimented myself once upon a time because I have the same desire.
How to get me to do it is pretty straightforward....when everyone receives the next customer survey...if you feel strongly about this then I encourage you to make it known so it bubbles up the list.
What we end up working on is what is at the top of the list;)

-- Seth

On Wednesday, October 5, 2016 at 8:59:31 AM UTC-4, Louis LaBrunda wrote:
Hi Joachim,

Sorry, I have no answer for your first question.  As for wanting better method search capabilities, I'm all for it.  I have had the same feelings (not quite as bad) often and would love a browser window where one could choose from the different matches and view the method.  It would also be nice to easily tell what class and side (instance/class) the method is in.

Lou



On Wednesday, October 5, 2016 at 2:59:02 AM UTC-4, Joachim Tuchel wrote:
Hi,

I remember there once was some addon/freebie that replaced the usual senders/implementors browser stuff. The great thing about it was that if you were searching for senders/implementors of a fragment of a method name (like 'print*') it opened a Browser where you had a list of all possible hits (method names) on the left and could select each of them to browser the respective method(s).

I forgot about it, but I am now on a project where I have to learn most of what the code is about by reading it (no colleagues or paper at hand), so the tools of VAST out of the box just annoy me and steal lots of my time.

Why? Because if I go to Transcript->Tools->Browse Implementors and enter a method name fragment, I get a prompter presenting me all possible (and some non-existent) candidates for the method name fragment. I can choose one of them and then all the other candidates are forgotten. If I find out the fragment I chose was not the one I was actually looking for, I have to start all over again. This costs lots of seconds and brain power (plus a few extra seconds for being upset about how stupid this thing is) every single time.

So I actually have two questions:

  • Does anybody know which freebie that was and do you happen to know if it still runs on the current 8.6-versions and where I can get it (Maybe it's even shipped with VAST?) ?
  • Do others also feel the need for far better search capabilities in VAST? Is this an area of improvement that we should try to convince Instantiations to work on? To me it seems like the work done on the code completion tools is a good basis for  much better search support in VAST

Thanks for reading


Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

jtuchel
Hi Seth,

Thanks for your thoughts on the feasibility of a better search capability based on the code completion stuff. Maybe (well, very likely) I have a very wrong picture of what is going on in there...

So let's come back to a simple solution for this. Searching for Implementors/Senders/References is quite fast as it is right now. It's more the presentation I am unhappy with.

Why do I have to start all over with my fragment (say Implementors of methods starting with "print"), selecting one of the candidates presented in the first prompter and getting through to the actual implementors browser for this one single method?

It would be so much better if the implementors browser had an extra pane in which all method names matching my search term are listed and if I could just work through the list by clicking on the ones I think might be best suited as a start.

So I am not asking for better search capabilites that do a deeper/wider/more general search and maybe also show me all possible matching pool variables or such. It would be cool to have such a beast, but that's for the extra points ;-)
I am asking for a better presentation for the existing searches in the first place.

Hope that clarifies a bit.

...and I know I once had a freebie loaded that has such a browser. And it wasn't Trailblazer, because I never really understood how to use Trailblazer...

Joachim





--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Seth Berman
Hello Joachim,

Yes, I understand.  
I hear many feature/enhancement requests that I generally agree with, but I'm "wired" to better understand how to frame the actual problem appropriately for the product, and trying to create a cohesive story or overall theme from the aggregation of what I hear.
I'm not the best person to send off to do tweaks here and there...and probably never will be.  Thus, I profess I will appear to miss the point of what individuals are saying (and sometimes that is actually true).  But in this case...yes...I understand what you are asking.
And no...I don't like Trailblazer either.  I tried to use it for awhile just to see if anything stuck...but if anything did...it has now escaped my memory.

-- Seth

On Wednesday, October 5, 2016 at 11:24:06 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thanks for your thoughts on the feasibility of a better search capability based on the code completion stuff. Maybe (well, very likely) I have a very wrong picture of what is going on in there...

So let's come back to a simple solution for this. Searching for Implementors/Senders/References is quite fast as it is right now. It's more the presentation I am unhappy with.

Why do I have to start all over with my fragment (say Implementors of methods starting with "print"), selecting one of the candidates presented in the first prompter and getting through to the actual implementors browser for this one single method?

It would be so much better if the implementors browser had an extra pane in which all method names matching my search term are listed and if I could just work through the list by clicking on the ones I think might be best suited as a start.

So I am not asking for better search capabilites that do a deeper/wider/more general search and maybe also show me all possible matching pool variables or such. It would be cool to have such a beast, but that's for the extra points ;-)
I am asking for a better presentation for the existing searches in the first place.

Hope that clarifies a bit.

...and I know I once had a freebie loaded that has such a browser. And it wasn't Trailblazer, because I never really understood how to use Trailblazer...

Joachim





--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Wayne Johnston
In reply to this post by jtuchel
Guess I don't understand this partial method name scenario.  Yes sometimes you know part of a method name and such a browser might be nice.  But usually you are looking at the code in a browser.  Doesn't the browser give you a way to find implementors of all messages sent (that is, not having to go to the Transcript)?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Seth Berman
Hi Wayne,

I believe you are referring to the "Browse Messages"  from which you can get implementors/senders of just the messages used in the code editor.
I believe Joachim is talking more about the inefficient workflow that occurs when you have to repeatably type your search term in the Transcript->Tools->Browse (Senders|Implementers|References).

It's probably worthy of some kind of screencast...but there is another way to do this.  For example, I never use these menu items at all.  I use a combination of the code completion box, shortcuts and dragNdrop to get all this information.
I would rather have a global search box...but in the meantime it does the job.
Anything in the code completion box (Classes, Pools, pool entries, symbols, atoms, messages, globals.....) support drag N drop and the code completion queries support camel case matching and prefix matching which is far superior to just prefix matching if you can manage to adjust your thinking and muscle memory.

Scenario
1. I'm in a method about to type asOrderedCollection...but I would like to know who actually implements that.
2. Usually right inline, or I might go to a workspace, I type: aoc      which is good enough to match asOrderedCollection.
3. I find the asOrdererdCollection entry in the code completion box and drag it outside the box...and let go.   I will get an implementors browser
4. Now I want to see senders of asOrderedCollection...so i press <Ctrl+Space> to bring up the code completion results again...drag the asOrderedCollection entry out...but I hold down the <Ctrl> key while I let go of drag.  Now I get a senders browser.

I'm basically doing stuff like this all the time and never bother with the Transcript menu items anymore....The following is a list of questions I resolve very quickly just with code completion and drag n drop.
1. Who implements this method I only sorta know the name of? <drag>  Who are the senders <Ctrl key down during drag>
2. Where is this symbol referenced <drag>
3. Where is the pool variable defined. <drag>  Where is it referenced <Ctrl key down during drag>
4. What are the ascii values and symbolic names of characters.  (Just type $  followed by <Ctrl+Space>)
5. Show me a hierarchy browser on this class.  Show me where this class is referenced <Ctrl key down during drag>

and more...

-- Seth

On Wednesday, October 5, 2016 at 12:01:08 PM UTC-4, Wayne Johnston wrote:
Guess I don't understand this partial method name scenario.  Yes sometimes you know part of a method name and such a browser might be nice.  But usually you are looking at the code in a browser.  Doesn't the browser give you a way to find implementors of all messages sent (that is, not having to go to the Transcript)?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Richard Sargent
Administrator
In reply to this post by jtuchel
On Tuesday, October 4, 2016 at 11:59:02 PM UTC-7, Joachim Tuchel wrote:
Hi,

I remember there once was some addon/freebie that replaced the usual senders/implementors browser stuff. The great thing about it was that if you were searching for senders/implementors of a fragment of a method name (like 'print*') it opened a Browser where you had a list of all possible hits (method names) on the left and could select each of them to browser the respective method(s).

I forgot about it, but I am now on a project where I have to learn most of what the code is about by reading it (no colleagues or paper at hand), so the tools of VAST out of the box just annoy me and steal lots of my time.

Why? Because if I go to Transcript->Tools->Browse Implementors and enter a method name fragment, I get a prompter presenting me all possible (and some non-existent) candidates for the method name fragment. I can choose one of them and then all the other candidates are forgotten. If I find out the fragment I chose was not the one I was actually looking for, I have to start all over again. This costs lots of seconds and brain power (plus a few extra seconds for being upset about how stupid this thing is) every single time.

Just to clarify (or be pedantic, if you prefer), the Browse Implementors allows you to select any or all of the candidate selectors. It is the Browse Senders which only allows a single selection. In general, I have started with the list of implementors and then look at the senders of the interesting implemented methods, one by one.
 

So I actually have two questions:

  • Does anybody know which freebie that was and do you happen to know if it still runs on the current 8.6-versions and where I can get it (Maybe it's even shipped with VAST?) ?
  • Do others also feel the need for far better search capabilities in VAST? Is this an area of improvement that we should try to convince Instantiations to work on? To me it seems like the work done on the code completion tools is a good basis for  much better search support in VAST

Thanks for reading


Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

jtuchel
Richard,

maybe you'll be disappointed by me not seeing you as pedantic. In fact I never tried multiple selection on both of these prompters.
So one of my complaints about browsing implementors has beeon proven to be a mixture of "I am ignorant" and "this could sure be more beautiful" ;-)

Thanks for taking the time to answer, I immediately fell in love with the multi select on the Implementors prompter ;-) Although that could be much more beautiful ;-))))

So maybe a little adjustment on the prompter's heading and the same mutli-selction facility for Senders would be low hanging fruit for the next release ;-)

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

jtuchel
In reply to this post by Seth Berman
Seth,

I like your attitude and confess to have a tendency toward trying to look at the big picture and build the right solution right away. Sometimes, however, a cheap solution can be a first step to solve 80% of the problem with little effort.
The other 20% will take 8 the other 95% of the effort ;-)

Joachim




Am Mittwoch, 5. Oktober 2016 17:39:27 UTC+2 schrieb Seth Berman:
Hello Joachim,

Yes, I understand.  
I hear many feature/enhancement requests that I generally agree with, but I'm "wired" to better understand how to frame the actual problem appropriately for the product, and trying to create a cohesive story or overall theme from the aggregation of what I hear.
I'm not the best person to send off to do tweaks here and there...and probably never will be.  Thus, I profess I will appear to miss the point of what individuals are saying (and sometimes that is actually true).  But in this case...yes...I understand what you are asking.
And no...I don't like Trailblazer either.  I tried to use it for awhile just to see if anything stuck...but if anything did...it has now escaped my memory.

-- Seth

On Wednesday, October 5, 2016 at 11:24:06 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thanks for your thoughts on the feasibility of a better search capability based on the code completion stuff. Maybe (well, very likely) I have a very wrong picture of what is going on in there...

So let's come back to a simple solution for this. Searching for Implementors/Senders/References is quite fast as it is right now. It's more the presentation I am unhappy with.

Why do I have to start all over with my fragment (say Implementors of methods starting with "print"), selecting one of the candidates presented in the first prompter and getting through to the actual implementors browser for this one single method?

It would be so much better if the implementors browser had an extra pane in which all method names matching my search term are listed and if I could just work through the list by clicking on the ones I think might be best suited as a start.

So I am not asking for better search capabilites that do a deeper/wider/more general search and maybe also show me all possible matching pool variables or such. It would be cool to have such a beast, but that's for the extra points ;-)
I am asking for a better presentation for the existing searches in the first place.

Hope that clarifies a bit.

...and I know I once had a freebie loaded that has such a browser. And it wasn't Trailblazer, because I never really understood how to use Trailblazer...

Joachim





--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

jtuchel
In reply to this post by Seth Berman
Seth

Am Mittwoch, 5. Oktober 2016 18:31:14 UTC+2 schrieb Seth Berman:
Hi Wayne,

I believe you are referring to the "Browse Messages"  from which you can get implementors/senders of just the messages used in the code editor.
I believe Joachim is talking more about the inefficient workflow that occurs when you have to repeatably type your search term in the Transcript->Tools->Browse (Senders|Implementers|References).

exactly!
 
It's probably worthy of some kind of screencast...but there is another way to do this.  For example, I never use these menu items at all.  I use a combination of the code completion box, shortcuts and dragNdrop to get all this information.
I would rather have a global search box...but in the meantime it does the job.
Anything in the code completion box (Classes, Pools, pool entries, symbols, atoms, messages, globals.....) support drag N drop and the code completion queries support camel case matching and prefix matching which is far superior to just prefix matching if you can manage to adjust your thinking and muscle memory.


I remember seeing you do that drag&drop thingie and was immediately fascinated. But when I see that popup in front of me, the idea that I could drag things from it never sparks up ;-)
 
Scenario
1. I'm in a method about to type asOrderedCollection...but I would like to know who actually implements that.
2. Usually right inline, or I might go to a workspace, I type: aoc      which is good enough to match asOrderedCollection.

I just tried it in my 8.6 image. Whoa. Only thing: you need to do a right button drag... Is this wired to the general drag&drop button setting that I always forget about where to find it?
 
3. I find the asOrdererdCollection entry in the code completion box and drag it outside the box...and let go.   I will get an implementors browser

This really nice! I need to get this into my muscular brain ;-)
 

4. Now I want to see senders of asOrderedCollection...so i press <Ctrl+Space> to bring up the code completion results again...drag the asOrderedCollection entry out...but I hold down the <Ctrl> key while I let go of drag.  Now I get a senders browser.

Hmm. Ctrl+drag. It's of course my fault, but this is hard to get used to if you're more a point and click guy... ;-)
 
I'm basically doing stuff like this all the time and never bother with the Transcript menu items anymore....The following is a list of questions I resolve very quickly just with code completion and drag n drop.

 
1. Who implements this method I only sorta know the name of? <drag>  Who are the senders <Ctrl key down during drag>
2. Where is this symbol referenced <drag>
3. Where is the pool variable defined. <drag>  Where is it referenced <Ctrl key down during drag>
4. What are the ascii values and symbolic names of characters.  (Just type $  followed by <Ctrl+Space>)
5. Show me a hierarchy browser on this class.  Show me where this class is referenced <Ctrl key down during drag>



This is a cool list and I need to force myself to play with it. Seems like you can save a lot of time with this. One thing is missing though: if you try to guess what method name could be suitable for a task by trying a fragment of a method name, like 'print*' or '*CustomerRef*' and such. This is the kind of searches I need to perform in my current project...

So there is a lot more buried in the code completion tool than you can see.

Joachim




 
and more...

-- Seth

On Wednesday, October 5, 2016 at 12:01:08 PM UTC-4, Wayne Johnston wrote:
Guess I don't understand this partial method name scenario.  Yes sometimes you know part of a method name and such a browser might be nice.  But usually you are looking at the code in a browser.  Doesn't the browser give you a way to find implementors of all messages sent (that is, not having to go to the Transcript)?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Louis LaBrunda
Hi Guys,

snip...

This is a cool list and I need to force myself to play with it. Seems like you can save a lot of time with this. One thing is missing though: if you try to guess what method name could be suitable for a task by trying a fragment of a method name, like 'print*' or '*CustomerRef*' and such. This is the kind of searches I need to perform in my current project...

Every once in a while I find myself off in the weeds with a project that needs things that VA Smalltalk may or may not have but are less used, so, the kind of search that Joachim suggests would be great.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Seth Berman
In reply to this post by jtuchel
Hi Joachim,

True, the "cheap" solutions I sometimes do for support cases with a proclaimed caveat that it may or may not make it's way into production.
The reason I don't often do this approach relates to our business model...which is basically to support everything until the end of time.
Or introduce migration entries which I don't like to do if I can help it.

So if the other "20% on to 95%" occurs over a series of releases...it really becomes a burden if I want to scrap the original cheap solution because it wasn't thought through or is no longer consistent with where we want to take the product and could have been avoided had we put a little thought in it beforehand.

I think the cheap solution can provide short-term satisfaction for individuals...and I'm all for the satisfaction part.  I worry more about the compounding of cheap solutions into the product which creates
an un-cohesive mess.

I see evidence of this in many of our menus and settings for example.  Where are all the settings?  In many cases...why are they there.  Where are they stored?  Why are some menu items available in one kind of browser...but not another when they would both make sense. The answer in many cases is that they were added in response to demand x from person y and that continued over time.

I try to be pragmatic so I understand some of this is unavoidable.  There are seemingly "cheap" things I am willing to do.  After all, on the surface cheap means less work. 
But I'm always very cautious of it which is my only resistance.

But the bottom line is, I think your idea is good and a solution to it would be helpful.  Perhaps that solution is exactly as you specified...perhaps not.
My only point is I need more clarity before I sign up to support it in our product.

I like the discussion though...I think it adds to that clarity.

-- Seth


On Thursday, October 6, 2016 at 8:13:44 AM UTC-4, Joachim Tuchel wrote:
Seth,

I like your attitude and confess to have a tendency toward trying to look at the big picture and build the right solution right away. Sometimes, however, a cheap solution can be a first step to solve 80% of the problem with little effort.
The other 20% will take 8 the other 95% of the effort ;-)

Joachim




Am Mittwoch, 5. Oktober 2016 17:39:27 UTC+2 schrieb Seth Berman:
Hello Joachim,

Yes, I understand.  
I hear many feature/enhancement requests that I generally agree with, but I'm "wired" to better understand how to frame the actual problem appropriately for the product, and trying to create a cohesive story or overall theme from the aggregation of what I hear.
I'm not the best person to send off to do tweaks here and there...and probably never will be.  Thus, I profess I will appear to miss the point of what individuals are saying (and sometimes that is actually true).  But in this case...yes...I understand what you are asking.
And no...I don't like Trailblazer either.  I tried to use it for awhile just to see if anything stuck...but if anything did...it has now escaped my memory.

-- Seth

On Wednesday, October 5, 2016 at 11:24:06 AM UTC-4, Joachim Tuchel wrote:
Hi Seth,

Thanks for your thoughts on the feasibility of a better search capability based on the code completion stuff. Maybe (well, very likely) I have a very wrong picture of what is going on in there...

So let's come back to a simple solution for this. Searching for Implementors/Senders/References is quite fast as it is right now. It's more the presentation I am unhappy with.

Why do I have to start all over with my fragment (say Implementors of methods starting with "print"), selecting one of the candidates presented in the first prompter and getting through to the actual implementors browser for this one single method?

It would be so much better if the implementors browser had an extra pane in which all method names matching my search term are listed and if I could just work through the list by clicking on the ones I think might be best suited as a start.

So I am not asking for better search capabilites that do a deeper/wider/more general search and maybe also show me all possible matching pool variables or such. It would be cool to have such a beast, but that's for the extra points ;-)
I am asking for a better presentation for the existing searches in the first place.

Hope that clarifies a bit.

...and I know I once had a freebie loaded that has such a browser. And it wasn't Trailblazer, because I never really understood how to use Trailblazer...

Joachim





--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Implementors / Senders browser improvements

Richard Sargent
Administrator
In reply to this post by jtuchel
On Thursday, October 6, 2016 at 5:09:18 AM UTC-7, Joachim Tuchel wrote:
Richard,

maybe you'll be disappointed by me not seeing you as pedantic. In fact I never tried multiple selection on both of these prompters.
So one of my complaints about browsing implementors has beeon proven to be a mixture of "I am ignorant" and "this could sure be more beautiful" ;-)

Thanks for taking the time to answer, I immediately fell in love with the multi select on the Implementors prompter ;-) Although that could be much more beautiful ;-))))

So maybe a little adjustment on the prompter's heading and the same mutli-selction facility for Senders would be low hanging fruit for the next release ;-)

Joachim, I have given such a thing considerable thought over the years and each time concluded that it would actually be more trouble than benefit (for me). I find that I need to know which one (or several) of the myriad selectors matching the pattern are the ones I want to learn the senders of. So, I find having the Implementors listed (and possibly trimmed down to the relevant few via judicious use of Remove From List) and then browsing the senders of each selector in turn is more productive (in the sense that I can get a better understanding of how the methods are related, used, etc.).

VisualWorks has a combined view, but I find it frustrating. It has a search box in the top left corner, a candidate list below, buttons to select whether it shows Implementors or Senders of the selected candidate, and the expected list of methods on the right, above a text pane for the source. The problem with it is that switching between Implementors and Senders resets the list of methods, so you cannot winnow the interesting from the irrelevant and be able to switch back and forth between implementors and senders. Two separate windows works much better for me and allows me to see the source of both an implementor and a sender at the same time.

Of course, it wouldn't be that hard to subclass one of the browser windows and add such a tool. Not that I have any interest in doing it! :-)



Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.