jedit-devel Mailing List for jEdit

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
>>
>>
>>
>>
>>
>>     
>
>   

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
>
>
>
>
>

I think if there was no previous support for this in the core, it would be
better to put it in the LnF plugin. But now that it's been in the core for a
long time, and users have been using it, would you move it from the core?

Shlomy

On Sun, Jul 31, 2011 at 5:44 PM, Dale Anson <da...@gr...> wrote:

> Does this functionality even need to be in jEdit core? It would be a simple
> matter to add Nimbus and Metal look and feels to the Look and Feel plugin.
>
> Dale
>
>
> On Sat, Jul 30, 2011 at 9:34 PM, Shlomy Reinstein <sre...@gm...>wrote:
>
>> 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...>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...> 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...>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
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

About the exception when starting with Nimbus I got, this has nothing to
do with BufferTabs.
Do

        if (isStartupDone())
        {
            for (Window window : Window.getWindows())
            {
                SwingUtilities.updateComponentTreeUI(window);
            }
        }

instead of

        for (Window window : Window.getWindows())
        {
            SwingUtilities.updateComponentTreeUI(window);
        }

to prevent that exception. On startup it is not necessary and causes
this exception with Nimbus.

Vampire schrieb:
> Most probably something that shows tabs, as you get an exception from a
> TabbedPaneUI.
> As it is from a SynthTabbedPaneUI it seems to be at least a similar
> problem to that of BufferTabs. Because Nimbus is based on Synth and the
> TabbedPaneUI of Nimbus is the Synth one. So it seems also in this case
> you have some component that still has a Nimbus UI while you already
> switched to Metal or something like that.
>
> Vampire schrieb:
>   
>> 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...>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...> 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...>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
>>>>>>
>>>>>>
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>>>>   
>>>>     
>>>>       
>>>>         
>>>   
>>>     
>>>       
>>   
>>     
>
>   

Most probably something that shows tabs, as you get an exception from a
TabbedPaneUI.
As it is from a SynthTabbedPaneUI it seems to be at least a similar
problem to that of BufferTabs. Because Nimbus is based on Synth and the
TabbedPaneUI of Nimbus is the Synth one. So it seems also in this case
you have some component that still has a Nimbus UI while you already
switched to Metal or something like that.

Vampire schrieb:
> 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...>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...> 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...>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
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>   
>>>     
>>>       
>>   
>>     
>
>   

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...>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...> 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...>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
>>>>
>>>>
>>>>       
>>>>         
>>   
>>     
>
>   

No matter where you add the functionality, the issue that BufferTabs is
working against an on-the-fly LnF change remains.
The functionality in core is also there already more or less.

Dale Anson schrieb:
> Does this functionality even need to be in jEdit core? It would be a simple
> matter to add Nimbus and Metal look and feels to the Look and Feel plugin.
>
> Dale
>
>
> On Sat, Jul 30, 2011 at 9:34 PM, Shlomy Reinstein <sre...@gm...>wrote:
>
>   
>> 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...>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...> 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...>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
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
>>
>>     
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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

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...>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...> 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...>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
>>>
>>>
>>>       
>
>   

Does this functionality even need to be in jEdit core? It would be a simple
matter to add Nimbus and Metal look and feels to the Look and Feel plugin.

Dale


On Sat, Jul 30, 2011 at 9:34 PM, Shlomy Reinstein <sre...@gm...>wrote:

> 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...>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...> 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...>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
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>

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...>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...> 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...>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
>>
>>
>

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...> 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...>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
>
>

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...>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

Merge Requests item #3383016, was opened at 2011-07-30 14:03
Message generated for change (Tracker Item Submitted) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1235750&aid=3383016&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: for 4.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Merge 19720 - MiscUtilities.expandVariables fix

Initial Comment:
Currently expandVariables does not recognize %varname% on windows
but with rev19720, it can now reverse what MiscUtilities.abbreviate() does.

You can test expandVariables by entering var compressed paths in the file system browser to see how they expand on various platforms.

suitable for 4.4 and 4.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1235750&aid=3383016&group_id=588

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...>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
>

Plugin Bugs item #3382969, was opened at 2011-07-30 20:39
Message generated for change (Tracker Item Submitted) made by jarekczek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382969&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Czekalski (jarekczek)
Assigned to: Nobody/Anonymous (nobody)
Summary: SideKick Code Completion hangs badly on .length

Initial Comment:
I was editing TextToolsComments.java, adding a line:

if (textArea.getSelection().length==0)

I couldn't finish. Before I type = (after "length") jedit hangs without any reactions to input. There's nothing left but killing it.

I can type this hard line if "Show completion popups where possible" is turned off.

Today's svn, linux, debian, openbox.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382969&group_id=588

Plugin Feature Requests item #3382965, was opened at 2011-07-30 20:30
Message generated for change (Tracker Item Submitted) made by jarekczek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3382965&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Jarek Czekalski (jarekczek)
Assigned to: Nobody/Anonymous (nobody)
Summary: TextTools: toggle line comment - move down

Initial Comment:
Hi all

That's my first submission to this great project. The idea is taken from Edit Pad Pro which was my editor under linux (wine) until today :)
After toggling a line comment the cursor should move down. That's very convenient. So I introduce such an option. Patch attached.

The caret is not moved if any is true:
1. something is selected
2. we're at the last line

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3382965&group_id=588

Plugin Feature Requests item #3381350, was opened at 2011-07-28 23:47
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381350&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: lucene - autoexpand new results, unexpand old results

Initial Comment:
I want to use lucene without a mouse. But i have to expand every single tree node in the search results tree.
I think lucene should expand them all automatically. Especially when you have "single results" mode.

Speaking of that, it would be nice if lucene would remember my preference for multiple or single results. 


----------------------------------------------------------------------

>Comment By: Shlomy Reinstein (shlomy)
Date: 2011-07-30 21:19

Message:
Implemented in SVN rev 19716 of LucenePlugin.
Also need to fetch the new version of MarkerSets from Git.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2011-07-30 20:04

Message:
pref for single/multiple results is now persistent, so only tree stuff
remains...

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2011-07-29 23:06

Message:
When using it with  multiple results, if this option is on, the previous
results should be un-expanded also 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381350&group_id=588

Plugin Bugs item #3382947, was opened at 2011-07-30 19:15
Message generated for change (Tracker Item Submitted) made by jarekczek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382947&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jarek Czekalski (jarekczek)
Assigned to: Nobody/Anonymous (nobody)
Summary: TextTools: toggle line comment of last line throws exception

Initial Comment:
If the last line of a file is empty and we try to comment it (TextTools, Toggle Line Comment), we get an exception:

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 16026
	at org.gjt.sp.jedit.buffer.JEditBuffer.getLineOfOffset(JEditBuffer.java:336)
	at org.gjt.sp.jedit.buffer.JEditBuffer.getRuleSetAtOffset(JEditBuffer.java:1756)
	at org.gjt.sp.jedit.buffer.JEditBuffer.getContextSensitiveProperty(JEditBuffer.java:1791)
	at org.gjt.sp.jedit.Buffer.getContextSensitiveProperty(Buffer.java:1069)
	at TextToolsComments.toggleLineComments(Unknown Source)
        ... rest not important I guess

Today's svn.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382947&group_id=588

Plugin Feature Requests item #3381350, was opened at 2011-07-28 13:47
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381350&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
>Summary: lucene - autoexpand new results, unexpand old results

Initial Comment:
I want to use lucene without a mouse. But i have to expand every single tree node in the search results tree.
I think lucene should expand them all automatically. Especially when you have "single results" mode.

Speaking of that, it would be nice if lucene would remember my preference for multiple or single results. 


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2011-07-30 10:04

Message:
pref for single/multiple results is now persistent, so only tree stuff
remains...

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2011-07-29 13:06

Message:
When using it with  multiple results, if this option is on, the previous
results should be un-expanded also 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381350&group_id=588

Plugin Bugs item #3382322, was opened at 2011-07-29 10:29
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382322&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
>Assigned to: Alan Ezust (ezust)
Summary: LucenePlugin: SearchResults Opens buffers in wrong view

Initial Comment:
I had lucene search results open, and I had another plain view open.
I assumed lucene would open buffers in the same view as the dockable, but 
it opens them in the other view.

And what's really bizarre is after I close the view, then Lucene can't open buffers at all anymore.


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2011-07-30 09:59

Message:
committed # 19714

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382322&group_id=588

Feature Requests item #2557712, was opened at 2009-02-02 18:55
Message generated for change (Comment added) made by vampire0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2557712&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Edit mode
Group: None
Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Kevin Hunter (hunteke)
Assigned to: Nobody/Anonymous (nobody)
Summary: syntax highlighting decision able to use entire path

Initial Comment:
Convention is starting to pull away from using just an extension or first line globs as indicators of what type of file it is.  As an example, reference Debian's use of filesystem placement as a measure of what they should be:

Anything in /etc/apache2/sites-available/ or /etc/apache2/sites-enabled/ should all be httpd conf files.

However, jEdit currently only recognizes files that end with 'httpd.conf'.

Reference email thread on lists:

Date: Sun, 17 Aug 2008 01:53:35 -0400
Subject: syntax highlight: apache conf
To: jEdit Dev List <jedit-devel@...>
From: Kevin Hunter <hunteke@...>

----------------------------------------------------------------------

>Comment By: Björn Kautler (vampire0)
Date: 2011-07-30 18:12

Message:
How would exisiting globs need to be fixed, what would be needed to be
changed?
Shouldn't the existing globs still match if they are matched against the
whole path, except if they didn't include a leading wildcard?
What else would be problematic / would need to be changed in existing
globs?

I'm strongly against a change of meaning if existing globs need to be
adapted. The shipped globs would be easy to change, but all custom globs by
users, in tutorials, in examples in modefiles etc. would be invalid also
and I don't think this would be feasible. If there is no way to do this
backwards compatible I think an additional option could be introduced. But
I'm also sure this can be done in a backwards compatible manner.

If the problem described above is the only one, I think the following
algorithm / rules should work fine, also backwards compatible:

- path separator in mode file is always forward slash
- if glob contains a forward slash, just match it against the full path
- if glob contains no forward slash, prefix the regex that results from
the glob when reading the mode file with "(?:.*/)?"
- replace the forward slashes when reading the mode file with
File.SEPARATOR or how the constant was named

This should add the ability to also match on the full path while no change
to existing globs is necessary.
At least if really the problem I mentioned is the only one. If not, what
else would be problematic / would need to be changed?

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2011-07-28 18:40

Message:
it looks like my commit was bad. Changing what filename glob means is not
an option. Dale and I will have to roll back our recent changes. Leshij, do
you want to submit your patch?


----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2011-01-13 03:55

Message:
Committed rev# 19190 to address this in jedit 4.5.
Will also try to get it accepted in 4.4.x


----------------------------------------------------------------------

Comment By: Kevin Hunter (hunteke)
Date: 2009-06-23 21:54

Message:
Heh, you know I would like it.  Mind filing that patch?

----------------------------------------------------------------------

Comment By: Denis Dzenskevich (leshij)
Date: 2009-06-22 17:05

Message:
Hello. I faced the same problem when tried to distinguish log files of
various apps. I implemented this feature in jEdit (full pathname match in
addition to filename). Does anyone need it? If so, I will file a patch.

----------------------------------------------------------------------

Comment By: Kevin Hunter (hunteke)
Date: 2009-02-06 21:46

Message:
Yes, I'm referring to the concept of deciding how to syntax highlight a
file.  I think jEdit does refer to it as edit mode.

A quick gander at jedit/Mode.java suggests to me that the current method
is mainly a regex on the basename of the file.  Why not just do a regex on
the entire filename, inclusive of the dirname and basename?

Then, for user accessible configuration, it's a matter of making a dialog
in Global Options, like "Mode Detection".  It would basically be a thin
veneer around ~/.jedit/modes/catalog : a 3 column dialog with the mode
file, the glob, and the name.  All fields editable, with a reset-to-default
button.

If a user changes a default, a new entry gets upserted into
~/.jedit/modes/catalog .  If the user reverts to a default, the associated
entry in ~/.jedit/modes/catalog gets removed.

Finally, it's a matter of updating the master catalog file, perhaps by
distribution, to "do the right thing."  (Match by full pathname, by
extension, whatevs.)

----------------------------------------------------------------------

Comment By: Shlomy Reinstein (shlomy)
Date: 2009-02-06 16:54

Message:
That's a very good point. Do you have a suggestion how to let users
configure file types? (BTW, I suppose you're referring to edit modes, as I
don't think there's any "file type" term in jEdit. Right?)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350588&aid=2557712&group_id=588

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

Plugin Feature Requests item #3381170, was opened at 2011-07-28 19:53
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381170&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: tvojeho (tvojeho)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: BufferTabs: option for tabs in single row, scrollable

Initial Comment:
Hi, I'd like to ask for this feature as many rows of buffer tabs decrease the the space of text area. Maybe it could even be a customizable number, e.g. 2 rows of tabs max.

tvojeho

----------------------------------------------------------------------

>Comment By: Shlomy Reinstein (shlomy)
Date: 2011-07-30 08:12

Message:
Implemented in SVN rev. 19711.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381170&group_id=588

Plugin Feature Requests item #3381350, was opened at 2011-07-28 13:47
Message generated for change (Comment added) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381350&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: lucene - autoexpand search results

Initial Comment:
I want to use lucene without a mouse. But i have to expand every single tree node in the search results tree.
I think lucene should expand them all automatically. Especially when you have "single results" mode.

Speaking of that, it would be nice if lucene would remember my preference for multiple or single results. 


----------------------------------------------------------------------

>Comment By: Alan Ezust (ezust)
Date: 2011-07-29 13:06

Message:
When using it with  multiple results, if this option is on, the previous
results should be un-expanded also 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3381350&group_id=588

Plugin Feature Requests item #3382428, was opened at 2011-07-29 13:05
Message generated for change (Tracker Item Submitted) made by ezust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3382428&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Alan Ezust (ezust)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console - Favorite Shell option

Initial Comment:
From Plugin Options - Console - General, there should be a combobox selector that lets you pick your favorite shell from the list. 

One of the options could be "remember last chosen shell".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3382428&group_id=588