From: Vampire <Vampire@jEdit.org> - 2011-08-01 10:19:47
|
You still didn't read the mail I mentioned, did you? To prevent further misunderstandings I'll quote it here again: [quote] 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 [/quote] 2011/8/1 Shlomy Reinstein <sre...@gm...>: > Ok, I just tried it, and now I understand what you meant. As it was written, > I thought there was only an "if" statement to add somewhere to eliminate an > exception on startup (which I didn't have). Now I see that this code for > updating the component tree (which I assumed that existed, according to your > email) is missing. > Adding this code now in initPLAF, the switch from metal to nimbus works > during runtime, but still does not work well. All the trees in the various > dockables suddenly appear with a very dark background (as if they are > selected), making them almost impossible to read. If I start with nimbus, > they don't look the same way, they appear normally, with white background. > Shlomy > > On Mon, Aug 1, 2011 at 12:32 PM, Vampire <Va...@je...> wrote: >> >> This is also what I refer to. >> Where I wrote about the exception when starting with Nimus, this was only >> about the addition of "if (isStartupDone()) {}". >> Please read my mail from 31.07.2011 00:37 GMT again. >> If you add that part (without the "if"), you will also get that exception >> when starting with Nimbus. >> >> Shlomy Reinstein schrieb: >> >> Hey, no reason to get angry... >> 1. You wrote "About the exception when starting with Nimbus I got, this >> has >> nothing to do with BufferTabs. ...". I never get any exception when >> starting >> with Nimbus, so I didn't need it. >> 2. What I wrote in the email was not related to starting with Nimbus. At >> runtime, after having using Metal for a while, I try to change to Nimbus, >> and I want to see it effective immediately in the current view. But I >> don't. >> The view's LnF changes to something that is neither Metal nor Nimbus, and >> no >> exceptions are thrown. New views and dialogs that I open are indeed in >> Nimbus, but the current view isn't, and this is what I referred to. >> >> Shlomy >> >> On Mon, Aug 1, 2011 at 11:03 AM, Vampire <Va...@je...> wrote: >> >> >> >> ** >> Then you didn't add >> >> if (isStartupDone()) >> { >> for (Window window : Window.getWindows()) >> { >> SwingUtilities. >> updateComponentTreeUI(window); >> } >> } >> >> as I said, did you? >> What do I write emails for? >> >> >> Shlomy Reinstein schrieb: >> >> The right thing would be to check with all dockables of all plugins. >> Fixing >> just my case won't fix it for others... >> But it doesn't work right even with '-noplugins'. At least for the current >> view, the new LnF does not look as it should. E.g. I change from Metal to >> Nimbus and I don't really see the Nimbus, only a strange combination of >> the >> two (for example, the scrollbars remain rectangle). Let's first get that >> working correctly, and then worry about the plugins. >> >> Shlomy >> >> On Mon, Aug 1, 2011 at 1:33 AM, Vampire <Va...@je...> >> <Va...@je...> wrote: >> >> >> >> ** >> 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...> >> <Va...@je...> <Va...@je...> <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...> <sre...@gm...> <sre...@gm...> >> <sre...@gm...> <sre...@gm...> <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...> <Va...@je...> <Va...@je...> >> <Va...@je...> <Va...@je...> <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...> >> <sre...@gm...> <sre...@gm...> <sre...@gm...> >> <sre...@gm...> <sre...@gm...> & >> lt;sre...@gm...> <sre...@gm...> <sre...@gm...> >> <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 >> >> >> >> >> >> >> >> >> >> >> >> ________________________________ >> >> ------------------------------------------------------------------------------ >> 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 >> > |