I can't seem to drag and drop between available and selected encodings.
It never turns into a rectangle, it is always a red circle with a diagonal line over it.
This is new to 5.0pre1 - I can not reproduce this in 4.5.
If the first pane to show up when you go to global options is the encoding option pane, something is not initialized properly. Drag works, drop fails.
If you switch optionpanes before trying your first drag between pingponglists, then it works.
If you have any hint about this but, I'm interested.
I can reproduce it but have no idea of the reason.
I debugged, the canImport(JComponent comp, DataFlavor transferFlavors) method of my TransferHandler is not called when the bug happens,
but my TransferHandler is initialized and declared as transfer handler for the two lists.
When switching from and to the EncodingOptionPane the init() method has already been called so I don't see the difference.
Maybe the removeNotify() or something like that is called somewhere but I didn't found it.
Sorry ignore what I said about how I can not reproduce this in 4.5. That is not correct.
The steps to reproduce are the same. You must have that OptionPane open initially when you bring up the
Global Options. DnD doesn't work until you *switch* optionpanes to that one.
Alan, when the tabs are created, OptionGroupPane.valueChanged is fired in the order: global, plugins. So the last fired valueChanged is of plugins pane, although the visible one is of globals. I think that if changing of panes would generate valueChanged event, then all would work ok. Currently when you switch between tabs: global, plugins - valueChanged is not executed. Will you be able to work on it?
No. Even if I remove the plugins tab, the error still reproduces. So the problem probably lies somewhere else. It seems to have something to do with valueChanged, but not the way I thought.
Matthieu gave up. I don't think I'll try really hard to fix it. If you feel the same, Alan, you may just disable encodings as a startup pane. If it was the last one, let's don't see it. Comment it as a hack for this entry and that's it.
Slava's early commits sometimes come totally out of the blue. Like this mysterious:
described as "more updates to freemaker syntax highlighting, documentation updates" and updating 13 files.
I guess no-one will now know what was that workarounding. So we may remove it and wait until something happens, but it's likely that nothing will happen. In whole jedit code there are no calls to addNotify, and only overrides for it. AbstractOptionPane, being parent of OptionGroupPane, does not override it, so these 2 lines seem to have no effect on jedit.
Matthieu, you were saying about removeNotify. Maybe you understand why removing addNotify makes your ping-pong work well?
Below is suggested patch, but I think addNotify call should be also removed from OptionsDialog.
diff -r dd7bdc741590 org/jedit/options/OptionGroupPane.java
--- a/org/jedit/options/OptionGroupPane.java Sun Apr 15 16:37:37 2012 +0200
+++ b/org/jedit/options/OptionGroupPane.java Sun Apr 15 20:52:41 2012 +0200
@@ -208,9 +208,6 @@
- if (!isShowing())
currentPane = optionPane;
} // }}}
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.