2 new plugin ideas
I had two ideas for plugins, I might write them, but if someone else wanted to, that would be cool too. Also, either of them might already be implemented somewhere and I just didn't see it.
1. Live Rearrange Plugin
I press and hold CtrlShiftR, or some key, and a window that looks like the Recent Files List (in that it's undecorated and small) comes up, showing the current class's PSI. While still holding down CtrlShiftR, I can drag and drop items within the structure. This will be useful until the IDEA Structure view allows for drag and drop.
2. Permissions Modifier Plugin
Allows you to define a set of keys in the keymap that toggle or set different permissions flags for the field, method, or class that the cursor is in, or that is in the selection. For example, if I have:
private Thing getThing() {..}
I could have the cursor anywhere on that line before the {, and I press CtrlShiftP, and I get:
public Thing getThing() {..}
Then I press CtrlShiftS, and I get:
public synchronized Thing getThing() {..}
I press CtrlShiftS again, and get:
public Thing getThing() {..}
If anyone has any comments on these, or ideas, or if someone wants to implement them, let me know (so I know not to try first :).
请先登录再写评论。
All things are possible, but at the moment I'd be happy to get a window up that works!
A few things I've discovered, more for your information and entertainment than anything else:
- JInternalFrame does not have a setUndecorated() method, while JFrame does.
- a Popup will show tooltips only if the ToolTipManager is told to
However, drag and drop doesn't work in a Popup -- I suppose it is due to some similar conflict between heavy and lightweight components. So far I have only seen D&D work in a JFrame or JInternalFrame. I could do my own lame D&D but I'm tired of giving up functionality! ]]>
- When I gave up dialog modality, a new set of problems arose. Now the SDT returns as soon as the popup is visible, and the popup is coded to be disposed when a keystroke is seen or mouse click changes focus. The keystroke that fires off the Live Rearranger action (in my case, Alt-R) is queued until after the Swing thread returns from generating the popup. Suppose I press and release Alt-R. First thing my popup sees is the key release, and hides & disposes the popup. There's no timestamp with the keystroke, so no way to know if the key was really released before the popup appeared or not. (I don't know of a way to drain the keyboard events from the Swing queue.) If I keep the Alt-R keys pressed, autorepeat kicks in and fires off zillions of plugin calls! :) I've set a flag that indicates if a previous call is in progress, but maybe there's a way to disable autorepeat temporarily. Will look.
Mostly I just wanted to blow off steam. Still working on it. Thanks! -
Dave
I think letting go of AltR should only close the window if the user has rearranged something. If I press AltR, hold it for 5 seconds, then release it, without doing anything else, I think it's reasonable to keep the dialog on the screen.
You probably want to bind the key to something else - on Linux under most window managers, holding Alt and dragging the mouse in a window does not pass the mouse event to the window at all, but instead drags that window, as if you had clicked on the titlebar and dragged that. This makes the default Alt+R keyrelease-closes-window behavior impossible to use for most Linux and Unix users.
I think the flag thing to deal with autorepeat is fine.
I think when the user is in the Live Rearrange window, another Alt+R should close the window, along with Esc and possibly Spacebar (it's easy to hit, the point of Live Rearrange is to be quick).
The auto-repeat is a "Will not fix" bug on the Java Bug Parade: http://developer.java.sun.com/developer/bugParade/bugs/4274879.html
It says that on Unix/Linux, key events are sent by X without any indication of whether they are autorepeated or not, so there's no way for AWT to know.
Dave,
I'm sure you've already thought of this, but have you tried a JWindow yet?
It has no window decorations and doesn't appear in the task bar, plus
tooltips seem to work fine with it. I can send you some sample code if you
need it.
Hope that helps,
Vil.
Dave Kriewall wrote:
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
Just looked back over previous messages and noticed that you tried a
JWindow, but had a problem with it not receiving focusLost events. Rather
than adding a FocusListener to the window, you should be adding a
WindowFocusListener. That seems to work in my (simple) tests.
One of the things I like about Swing is its endless ability to surprise... ;)
Again, hope that helps.
Vil.
Vilya Harvey wrote:
--
Vilya Harvey
vilya.harvey@digitalsteps.com / digital steps /
(W) +44 (0)1483 469 480
(M) +44 (0)7816 678 457 http://www.digitalsteps.com/
Well, for the curious or masochistic Swing enthusiasts (Vil and/or Keith?), I ended up using a Popup. JWindow only seemed to receive "window focus lost" events when the entire IDEA app lost focus, but not when I clicked on the text editor area, for example.
Popups are manufactured as light, medium or heavyweight objects (but we have little control over which). I changed the root window to 'null' and I think I got a heavyweight popup as a result. Anyway, drag and drop works in the kind of popups I now have.
You can't register any listeners for a popup. All you can do is show() and hide() (and dispose()) it. Window focus lost events weren't helping me anyway. So now I find the IDEA WindowManager's suggested parent window, and add a mouse listener to the component of that window that has focus. Then I can tell if a mouse click occurs outside the popup. And I intercept all keystrokes once the popup is displayed so it can be disposed when a key release occurs.
I'm sure there's a way to do this all with a JWindow since a Popup is supposed to be implemented on top of a JWindow. I'll leave that as an exercise to the reader. :)
Anyway, Vil, I concur. Swing behavior and functionality is much less predictable than I naively expected!
-Dave
Keith,
Just wanted to let you know that your skeleton code for updating the progress bar works, and to thank you for it. I'll upload a new version today (based on it) which rearranges contents of directories.
It seems strange to me that the only real purpose of the additional thread is to be able to call SwingUtilities.invokeAndWait() to force the SDT to empty its event queue and catch up on any painting that needs to be done. As you noted, all the work of the plugin is being done on the SDT. Couldn't Sun just add a method like invokeAndWait() which can be called by the SDT? Then an additional thread wouldn't be necessary.
Thanks again,
-Dave