| Method call hierarchy feature in M1 [message #53906] |
Tue, 10 June 2003 16:12  |
Eclipse User |
|
|
|
Hi,
I have just installed 3.0 M1 and I would like to commend you guys for the
excellent enhancements in JDT. I would like to make a comment about "Method
call hierarchy" hoping that this is the appropriate venue. If not, please
redirect me.
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?
Also, it would be nice to have a feature similar to "Link with Editor" so
that while code browsing "Method call hierarchy" can be updated as well.
Best regards.
|
|
|
|
|
|
|
|
| Re: Method call hierarchy feature in M1 [message #56684 is a reply to message #56546] |
Fri, 13 June 2003 13:35  |
| Eclipse User |
|
|
|
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 14: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 #57031 is a reply to message #56900] |
Fri, 13 June 2003 15: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
|
|
|
|
|
|
| Re: Method call hierarchy feature in M1 [message #57597 is a reply to message #57496] |
Sat, 14 June 2003 16:08 |
| Eclipse User |
|
|
|
Yes, but control-mouse-over is a prelude to a control-mouse-click, so it
could be confusing...
-- Scott
"Vladimir Blagojevic" <vladimir@cs.yorku.ca> wrote in message
news:bcfald$jn$1@rogue.oti.com...
> But it is not Ctrl+mouse click but Ctrl+mouse over. I dont thnk that has
any
> default operation over tree structures- at least not in Microsoft Lookout
I
> am using to read these newsposts :)
>
> > > 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.
> >
> > Careful -- control+mouse is typically a "drag copy" operation in a tree
> > widget -- this would be inconsistent behavior. (I'm not sure what "drag
> > copy" would mean in this view, but that's the normal meaning of it for
> many
> > other tree views...)
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04296 seconds
Home