I wonder if there is a way to perform a step-by-step debugging of the compiled GWT code, in order to determine how some events are being fired.
The interest I have on this is that I'm using SmartGWT, and for some reason the click events on their components propagate to pop up windows that occupy the same position. However this only happens in Mobile Safari.
Even more interesting it only happens with smartGWT version of onClick and not with the plain GWT onClick.
Mostly a hack for now, but I suppose it'll work (you'll have to recompile your app though):
First, compile a recent GWT from trunk: https://developers.google.com/web-toolkit/makinggwtbetter#workingoncode
Then recompile your app with source maps enabled: http://code.google.com/p/google-web-toolkit/wiki/SourceMaps
Follow the steps in the comments of this wiki page to be able to use SourceMaps in Chrome, then re-deploy your app
Get Chrome on the Dev channel: http://www.chromium.org/getting-involved/dev-channel
Use http://www.iwebinspector.com/ to start Mobile Safari with remote debugging and then connect to it from your Chrome desktop: http://www.webkit.org/blog/1620/webkit-remote-debugging/
Finally, enable source maps in Chrome so you'll see your Java code in the Web Inspector!
See http://www.youtube.com/watch?v=-xJl22Kvgjg for a preview of the future of debugging with GWT, that will allow this kind of things in a much less hackish way in the near future.
I don't know if there is a nice way to debug compiled javascript GWT code, but why do you need it?
For described purpose it's better to use GWT development mode with debugging options. You can add the following parametres e-Xdebug -Xrunjdwp:transport=dt_socket,address={PORT},server=y,suspend=n to the development mode running command, it will give an opportunity to add breakpoints to the cliend side GWT/SmardGWT source code. Then for debugging you should connect to port specified in parametres from your java IDE.
Debugging GWT https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging
Related
Is Chrome Dev Tools available only through Chrome extensions? Or is there a way we can use it, for instance, as a library from a JS standalone file?
Update
Chrome DevTools Frontend is now an NPM package that you can take advantage of. It is based from the new DevTools sub-repo in Blink. So you can easily pull in the DevTools assets and keep then up-dated without much work.
Original post
It depends on what you want exactly. You can dig in and rip out bits of the frontend to use. Like Betwixt by Konrad pulls the network panel design out and plugs it up to an OS interceptor. So you can use the network panel you know and love to debug any app on your desktop.
Now, can you easily do this kind of stuff. Even keeping it auto-updated? No, not really. It is fairly complicated and you need to be able to handle ripping the stuff out yourself. That being said, if you want a challenge then the code is open to everyone.
I'd say that the first sentence on the About website is pretty clear:
... built into Google Chrome.
So officially, by Google, it's only for Chrome. It's part of Chrome, not a standalone library. Issues linked to DevTools are part of Chromium, where people can contribute.
I am currently trying to modify the behavior of an existing open-source plug-in for Eclipse.
I'm trying to understand how the plugin works. To do so, I opened it in "Debug" mode as an Eclipse application and I am testing it out after having inserted many breakpoints.
However, sine Eclipse plugins do not have a Main method, it's still really difficult for me to keep track of everything that is going on. The calls seem to jump arbitrarily (which I quickly realized was happening through all the interfaces and superclasses the plugin is inheriting) and I can't see exactly what's doing what.
What is the proper (read: BEST) way to debug a program with no Main method? How can I test, tweak, and explore and program - in this case a plugin - whose modus operandi I'm uncertain of?
You need to run your plugin in a runtime workbench. This (simplistically) starts a new instance of Eclipse with all existing plugins installed, plus the plugin you want to debug. Make sure that you have the PDE tools installed in your Eclipse instance and then in the debug configurations area, double-click on Eclipse Application to generate a default runtime workbench launch config.
I'd also recommend that you read up on PDE (plugin development environment), and you can get an overview here: http://wiki.eclipse.org/PDE/FAQ. And you can read up on plugins in general here: http://eclipsepluginsite.com/. There are many tutorials and lots of information all over the web. So, google is your friend.
Along with using breakpoints in Debug method you can even try printing stack trace using Thread.currentThread().getStackTrace() method to know the starting point of a Thread.
I am new to GWT and understood the motive behind creating such good framework. However I could not understand how GWT builds the UI and shows while in development mode.
It is said that while bootstrapping .nocache.js file is loaded in the browser, then this file created a hidden iframe. Then depending on browser and language settings a .cache.html file is loaded in the iframe where all application logic resides.
What I could not understand is how gwt does this in development mode/ hosted mode. Because .cache.html files are not available in development mode. I assume that the sdk receives a request from .nocache.js file regarding the browser details and then generates a .cache.html file for that particular browser and that is loaded in the iframe. My question is how .nocache.js file sends a request to sdk to dynamically generate a .cache.html file? Or does it have something to do with hosted.html and the browser plugin? How the UI and RPC code is loaded while in development mode. For nocache.js file to send a request there must be a server program (Servlet) listening to the request and allowing GWt to start looking for entrypoint class and start generating the UI content.
I could not understand how gwt will come to know about the browser settings and generate the UI? Does hosted.html and browser plugin has something to do with the content generation?
I searched using google, but all my trials went useless. Or may be I searched using wrong search keys. Could anyone please tell me or point me to a link where it is clearly explained?
When an application is running in development mode, the Java Virtual Machine (JVM) is actually executing the application code as compiled Java bytecode, using GWT plumbing to connect to a browser window.
As of GWT 2.0, development mode uses a regular browser instead of an embedded browser. You can use any supported browser.
Out of process hosted mode (OOPHM) is an upcoming replacement for GWT hosted mode debugger. OOPHM allows one to use a standard browser (IE, Safari (32bit) and Firefox) for debugging GWT-client-side code.
With OOPHM you can:
do modifications to your widgets with no time consuming Java-to-JavaScript recompilation
set breakpoints to widget code.
use any advanced browser features and extensions not available in conventional hosted mode (Firebug for example).
Useful links:
https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging
http://code.google.com/p/google-web-toolkit/wiki/DesignOOPHM
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
http://www.slideshare.net/allahbaksh/gwt-generators-and-oophm
Have a nice time.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...
I need to see component tree of the GWT application. DOM tree will be also acceptable. Unfortunatelly GWT hosted browser does not provide access for devToolbar.
The only way I found is to compile to javascript and then use regular browser. But compilation takes enormous ammount of time.
ExtJS has Debug Console, but I was not able to find something similar for GXT.
Please suggest the way you debug visual GWT applications.
Yes, I was just wanting this today FireBug + GWT. If you are adventurous you could look into builds of GWT 2.0 where Out Of Process Hosted Mode will be available letting you debug in FireFox or other browsers. Design: Out of Process Hosted Mode
The source for GWT is here http://google-web-toolkit.googlecode.com/svn/branches/
I personally haven't hit the pain threshold to build this yet because I keep hearing 2.0 is "close"
It's not a debugger in the same mould as Firebug but the GWT Log console is really, really handy for finding out what's happening within the JavaScript.
See: http://code.google.com/p/gwt-log/
Normally one would use the IDE debugger to step through GWT code. but if the problem is a CSS/styling issue (which from the sound of the question, it seems to be), then that might not really help.
i guess compiling it and using firebug is the only tried and true way for css issues.
Why is compilation into (pretty) JavaScript taking so much time? I don't think it should. Perhaps you should disable compilation for irrelevant browsers (irrelevant for debugging purposes), thereby reducing compilation time significantly.
One idea is to minimize compile time by reducing the permutations (different version for each browser) during development.
In your module.gwt.xml force an user agent, for example gecko1_8 (Firefox 2).
<!-- User Agent -->
<set-property name="user.agent" value="gecko1_8" />
If you're using i18n you can also limit the locales used during development.