Community
Participate
Working Groups
Build 20040318 Linux-GTK The "Open Log" button on the Error Log view and the dialog that appears when exceptions are logged "Would you like to open the log now?" don't work. When I click the view's button or click Yes in the dialog, nothing happens.
Cherie, please investigate.
I've tried to add on 2 solutions for linux: 1. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/snippits/snippet30.html which involves Program p = Program.findProgram(".txt"); if (p!=null) p.execute(logfile.getAbsolutePath()); and 2. IBrowser browser = BrowserManager.getInstance().createBrowser(); try { browser.displayURL(logfile.getAbsolutePath()); } catch (Exception e) { } Unfortunately, both have no effect on Motif and the recent GTK builds aren't launching correctly (tried on SuSE and RH) :( Seeking suggestions pending attempting other solutions :)
What Linux-GTK builds are you trying? I've been using all the integration builds just fine.
I was trying the I0318-1131 and I0322-0800 gtk builds using the sun's and the newest sanctioned jdk1.4.2 but both of these wouldn't even allow me to launch. (was using suse and red hat 8.0 I believe). Eventually moved to motif builds which let me play. :) Odd that I wouldn't be able to launch these GTK builds though since I've never had problems with GTK builds before. As for my last statement, using the browser manager will likely work (was experimenting after I commented) but will create an extra dependence on o.e.help.base and I'm trying to keep pde.runtime as light as possible :(
Grant Gayed wrote: I just tried it and it works for me, so I have two guesses: - You're running under kde. This doesn't work. Try under gnome. - There isn't a Display instance when Program.launch(...) is invoked. This can usually be safely assumed, but since I don't know your context, you can invoke Display.getDefault() before Program.launch(...) to ensure this. If these don't help... What's the program you're trying to launch? What linux distribution are you using?
I'm testing this function on Gnome on RH Linux 8 with latest sanctioned 1.4.2 jdk and am still having problems. Thus, moving onto your second point, perhaps there isn't a display instance. I tried three things: 1. Display display = Display.getDefault(); display.asyncExec(new Runnable() public void run(){ Program.launch(inputFile.getAbsolutePath()); } }); 2. BusyIndicator.showWhile(tableTreeViewer.getTableTree().getDisplay(), new Runnable(){ public void run(){ Program.launch(inputFile.getAbsolutePath()); } }); 3. Runtime.getRuntime().exec("/usr/bin/less " + inputFile.getAbsolutePath()); Unfortunately, neither of these produced results on today's GTK integration build. :( Would you be able to tell me what I'm doing wrong?
Cherie, I think the problem here is that the file you are trying to open has a ".log" extension, and the OS does not have a program registered with this extension. What you should try is to find the program associated with ".txt" and use it to open the .log file.
Already tried that per Comment#2 :(
Sorry, Grant -- going online with our conversation from earlier :) Grant Gayed wrote: If java's Runtime.exec(...) doesn't work for you either then it's not a problem with Program, but with the argument you're passing. Possibilities to consider: - does inputFile represent an executable? - does the file definitely exist where getAbsolutePath() claims that it does? - do you have execute permission on the file?
Hi Grant, It's only a log file so it doesn't represent an executable. :( For that function to be available, the getAbsolutePath() file must exist so no worries here :) I even check to make sure the function is there and 'less' it in an xterm window to make sure. By default, .log access is only -rw-rw-r-- but I changed chmod to 777 and tried it again with the same (non-existent) results :( Am I off somewhere here? Yours, Cherie.
OK, there seems to be a problem when the file being launched isn't an executable, as Program isn't realizing that it's running on gnome. I'll ask Chrix about this when he gets in (soon).
Hi Cherie, Would it be preferable to have the "open log" button open the log file in an Eclipse text editor? Using the Program.launch API triggers different results based on the extension of the .log file. There is not always a registered system viewer on certain platforms for the particular type. As a result it is best to avoid calling the Program API and prefer the existing Eclipse text editor. It is less random and in that particular case probably more convenient than having OpenOffice showing up as it does on my linux box... Regarding the specific issue with Program.launch: bug 56144 is capturing this.
Christophe's suggestion is reasonable (and preferable). Please open the log file in an Eclipse text editor.
What if the exceptions are caused by something editor-related? :-)
;-) That was my question too. But, code will fail in the runtime launch and the hope is that we'll open the log in the host launch's text editor. If that fails too then you probably didn't write the error-possessed code in the first place and we'll blame it on some intern :-D
Jared makes a good (and humorous) point. But it's better than the current option where you get nothing. I think TextEditor has matured enough over the years to be dependable in this situation. If it fails to open in rare cases, you can still see individual entries in the event details dialog, so you're not totally left in the dark. Cherie, your rebuttal to Jared's point does not apply in this case. It only applies in the other instance where we call Program.launch(..). The instance being when you launch a runtime workbench and fails with exit code 13. In this case, PDE tells the user that there is a log and offers to open it for them. Here we can open the log of the runtime workbench in an editor in the host platform. We currently open it with Program.launch(..), so on gtk, you will get nothing. This is the more serious problem.
On second thought, regarding comment #12, opening the log in an Eclipse text editor is not a desirable option. This will make the lightweight and RCP- friendly org.eclipse.pde.runtime plugin depend on plugins like org.eclipse.ui.ide and org.eclipse.core.resources. This is a hefty price to pay just for this functionality. Cherie, I therefore recommend doing the following: Plan A: call Program.launch() on the file. If this fails (i.e. returns false), then Plan B: print the contents of the log file into a dialog much like the dialog you would see in Help >About Eclipse Platform >Configuration Details dialog.
The (slightly) revised solution is that instead of automatically using a dialog solution for non-Win32 platforms, we will test for a default external text editor first. If one exists, use it. Else, dialogs are all the rage. Tested on SuSE and RH Enterprise this morning :-) if (SWT.getPlatform().equals("win32")) //$NON-NLS-1$ Program.launch(inputFile.getAbsolutePath()); else { Program p = Program.findProgram (".txt"); //$NON-NLS-1$ if (p != null) p.execute (inputFile.getAbsolutePath()); else { OpenLogDialog openDialog = new OpenLogDialog(tableTreeViewer.getControl().getShell(), inputFile); openDialog.create(); openDialog.open(); } }
