Re: [ jEdit-devel ] Changing L&F at runtime

I've tried with all but FoldTools and CppCheck as those are not
available in the plugin manager and I didn't see any problem.
But I guess it is also a matter of what Dockables are shown and with
what content etc.
If you try the plugins with a binary search algorithm you should have
the culprit within 4-5 tries.

Shlomy Reinstein schrieb:
> I got nearly 30 plugins. It'll take a while until I have the time to do
> enable one by one to see which causes the problem...
> The plugins:
> ActionHooks, BufferTabs, ClassBrowser, Code2HTML, CodeHelper, Completion,
> Configurable Fold Handler, Console, CppCheck, CtagsInterface, CtagsSideKick,
> DirtyGutter, ErrorList, FastOpen, FoldTools, Highlight, InfoViewer, JDiff
> Plugin, LucenePlugin, MarkerSets, MenuEditor, Navigator, ProjectViewer,
> QuickNotepad, SideKick, SuperAbbrevs, TaskList, Updater, Whitespace.
>
> Shlomy
>
> On Sun, Jul 31, 2011 at 7:07 PM, Vampire <Va...@je...> wrote:
>
>   
>> **
>> No, wait.
>> I've accidentally tested with the current BufferTabs release, not with the
>> fixed one from SVN.
>> With the fixed one and Nimbus I get one Exception on startup.
>> But the change to Metal works without any problem.
>> What other plugins do you have installed?
>> Try to disable all plugins and then enable one after the other and retest
>> to find out what plugins is causing this.
>>
>> Vampire schrieb:
>>
>> So this is a BufferTabs issue again.
>> I've tested with a clean jEdit, without plugins.
>> BufferTabs is not Nimbus friendly anyway, maybe BufferTabs is just too
>> much of a hack.
>> If you have Nimbus activated and try to change the Tab placement you get
>> NPE's also, without changing the LnF before.
>> And with BufferTabs enabled I also get NPEs when switching from Nimbus
>> to Metal LnF like you described. But only for existing Views. New Views
>> are showed fine in Metal LnF.
>>
>> Shlomy Reinstein schrieb:
>>
>>
>>  Also, here's the exception that is thrown after 3 (it is thrown many times):
>>
>> Exception in thread "AWT-EventQueue-0"
>> java.lang.NullPointerException
>>  at sun.font.FontDesignMetrics$MetricsKey.init(FontDesignMetrics.java:199)
>>  at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:267)
>>  at sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:942)
>>  at javax.swing.JComponent.getFontMetrics(JComponent.java:1599)
>>  at
>> javax.swing.plaf.synth.SynthTabbedPaneUI.getFontMetrics(SynthTabbedPaneUI.java:733)
>>  at
>> javax.swing.plaf.synth.SynthTabbedPaneUI.getFontMetrics(SynthTabbedPaneUI.java:729)
>>  at
>> javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneScrollLayout.calculateTabRects(BasicTabbedPaneUI.java:3131)
>>  at
>> javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateLayoutInfo(BasicTabbedPaneUI.java:2496)
>>  at
>> javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneScrollLayout.layoutContainer(BasicTabbedPaneUI.java:2900)
>>  at java.awt.Container.layout(Container.java:1421)
>>  at java.awt.Container.doLayout(Container.java:1410)
>>  at java.awt.Container.validateTree(Container.java:1507)
>>  at java.awt.Container.validateTree(Container.java:1513)
>>  at java.awt.Container.validateTree(Container.java:1513)
>>  at java.awt.Container.validateTree(Container.java:1513)
>>  at java.awt.Container.validateTree(Container.java:1513)
>>  at java.awt.Container.validateTree(Container.java:1513)
>>  at java.awt.Container.validateTree(Container.java:1513)
>>  at java.awt.Container.validate(Container.java:1480)
>>  at
>> javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:669)
>>  at
>> javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:124)
>>  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
>>  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
>>  at java.awt.EventQueue.access$000(EventQueue.java:84)
>>  at java.awt.EventQueue$1.run(EventQueue.java:602)
>>  at java.awt.EventQueue$1.run(EventQueue.java:600)
>>  at java.security.AccessController.doPrivileged(Native Method)
>>  at
>> java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
>>  at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
>>  at
>> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
>>  at
>> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
>>  at
>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
>>  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
>>  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
>>  at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>>
>> Shlomy
>>
>> On Sun, Jul 31, 2011 at 6:21 AM, Shlomy Reinstein <sre...@gm...> <sre...@gm...>wrote:
>>
>>
>>
>>
>>  Here's what I saw (Alan saw the exact same thing so I thought anyone
>> would):
>> 1. Change to Nimbus LnF.
>> 2. Restart jEdit. It should come up with Nimbus. (If it does not,
>> something's already wrong..)
>> 3. Change to Metal LnF.
>> After these steps, the view is almost unresponsive. Clicks in the menu bar,
>> text area etc do not do anything, or maybe trigger clicks in other places
>> (not where you clicked). You can't even open a new view using the mouse
>> because the menu bar is not responsive. If I am not mistaken, lots of
>> exceptions are thrown on the EDT, either immediately when you apply or as
>> soon as you try to do something with the view (like clicking menus).
>>
>> Shlomy
>>
>> On Sun, Jul 31, 2011 at 3:37 AM, Vampire <Va...@je...> <Va...@je...> wrote:
>>
>>
>>
>>
>>  **
>> Maybe it would help to say WHAT issues you see.
>> I've had a quick look and for me it seems to work quite well.
>> After you change the LnF new Views you open are with the new LnF
>> correctly.
>> Of course existing Windows and Dialogs are not changed correctly.
>> This has be triggered manually by doing
>>
>>         for (Window window : Window.getWindows())
>>         {
>>             SwingUtilities.updateComponentTreeUI(window);
>>         }
>>
>> which should work for all Windows, i. e. Frames, Dialogs, .... owned and
>> ownerless.
>> From a quick look there was only one quirk I've seen, which is with
>> background colors in JTree cell renderers of JTrees that are not newly
>> created.
>> But maybe there can be a work-around found for this.
>>
>> What other quirks did you see?
>>
>> Regards
>> Vampire
>>
>> Shlomy Reinstein schrieb:
>>
>> Please ignore that. There are still issues with changing L&F at runtime.
>> I've reverted my change.
>>
>> Shlomy
>>
>> On Sat, Jul 30, 2011 at 5:52 PM, Shlomy Reinstein <sre...@gm...> <sre...@gm...> <sre...@gm...> <sre...@gm...>wrote:
>>
>>
>>
>>  Hi,
>>
>> For a long time, jEdit didn't allow changing the L&F at runtime - so
>> changing the "lookAndFeel" property only had an effect on the next restart
>> of jEdit. If I am not mistaken, the reason for that was an exception that
>> was thrown when BufferTabs was used, which corrupted the painting (and
>> required a restart).
>>
>> Yesterday, Vampire found the reason for these exceptions from BufferTabs. I
>> fixed it in SVN (in BufferTabs), and added back the code to apply L&F
>> changes at runtime. Now it seems that changing the L&F at runtime works
>> fine. There is no exception and the changes effect jEdit immediately.
>>
>> I've committed my change to jEdit as well. Please try it, and let me know
>> if there are problems (in which case I'll revert my change).
>>
>> Thanks,
>> Shlomy
>>
>>
>>
>>    ------------------------------
>>
>> ------------------------------------------------------------------------------
>> Got Input?   Slashdot Needs You.
>> Take our quick survey online.  Come on, we don't ask for help often.
>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.http://p.sf.net/sfu/slashdot-survey
>>
>>
>>
>>
>>
>>     
>
>