You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by frederic <fr...@ancestris.org> on 2018/05/01 15:54:28 UTC
Re: Bug in Netbeans for MacOS
Geertjan,
Thanks for your message.
(I have moved this discussion to dev@).
To respond to your question, I want to let all the TopComponents of the
application know that the selection in one module has changed. The use
of an ExplorerManager in all top components and setSelectedNodes
sounded like an easy and legitimate way. If there is another way, happy
to be pointed to the right direction.
In any case, the specific added code for MacOS in MainWindow.java
prevents numerous calls of setSelectedNodes. Whether I find another
solution for my application, it might still be necessary to fix it,
doesn't it ?
Best regards,Frederic
Le mardi 01 mai 2018 à 17:40 +0200, Geertjan Wielenga a écrit :
> On Tue, May 1, 2018 at 5:33 PM, frederic <fr...@ancestris.org>
> wrote:
> > Hi Efrem, Thomas,
> >
> > Thanks for you replies.
> >
> > The application is Ancestris, but it does not matter much which
> > application is running netbeans. I have spent quite ssome time
> > finding the bug. The crash is generated after several calls to
> > "ExplorerManager.setRootContext()" or
> > "ExplorerManager.setSelectedNodes()". After about 20 to 100 calls,
> > it creates the bug.
> >
> > What I am trying to do:
> > - I have a TopComponent with a simple ExplorerManager in it, which
> > holds the context.
> > (associateLookup(ExplorerUtils.createLookup(manager, map));)
> > - Each time the user changes the selected element, I run an
> > ExplorerManager.setRootContext() and
> > ExplorerManager.setSelectedNodes().
>
> But why do you need to do that? That seems to be causing some kind of
> race condition or blocker of some kind and you probably need to solve
> whatever the situation is in a different way.
> Gj
>
>
>
> > - On Linux, no problem for any number of changes- On MacOS,
> > computer slows down after about 20 to 100 selections, Then it
> > crashes.
> > I have checked the source code of MainWindow.java in
> > package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and
> > 8.2 : they all have the same code, therefore the same bug.
> > If you want to check on 9.0, just check the MainWindow code. Can
> > you show it to us please, see if it has the same call under
> > resultChanged() ?
> > (Otherwise, not sure we can test with my application on 9.0, it has
> > not been converted yet to NB9.0.)
> > Tom, if I cannot have support on 8.0.1, maybe I can get support on
> > 8.2 ? Or else, can I get someone to tell me how to recompile the
> > following jar : "org.netbeans.core.windows.jar" ?
> >
> > Hope this adds more explanations.
> > Many thanks again.Frederic
> >
> >
> > Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
> > > Hi my name is Efrem. I am willing to test this with the new beta
> > > release of NB 9.0 on MacOS.
> > >
> > > I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen
> > > because
> > > of its age...
> > >
> > > If you can provide me the steps or source to test I am willing to
> > > test
> > > it today.
> > >
> > > What is the application and what are you trying to do?
> > >
> > > Please advise.
> > >
> > > Efrem McCrimon
> > > GUI Builder Tribe tester
> > > DB Tribe tester
> > >
> > >
> > >
> > > On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org>
> > > wrote:
> > > > Dear all,
> > > >
> > > > I have found a bug in Netbeans on MacOS which makes the
> > > > applications crash
> > > > on MacOS. I would like to know if it is possible to fix it in
> > > > Netbeans 8.0.1
> > > > or at least to make sure it is not in Netbeans 8.2.
> > > >
> > > > The bug :
> > > > ======
> > > >
> > > > I'm using Netbeans 8.0.1 for Ancestris. There seems to be a
> > > > conflicting
> > > > thread in MainWindow.java that compromises the removal of
> > > > lookup listeners.
> > > >
> > > > Therefore, if an updateLookup runs in the application, the
> > > > following thread
> > > > is activated which itself runs an updateLookup.
> > > >
> > > > The application ends up multiplying the number of listeners up
> > > > to several
> > > > tens of thousands and crashes on Mac.
> > > >
> > > > Here is the code with the bug: (in MainWindow.java in package
> > > > org.netbeans.core.windows.view.ui)
> > > >
> > > > if (Utilities.getOperatingSystem() == Utilities.OS_MAC)
> > > > {
> > > > //Show a "save dot" in the close button if a
> > > > modified file is
> > > > //being edited
> > > > //Show the icon of the edited file in the window
> > > > titlebar like
> > > > //other mac apps
> > > > saveResult =
> > > > Utilities.actionsGlobalContext().lookupResult
> > > > (SaveCookie.class);
> > > > dobResult =
> > > > Utilities.actionsGlobalContext().lookupResult
> > > > (DataObject.class);
> > > > if( null != saveResult && null != dobResult ) {
> > > > saveListener = new LookupListener() {
> > > > @Override
> > > > public void resultChanged(final LookupEvent
> > > > ev) {
> > > > RP.post( new Runnable() {
> > > >
> > > > @Override
> > > > public void run() {
> > > > updateMacDocumentProperties(ev);
> > > > }
> > > > });
> > > > }
> > > >
> > > > };
> > > > saveResult.addLookupListener(saveListener);
> > > > dobResult.addLookupListener(saveListener);
> > > > }
> > > > dobResult.allItems();
> > > > }
> > > >
> > > > The " updateMacDocumentProperties(ev)" includes :
> > > > - saveResult.allItems()
> > > > - dobResult.allItems()
> > > > which trigger an updateLookup as well, creating two threads
> > > > updating the
> > > > same lookups (removeListener, addListener).
> > > >
> > > >
> > > > The fix:
> > > > =====
> > > >
> > > > I would be ok to just replace :
> > > >
> > > > "Utilities.getOperatingSystem() == Utilities.OS_MAC"
> > > >
> > > > with
> > > >
> > > > "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
> > > >
> > > > because I do not think we need this on Mac in the Ancestris
> > > > application at
> > > > least.
> > > >
> > > > Can someone recompile the package with this fix and send it
> > > > back to me ? Or
> > > > else can someone help me fix it myself localy (I do not have
> > > > the code to
> > > > recompile this package) ?
> > > >
> > > >
> > > > Many thanks in advance if it can be done.
> > > >
> > > > Best regards,
> > > > Frederic
> > > >
Re: Bug in Netbeans for MacOS
Posted by Geertjan Wielenga <ge...@googlemail.com>.
It sounds like you should be using a LookupListener to listen for the
selected Node, see leanpub.com/nbp4beginners.
I don't think I've ever used setSelectedNodes and not needed it either.
I'd be very very careful about adding code into MainWindow.java, i.e., you
could end up changing behavior for all the applications that run on top of
the NetBeans Platform.
Gj
On Tue, May 1, 2018 at 5:54 PM, frederic <fr...@ancestris.org> wrote:
> Geertjan,
>
> Thanks for your message.
>
> (I have moved this discussion to dev@).
>
> To respond to your question, I want to let all the TopComponents of the
> application know that the selection in one module has changed. The use of
> an ExplorerManager in all top components and setSelectedNodes sounded like
> an easy and legitimate way. If there is another way, happy to be pointed to
> the right direction.
>
> In any case, the specific added code for MacOS in MainWindow.java prevents
> numerous calls of setSelectedNodes. Whether I find another solution for my
> application, it might still be necessary to fix it, doesn't it ?
>
> Best regards,
> Frederic
>
>
> Le mardi 01 mai 2018 à 17:40 +0200, Geertjan Wielenga a écrit :
>
>
>
> On Tue, May 1, 2018 at 5:33 PM, frederic <fr...@ancestris.org> wrote:
>
> Hi Efrem, Thomas,
>
> Thanks for you replies.
>
> The application is Ancestris, but it does not matter much which
> application is running netbeans. I have spent quite ssome time finding the
> bug. The crash is generated after several calls to
> "ExplorerManager.setRootContext()" or "ExplorerManager.setSelectedNodes()".
> After about 20 to 100 calls, it creates the bug.
>
> What I am trying to do:
> - I have a TopComponent with a simple ExplorerManager in it, which holds
> the context. (associateLookup(ExplorerUtils.createLookup(manager, map));)
> - Each time the user changes the selected element, I run an
> ExplorerManager.setRootContext() and ExplorerManager.setSelectedNodes().
>
>
>
> But why do you need to do that? That seems to be causing some kind of race
> condition or blocker of some kind and you probably need to solve whatever
> the situation is in a different way.
>
> Gj
>
>
>
>
>
> - On Linux, no problem for any number of changes
> - On MacOS, computer slows down after about 20 to 100 selections, Then it
> crashes.
>
> I have checked the source code of MainWindow.java in
> package org.netbeans.core.windows.view.ui for NB 8.01, 8.02, and 8.2 :
> they all have the same code, therefore the same bug.
>
> If you want to check on 9.0, just check the MainWindow code. Can you show
> it to us please, see if it has the same call under resultChanged() ?
>
> (Otherwise, not sure we can test with my application on 9.0, it has not
> been converted yet to NB9.0.)
>
> Tom, if I cannot have support on 8.0.1, maybe I can get support on 8.2 ?
> Or else, can I get someone to tell me how to recompile the following jar :
> "org.netbeans.core.windows.jar" ?
>
> Hope this adds more explanations.
>
> Many thanks again.
> Frederic
>
>
>
> Le mardi 01 mai 2018 à 09:33 -0400, Efrem Mc a écrit :
>
> Hi my name is Efrem. I am willing to test this with the new beta
> release of NB 9.0 on MacOS.
>
> I am running Mac OSX 10.11.6 on a Mac Mini which is OS frozen because
> of its age...
>
> If you can provide me the steps or source to test I am willing to test
> it today.
>
> What is the application and what are you trying to do?
>
> Please advise.
>
> Efrem McCrimon
> GUI Builder Tribe tester
> DB Tribe tester
>
>
>
> On Tue, May 1, 2018 at 7:24 AM, frederic <fr...@ancestris.org> wrote:
>
>
> Dear all,
>
> I have found a bug in Netbeans on MacOS which makes the applications crash
> on MacOS. I would like to know if it is possible to fix it in Netbeans 8.0.1
> or at least to make sure it is not in Netbeans 8.2.
>
> The bug :
> ======
>
> I'm using Netbeans 8.0.1 for Ancestris. There seems to be a conflicting
> thread in MainWindow.java that compromises the removal of lookup listeners.
>
> Therefore, if an updateLookup runs in the application, the following thread
> is activated which itself runs an updateLookup.
>
> The application ends up multiplying the number of listeners up to several
> tens of thousands and crashes on Mac.
>
> Here is the code with the bug: (in MainWindow.java in package
> org.netbeans.core.windows.view.ui)
>
> if (Utilities.getOperatingSystem() == Utilities.OS_MAC) {
> //Show a "save dot" in the close button if a modified file is
> //being edited
> //Show the icon of the edited file in the window titlebar like
> //other mac apps
> saveResult = Utilities.actionsGlobalContext().lookupResult
> (SaveCookie.class);
> dobResult = Utilities.actionsGlobalContext().lookupResult
> (DataObject.class);
> if( null != saveResult && null != dobResult ) {
> saveListener = new LookupListener() {
> @Override
> public void resultChanged(final LookupEvent ev) {
> RP.post( new Runnable() {
>
> @Override
> public void run() {
> updateMacDocumentProperties(ev);
> }
> });
> }
>
> };
> saveResult.addLookupListener(saveListener);
> dobResult.addLookupListener(saveListener);
> }
> dobResult.allItems();
> }
>
> The " updateMacDocumentProperties(ev)" includes :
> - saveResult.allItems()
> - dobResult.allItems()
> which trigger an updateLookup as well, creating two threads updating the
> same lookups (removeListener, addListener).
>
>
> The fix:
> =====
>
> I would be ok to just replace :
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC"
>
> with
>
> "Utilities.getOperatingSystem() == Utilities.OS_MAC & false"
>
> because I do not think we need this on Mac in the Ancestris application at
> least.
>
> Can someone recompile the package with this fix and send it back to me ? Or
> else can someone help me fix it myself localy (I do not have the code to
> recompile this package) ?
>
>
> Many thanks in advance if it can be done.
>
> Best regards,
> Frederic
>
>
>
>