Improve the algorithm for decision about the preferred PDF viewer on Unix-like systems (except Mac OS).
1) Try to find xdg-open (in /usr/bin, /usr/local/bin, possibly in the whole PATH)
2) If xdg-open was found, run: xdg-open <filename>
If the execution was successful, finish.
3) Try to detect whether the current GDM is Gnome or KDE:
- Gnome: system variable GNOME_DESKTOP_SESSION_ID is defined
- KDE: system variable KDE_FULL_SESSION is defined
4) If Gnome or KDE is detected, try one or more predefined PDF viewers
(again, try to find them in /usr/bin, /usr/local/bin, possibly in the whole PATH)
- Gnome: evince, ggv
- KDE: kpdf, kghostview
If the execution is successful, finish.
5) Try to find some other PDF viewer (in /usr/bin, /usr/local/bin, possibly in the whole PATH):
- acroread, xpdf
This enhancement would be implemented in file
Would going the JDK6 Desktop.getDesktop() route be an acceptable solution in this case? The file open support there does very good detection on my Linux systems, presumably also on Windows.
I believe that Tim Sparg is going to work on this issue for the First Patch program, with the help of Tushar Joshi. But in response to Ernest's question of 15 August, yes, I think the Desktop API is probably the best solution.
I imagine that the reason it was not originally developed this way is because the Desktop API was introduced in JDK 6, but the IDE still had to support earlier versions of the JDK. However, that is no longer a concern because JDK 6 or higher is required for current versions of NetBeans:
Here is a helpful article on the Desktop API:
I agree with TomWheeler, the Dektop API looks to be a valid replacement for the logic that looks up the PDF-Viewer
I see 2 ways of accomplishing this
1) rewrite the open() method of PDFOpenSupport so that it jus wraps the call to Desktop.open()
2) doing the above and falling back on the old code if the Desktop.open() call fails
I think that the first option is much cleaner, it allows you to remove alot of code that exists to support the implementation of the searching logic.
I also think that the first option is the right one, as it is much simpler and
Tim, it would be great if you could provide your patch.
In addition to Tom, email@example.com and firstname.lastname@example.org I also agree that using Desktop API from Java SE 6 is the most standard and platform independent way of making this happen.
Tim, try implementing the first option in your local environment and send me the patch and I will help you test the fix on platforms like Mac OS X Lion, Windows 7 and Ubuntu 11.04
Created attachment 110940 [details]
OpenPDF using Desktop functionality
I've created the patch as per the suggestions above (Using the built in Desktop.open() functionality).
If there are any changes required please let me know and I will amend the patch
Thank you very much, Tim. I am going to apply your patch.
In response to Comment #7
I have checked this patch and verified the functionality on Max OS X Lion and WIndows 7. I found this patch working as expected on these platform.
On Mac - PDF opens in Preview app
On Windows 7 - PDF Opens in system PDF viewer, in my case Foxit reader
I also tried simulating the error condition by making conditions of PDF file on Mac as 000 and it shows error in a dialog.
Tushar Joshi, Nagpur
Thank you, Tim.
Thank you, Tushar.
Great job! We really appreciate your helpful contribution.
Now the code is clean and simple - exactly as it should be.
I only slightly changed the patch to avoid using deprecated class NotifyDescriptor.Exception.
Verified on Windows 7 and Ubuntu Linux 11.04. Works well.
In response to Comment #11
Wow! Thanks Jarda for this quick turnaround.
Tim here goes your blood into the veins of NetBeans IDE now, congrats.
Works on Ubuntu 10.04 / GNOME - opens evince as expected.
Integrated into 'main-golden'
User: Jaroslav Havlin <email@example.com>
Log: #119629 - Improve detection of the preferred PDF viewer