Rearranger RFE: new group for implementing/overriding methods
Hi Dave,
First, thanks for the nice plugin.
Currently it is possible to create a rule for "Interface Methods". It
would be cool, if it also would allow a group for "Implementing Methods"
(no matter, whether interface or just abstract in the super-class) and
one for "Overriding Methods" (which override super-class methods).
Thanks in advance.
Tom
Please sign in to leave a comment.
Thanks, Tom. Can you clarify, so I'm sure I understand what you'd like --
You can currently specify a rule like
which will select any methods that implement or override a superclass or interface method.
1) Do you want the ability to differentiate between overriding a superclass method and implementing an abstract method?
The "Interface Method" rule was created so that methods could be sorted by interface, and tailored comments (containing the interface name) could be generated. It does not sound like you need this ability to group and generate tailored comments; rather, it sounds like you need only the ability to distinguish overriding and implementing attributes of methods. Suppose a class X has two superclasses Y and Z. Is it desirable to be able to group all of X's methods that override class Z methods separately from all of X's methods that override class Y's methods? I don't think so.
2) So I'm proposing to add one more condition to "Method" rules; besides static, abstract, final, overridden, overriding, etc. there would be "implementing". Implementing is distinguished from overriding as you describe.
Will that suffice?
-Dave
One more thought. IDEA distinguishes four categories of methods:
- overriding
- overridden
- implementing
- implemented
Perhaps I should add two more criteria to the current 'method' rule (implementing and implemented) and distinguish these from the first two.
Yes.
+1, good idea.
Tom
Even better, although I do not need the "overridden" or "implemented" at
the moment, especially, because "implemented" is the same as "abstract"
or an interface method as long as a non-abstract subclass exist, which
should, because otherwise it makes no sense.
Tom
Hallo Tom,
Try version 3.3; I've added your overridden/overriding/ implemented/implementing criteria for methods, and show the corresponding icons in the confirmation and live rearrangement dialogs. Let me know if it gives you any trouble.
-Dave
Thanks, Dave, I'll give it a try.
Tom
Actually you'll need version 3.4. 3.3 wouldn't display any icons (except for me in my development environment...)
-Dave
Cool. The icons are back and Enter works as expected.
Thanks :)
(Now, the Ctrl-Up/Down still behaves weirdly but that's
ok..)
Vince.
In playing around with keystrokes and focus, I noticed a few things:
- As you press the tab key, the focus goes from the tree to scroll pane's vertical bar, horizontal bar, dialog's OK button, Cancel button, and back to tree. Unfortunately there's no default visual difference for the slider bars when selected. You just have to know, I guess.
- When focus is on a slider bar, up/down arrows and left/right arrows move the slider one increment. Page up/down moves an entire page, etc.
- Ctrl-up/down in the tree isn't documented in Swing to do anything, but for a table is described as "deselect selection". This seems to be what is happening. If one row is selected, ctrl-down leaves it outlined but unselected; ctrl-up reselects it. What is it you'd like or expect it to do?
-Dave
Regarding the scrollbars, you can make them non-focusable.
Tom
Yes, could do. Or could modify the paint() routine to do something to highlight them when focused.
But to make them non-focusable would mean being unable to control the scrolling with the keyboard. I guess I'll just leave it as is for now.
-Dave
IIRC, moving the selection in the tree or table automatically scrolls it
into the visible area, so there is no need for moving a scrollbar
separately.
Tom
OK, I'm convinced. :) I'll make them unfocusable.