|
|
|
| Re: Method call hierarchy feature in M1 [message #55330 is a reply to message #53906] |
Thu, 12 June 2003 14:37   |
Eclipse User |
|
|
|
Originally posted by: adam_kiezun.ch.ibm.spam.protection.com
> I am not an usability expert but as a user I think that there is very
> limited benefit of "Location" and "Call" fields having such prominent real
> estate. It is good that they can be turned off to reduce clutter. How about
> moving all other additional metadata into a hover box?
turn them off by using the view menu and selecting 'hierarchy view only'
a.
|
|
|
|
| Re: Method call hierarchy feature in M1 [message #56546 is a reply to message #55463] |
Fri, 13 June 2003 15:03 |
| Eclipse User |
|
|
|
Originally posted by: linnet.nospam.users.sourceforge.net
Vladimir Blagojevic wrote:
> "> What is more annoying of the current implementation is , is that double
> click
>
>>on the method in the tree, doesn't jump to the first location in the
>
> method
>
>>where that is found. I have to do it through the popup menu (then open)
>>or double click on that table (Location/Call)
>
>
> Did you notice that it jumps to location if that file is curently open in
> the editor area? I agree with you - it is a weird deafult behaviour.
>
> But do you agree with me that having line number and the name of the method
> repeated in Location/Call is fairly useless? There must be a better way to
> do this.
>
>
>
Hi Vladimir,
I'm the developer of the call hierarchy view, so I guess that I'm biased
:-) Anyhow, I'd like to comment.
I don't agree that it's useless. The location part of the view presents
the actual call including the actual parameters used. If your method
doesn't take any parameters, I agree. If you only have one call to a
method, I agree (although it allows you to see the actual details of the
call).
Best regards,
Jesper
|
|
|
| Re: Method call hierarchy feature in M1 [message #56684 is a reply to message #56546] |
Fri, 13 June 2003 17:35 |
 Vladimir Blagojevic
Messages: 71
Registered: July 2009 |
Member |
|
|
Hi Jesper,
No doubt that your work is appreciated. The feature is good, serves a
purpose most of the time, all I am saying is "let's make it better".
Use case:
Suppose that a user invoked Method call hierarchy (MCH) on method A. As
currently implemented a tree of method calls that invoke A in selected scope
is presented. Currently there is no option to select a scope. User should
maybe have an optional scope selection - as in search. Not a priority I
guess.
The details of the features I have in mind.
Feature 1:
Improve the the present functionality by introducing one click on the method
element B in MCH tree. One click takes a user to a specified file location
in java editor. File is opened, if necessary, and specified location (call
to A) is highlighted. If multiple calls are made to A from the selected MCH
tree element B, those calls are somehow indicated as well (highlighting,
arrows pointers from left margin etc)
Feature 2:
Introduce hover. Ctrl + mouse over tree element B (that calls A) shows a
source hover for that method B with indication of call(s) made to A. So
basically replicate feature 1 in a different form i.e. java source hover.
Java source hover as currently implemented in JDT might not be suitable
since the current implementation shows only n first lines of selected
element. The better solution might be presenting source of B in a hover
with a scrollable window - similar to F2 - "make hover sticky" feature of
JDT. Anyhow, the goal is to show the source of B and indicate the context of
each call made to A.
By introducing feature 1 and 2 you eliminate the need for the separate
"Location/Call" panel. Functionality is greatly improved , clutter is
reduced and consistency is kept along with features that user is already
familiar with in JDT.
Any opinions?
Best regrads.
|
|
|
| Re: Method call hierarchy feature in M1 [message #56820 is a reply to message #56684] |
Fri, 13 June 2003 18:39 |
| Eclipse User |
|
|
|
Originally posted by: linnet.nospam.users.sourceforge.net
Vladimir Blagojevic wrote:
> Hi Jesper,
>
> No doubt that your work is appreciated. The feature is good, serves a
> purpose most of the time, all I am saying is "let's make it better".
>
I couldn't agree more on the "make it better" idea :-)
> Use case:
>
> Suppose that a user invoked Method call hierarchy (MCH) on method A. As
> currently implemented a tree of method calls that invoke A in selected scope
> is presented. Currently there is no option to select a scope. User should
> maybe have an optional scope selection - as in search. Not a priority I
> guess.
What do you mean by scope in this context? It's possible to set the
limit the search scope on the view menu. Do you have something else in mind?
>
> The details of the features I have in mind.
>
> Feature 1:
>
> Improve the the present functionality by introducing one click on the method
> element B in MCH tree. One click takes a user to a specified file location
> in java editor. File is opened, if necessary, and specified location (call
> to A) is highlighted. If multiple calls are made to A from the selected MCH
> tree element B, those calls are somehow indicated as well (highlighting,
> arrows pointers from left margin etc)
>
>
> Feature 2:
>
> Introduce hover. Ctrl + mouse over tree element B (that calls A) shows a
> source hover for that method B with indication of call(s) made to A. So
> basically replicate feature 1 in a different form i.e. java source hover.
> Java source hover as currently implemented in JDT might not be suitable
> since the current implementation shows only n first lines of selected
> element. The better solution might be presenting source of B in a hover
> with a scrollable window - similar to F2 - "make hover sticky" feature of
> JDT. Anyhow, the goal is to show the source of B and indicate the context of
> each call made to A.
>
>
> By introducing feature 1 and 2 you eliminate the need for the separate
> "Location/Call" panel. Functionality is greatly improved , clutter is
> reduced and consistency is kept along with features that user is already
> familiar with in JDT.
>
> Any opinions?
>
I see your point in presenting the same information in another way. I
have taken the liberty of creating a bug report
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=38904) on this matter.
> Best regrads.
>
>
Best regards,
Jesper
|
|
|
|
| Re: Method call hierarchy feature in M1 [message #56953 is a reply to message #56900] |
Fri, 13 June 2003 19:25 |
| Eclipse User |
|
|
|
Originally posted by: adam_kiezun.ch.ibm.spam.protection.com
> Cool, lets see what happens. BTW you don't seem to be employed by IBM/OTI.
> You have right priviledges in eclipse cvs? Does some project leader from
> IBM/OTI have to approve this "enhacement" ?
i'm Jesper's 'buddy' on the eclipse.org side (the guy who releases Jesper's code to cvs :))
yes, we look at the enhancements and decide if that's the right direction
but it's very good to experiment with different approaches - if anything, it's very easy to revert, right?
cheers
a.
---
eclipse.org
|
|
|
| Re: Method call hierarchy feature in M1 [message #57031 is a reply to message #56900] |
Fri, 13 June 2003 19:53 |
| Eclipse User |
|
|
|
Originally posted by: linnet.nospam.users.sourceforge.net
Hi Vladimir,
> Hi Jesper,
>
>
>>>Suppose that a user invoked Method call hierarchy (MCH) on method A. As
>>>currently implemented a tree of method calls that invoke A in selected
>
> scope
>
>>>is presented. Currently there is no option to select a scope. User
>
> should
>
>>>maybe have an optional scope selection - as in search. Not a priority I
>>>guess.
>>
>>What do you mean by scope in this context? It's possible to set the
>>limit the search scope on the view menu. Do you have something else in
>
> mind?
>
> For example: select java method in editor source file. Right click to get
> context menu.
> The options in the same group along with "Open Call Hierarchy" are "Open
> Declaration", "Open Type Hierarchy" etc. Now newly added in M1 is "Open Call
> Hierarchy". All I am saying is that "Open Call Hierarchy" and probably "Open
> Type Hierarchy" options should be scoped ii.e for these two options add
> another scope menu slideout that scopes the search to:
> Working Set and Workspace etc.
>
>
> Think, or even better try doing "Open Call Hierarchy" on toString() method
> or "Open Type hieararchy " on Iterator. The point is - it gets messy lol :)
> You really need scope IMHO. I want to see where toString() method is called
> in Working Set.
>
Ok, I see your point (toString() is a good candidate for
OutOfMemoryExceptions :-) ). The way the call hierarchy works now is
more static - the search scope is related to the view and not to the
current use of the action (the type hierarchy doesn't have a search
scope yet, but AFAIK it's in the JDT UI plan).
I don't know if it would be a good idea to add search scope to the
context menu. If the menu item is changed there should at least be a
way to use the currently set search scope). The keyboard shortcut should
at least be kept as it is.
Again, I may be biased, but that's the way I use it (and the way
whomever I have pursuaded to use the thing use it :-) ).
Best regards,
Jesper
>
>
>>I see your point in presenting the same information in another way. I
>>have taken the liberty of creating a bug report
>>(https://bugs.eclipse.org/bugs/show_bug.cgi?id=38904) on this matter.
>
>
> Cool, lets see what happens. BTW you don't seem to be employed by IBM/OTI.
> You have right priviledges in eclipse cvs? Does some project leader from
> IBM/OTI have to approve this "enhacement" ?
>
No, I'm just a contributor kept on a short leash by my master :-) No
offense meant, Adam :-)
> Best regards.
>
>
>
Best regards,
Jesper
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05146 seconds
] 
Search
Help
Register
Login
Home
