Thu 26 May 2016 12:01:15 AM UTC, comment #8:
Fixed on the default branch, thank you for your contribution to Octave!
http://hg.savannah.gnu.org/hgweb/octave/rev/895971cb50f0
|
Wed 25 May 2016 05:30:48 PM UTC, comment #7:
Thanks a lot, Mike, for your review. Updated patch is pasted here. Apropos the crediting for the patch, I don't mind either way.
|
Wed 25 May 2016 03:59:54 PM UTC, comment #6:
Forgot to answer, the isguirunning() is not redundant because the user might have built Octave with the Qt GUI but without Java support, or vice versa. If you look further into listdlg.m there are two implementations depending on whether the Qt GUI is available or whether Java is available.
|
Wed 25 May 2016 03:49:05 PM UTC, comment #5:
I was thinking along the same lines as Atri, create an object to prove that it can be instantiated. Because most likely the user is going to instantiate such an object immediately after anyway.
But yes if Java offers a platform-independent way to check whether the environment has a graphical capability, that looks good to me.
Can you throw that test into the "swing" case as well? I don't think the comments are actually necessary, it seems pretty self-explanatory. And can you add a space between the function call "javaMethod" and the opening parenthesis?
Would you like to be credited with your name and email address for this patch?
|
Wed 25 May 2016 02:48:02 PM UTC, comment #4:
Hi Philip,
Thanks for your comments. I see your point, so one could try something like the patch pasted here. But at least in the context of the check for menu.m, wouldn't this make the first condition in menu() redundant? I mean the
part of the check in menu() should not be needed any more, as the other check
will already ensure this for us.
Otoh, my previous patch ensures that you can actually create awt objects, which seems like a more ideal test for usejava's usecase. So pros and cons...
What do you think?
|
Wed 25 May 2016 10:22:16 AM UTC, comment #3:
When I wrote usejava.m I choosed to call 'methods ("Java object")' to avoid creating Java objects that could be lingering on and occupy resources. I'm not sure Java objects get deleted when they get out of scope.
Isn't there a Java method that checks for a graphical display? that would be superior.
googling for "Java check graphical display" does turn up some interesting answers.
|
Wed 25 May 2016 07:04:07 AM UTC, comment #2:
Scratch the previous patch (file #37254), the proper patch is attached here (no need to use nested try catch blocks). At the moment, I am only testing if awt objects can be instantiated because that is what menu() checks [usejava("awt")]. If a similar thing needs to be done for usejava("swing"), which at present I am not sure it does, then I can take a shot at it as well later.
(file #37256)
|
Wed 25 May 2016 02:40:49 AM UTC, comment #1:
Confirmed, this is because menu checks
and the check is succeeding even when it is not possible to use AWT widgets because there is no graphical environment.
I wonder if usejava("awt") and usejava("swing") should return false if the widgets can't actually be instantiated because there is no X environment available. Matlab's help for usejava is not particularly insightful, but I think that would make the most sense.
Would you like to submit a patch to fix this?
|
Wed 25 May 2016 02:20:32 AM UTC, original submission:
Open a terminal on a system without X and try to run
This gives an error:
This is contrary to what the documentation for menu() says:
If the GUI is running, or Java is available, the menu is displayed graphically using 'listdlg'. Otherwise, the title and menu options are printed on the console
|