On FireFox, you could install the GreaseMonkey extension and write a
quick script that looks for the gwt.codesvr parameter on the current
page and adds the same parameter to all links. I don't know if there
is something similar in other browsers.
I find hat being able to debug in firefox with firebug and have gwt
breakpoints to be vastly surperior to old school hosted mode.
I guess I haven't had the frustration that you have because I just
leave the browser minimized between debug sessions and refresh when
necessary.
On Mar 11, 10:40 am,
Thanks. GreaseMonkey could prove to be the solution here, although I
have to experiment to see if GreaseMonkey will correctly pick up
dynamically generated DOM (e.g. links generated as part of a GWT
module).
Wouldn't be surprised if such script has already been written
On Mar 12, 6:34 am,
I fully agree, running a GWT app in native browser and being able to
debug it is the way to go, hosted mode is history.
However, for the time being, it looks like Google didn't really think
their browser plug-in through for accomodate apps which are gradually
introducing GWT by incorporating GWT
Comments in line below:
On Thu, Mar 11, 2010 at 11:40 AM, JazzyJava ole...@gmail.com wrote:
Helllo,
I am testing an upgrade of our appliation fro GWT 1.7 to 2.0. All is
fine, except I find that debugging now is a much bigger pain than it
was in 1.7. I have a feeling I am missing something,
Thanks for the quick response.
I looked at the link (https://groups.google.com/group/google-web-
toolkit/msg/e6d2814e79bc3a45), and it looks like a hack. It will only
work if I have some centralized URL generation logic, AND if I pass
the gwt.codesvr=x query param at some correct prior point
