|
This is all the terminal output from FDT (starting up an existing project, and compiling it pretty much immediately)
As for deleting the additional files, (I'm using a 32 bit computer, so I'm assuming the correct folder for me is linux32), I removed .SWFViewerCheck, but there was no data folder in either location, only swfViewer-linux.jar and swt-linux.jar.
Deleting that file made no difference (it still wouldn't display an external SWF window) and the terminal output was nearly identical to the previous output. As I have mentioned before, "fb4linux" works without any problems (and I'm assuming it uses a similar system for debugging), so I'm guessing the problem does not arise due to sealed off ports. I also had a previous version of FDT 3.5 Pure which ran without hickups. Thank you for your input. I think the problem boils down to this line:
[STDOUT]: Could not instantiate Browser: No more handles [Unknown Mozilla path (MOZILLA_FIVE_HOME not set)] The Browser could not be initialized since the path variable MOZILLA_FIVE_HOME is not set. http://www.eclipse.org/swt/faq.php https://www-304.ibm.com/support/docview.wss?uid=swg21271865 in short you can try to set: export MOZILLA_FIVE_HOME=/path/to/mozilla Please check also if the web browser inside of fdt (or eclipse) is working, since the External Swf Viewer uses the same. It seems like a setup problem with the XUL-Runner, but I am not quite sure. The internal web browser (as well as the welcome screen, which I'm assuming uses the same system) work just fine, even when debugging the SWF does not.
Regardless, the issue is resolved. After getting nowhere trying to properly set the MOZILLA_FIVE_HOME variable, I found a site which described how to install xulrunner http://www.samclarke.com/2011/11/how-to-install-aptana-studio-3-on-ubuntu-11-10-oneiric/ The debugger will now launch the SWF. I still had one problem though (but solved it), the debugger would never correct properly.
I had to download the latest Flash Player Debugger (found at http://www.adobe.com/support/flashplayer/downloads.html Just a side question, why does FDT use the flash player from xulrunner (or the whatever browser is used) rather than the debugger found in the SDK? Also, I realize now that this was an eclipse (not FDT) issue, but thank you for guiding me through to the solution. Andreas,
thanks a lot for doing this research and for sharing your findings! Your contribution is highly appreciated! regards, Philipp After a complete reinstall of Ubuntu 12.04 (32 bit) and using the latest FDT (I believe it is version 5.5 now, correct?) the problem has returned with the same error message of "MOZILLA_FIVE_HOME not set".
My previous solution won't work as "XUL-Runner" has a dependency on an older version of a library, and as the current version of that library is being used by other applications, I can't downgrade it. I'll try to find a different solution and report back if I find anything. However, the compiler works just fine; it's just the "External SWF Viewer" that's giving me problems. I can still debug and run the application using the following steps:
The last change has to be made to every new project you create, as FDT always defaults to debugging with "External SWF Viewer" for all new projects. Using that workaround, this bug can be changed from "Blocking" to "Major" or "Minor". More testing (or rather, re-trying things I had tested earlier).
I already have the up to date versions of FireFox and XULRunner installed on the system. I have tried setting MOZILLA_FIVE_HOME to both directories /usr/lib/mozilla/ and /usr/lib/xulrunner/ (separately, not at the same time). Both directories exist and contain plugin folders, where I placed libflashplayer.so among the other *.so files that existed there. In both cases, I get a different error message from FDT when I run it from the command line
I'm assuming the second error message ("No more handles") is the important one; the first one may go away after the .SWFViewerCheck directory has been created after successfully running SWFViewer once. I guess this means more testing... I tried another "solution" recommended several places on the internet; starting the application either with -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner or appending that same line to eclipse.ini.
Sadly, this did not work either, and gave the same error message as previously provided:
Setting both MOZILLA_FIVE_HOME and passing the additional parameter at the same time did not work either. Yet another "solution" recommended adding -Dorg.eclipse.swt.browser.UseWebKitGTK=true to eclipse.ini. Again, this did not fix the issue, and gave the same error message as setting the XULRunnerPath variable. I mentioned this before, but I'll bring it up again. The "Internal Web Browser" works just fine (and judging by the command line output, it seems to use the browser I instructed it to in eclipse.ini). It seems to only be a problem with SWT or SWFViewer. I searched the file system for libxpcom.so and found it in the two following locations.
So using the aforementioned method, I set MOZILLA_FIVE_HOME to /usr/lib/firefox which definitely gave a different result. However, the result was a full on fatal Java error. I have placed the terminal output as well as the contents of the "log" file created by Java in this Gist: I'm getting a very similar error, which I do believe is related, when I debug an FDT Plugin.
The full error message can be found in this Gist (and it includes what I find to be an amusing output of "I am here. Bring it on.") Is FDT 5.5.2 the version that is currently available in the "Buy & Download" section?
Then yes, the same error is still occurring. For the previous comments, I tried all these tests with a fresh install from which ever version was up for download on 2012-06-12. I tried it again today with another fresh install, and am still getting the same results. The problem doesn't affect "standard development" as much as I can always use the Flash Player used by Adobe (a workaround described in my previous comments). However, it seems that FDT plugin development is impossible thanks to this bug (which is a shame, I was looking forward to trying that). Andreas,
First of all thanks a lot for doing this research. 1. Start FDT and compile a test project into a SWF java -cp swt-linux.jar:swfViewer-linux.jar com.powerflasher.swfViewer.SWFViewer -file=file:////pathToWorkspace/project/bin/project.swf As you can see we call directly the SWFViewer class of our swfViewer-linux.jar and also the swt-linux.jar is added to the classpath. I expect that the external swf viewer could not open its browser widget. But maybe you can try to adapt this call with additional parameters as you suggest above: If this works for your linux version I am going to implement an additional a preference page for the next FDT where those extra parameters could be added to the call of the external swf viewer. regards, Stephanie Stephanie,
I'm still getting the same results as the output in FDT I'm afraid, even using the additional parameters makes no difference; I still get the "MOZILLA_FIVE_HOME not set" error: So, I set MOZILLA_FIVE_HOME to /usr/lib/firefox, and as before, received this error message: I'm not sure which file the error is talking about when it says that it "is missing", but I can guarantee, libxpcom.so does exist inside of /usr/lib/firefox. Did some searching and some testing, as long as MOZILLA_FIVE_HOME is set properly, the error message looks much like this one:
https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/728825 
Though, rather than look in ~/.swt/lib/linux/x86, FDT will look in (and create, it seems) /tmp/swtlib-32/. I tried the same workaround as noted in the bugtracker, but rather than copy to the home folder, I copied to the "tmp" folder (In fact, I did both just to be on the safe side. I also had to install libswt-gtk-3-jni) It results in the same error message, "UnsatisfiedLinkError: Could not load SWT library.". No change. Would it perhaps make a difference with a newer version of Eclipse or SWTLib? There is a very good chance that this may not be an FDT problem. I would be happy to run any "test builds" if it helps. Andreas
Maybe you could also verify the following idea. java -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner -cp swt-linux.jar:swfViewer-linux.jar com.powerflasher.swfViewer.SWFViewer -file=file://~/Testbench.swf "Would it perhaps make a difference with a newer version of Eclipse or SWTLib?" Regards, Oddly enough, changing the parameter orders gives a new error message:
https://gist.github.com/3048738#file_fdt5+output+3 (this is despite MOZILLA_FIVE_HOME not being set in this terminal session)
Actually, I'm using 32 bit Linux (on a 32 bit machine), but it should be the same for both versions so long as the paths are changed, correct? I apologize for the inconvenience this is causing. Has no one else reported this error as well? I do find it odd that I'm the only person with this problem. I would assume it was due to user error, conflicting program, or a problem with installation, but the issue persisted even after a complete system reinstall. Success!
I did as you said, replacing swt-linux.jar with the version from my Eclipse for Java installation and it worked like a charm! (tested from inside of FDT, not running SWFViewer separately) ... well, sort of like a charm. The SWF runs just fine, but I'm not getting any output from "trace" (the process shows up as <terminated> from the console inside of FDT) and I'm getting another error from the terminal: But the SWF works, and that's good enough for me. In case it is of any use, the SWT library was version gtk.linux.x86_3.7.2.v3740f from an Eclipse Indigo installation for Java. Andreas,
thank you for all this work, this was very helpful. Another question: Is debugging possible ? Also you could change the start location to "http://www.whatismybrowser.com/" Regards,
Actually, this one was my mistake. In Java, you can get the console output with either "Run as" or "Debug as". Without thinking, I used "Run as" in FDT when testing. I did not realize that trace would only work with "Debug as". Everything is running like a charm (for real, this time). Thank you very much for taking the time and effort to get this matter sorted out! On a related note, if you need any beta testers for Linux builds of future versions of FDT, I would be very glad to assist. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
FDT won't launch the external player
I could always use tools such as Doomsday Console for on-screen terminal output.
FDT will give some logs directly to the terminal (stdout). Maybe you could give us these logs.
If the External SWF Viewer was ever visible you could try do delete this file:
FDT/plugins/com.powerflasher.fdt.ui.swfViewer/linux64/.SWFViewerCheck (contains the last used socket port)
and this directory:
FDT/plugins/com.powerflasher.fdt.ui.swfViewer/linux64/data (contains window placement, etc.)
After erasing these resources the External SWF Viewer should pop up again.
The External SWF Viewer uses a free socket connection (the port is the next available port in the system, chosen by the jvm) for communication between the already running instance and the new instance coming up from your last launch, to avoid another pop up of the viewer.