Comment by dygger:
Could someone tell if UiBinder supports DialogBox? - I tried it but got
compilation errors in generated UiBinderImpl class... Moreover, it passes
all dialog's content (including GWT widgets as a string in setHTML method:
f_DialogBox1.setHTML(gwt:VerticalPanel
On Wed, Oct 7, 2009 at 12:22 AM, rj...@google.com wrote:
Bob, is this going in? When it does, should I retool UiBinder to use it
for ui:style?
It didn't occur to me until now that you would have to have code like
this in UiBinder to generate the synthetic interfaces. Would it be
easier to
Comment by j...@google.com:
While it doesn't make a great deal of sense to put a DialogBox in a .ui.xml
file, because it's intended to be displayed via its own show() method, we
should be giving a better (and earlier) error than this. Note that you
*can* still create a dialog box's
Ok, that makes sense, and sounds like my fault. I'll have a look at it later
today.Thanks for catching this.
On Tue, Oct 6, 2009 at 1:31 PM, bond raul.pel...@mail.ee wrote:
I have same problem with Mail sample.
Could it be because of my locale - decimal symbol is comma?
Generated BinderImpl
Just added an issue:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4111
On Wed, Oct 7, 2009 at 9:30 AM, Joel Webber j...@google.com wrote:
Ok, that makes sense, and sounds like my fault. I'll have a look at it
later today.Thanks for catching this.
On Tue, Oct 6, 2009 at 1:31
I can review today. The redundant code is in
com.google.gwt.uibinder.rebind.CssResourceWriter.
Perhaps I'm wrong to be dismissive of Keith's concerns--we're aiming at
different audiences. He's' generating source that people will work with
directly, I'm generating source that will only be accessed
For that matter, given the existence of ui:style, is the need for this
utility still clear? Not saying it isn't, just unclear on its expected use.
The purpose of this tool is to give developers an easy upgrade to
@Strict mode, which is mostly just the grunt work of creating the Java
interface.
Revision: 6310
Author: amitman...@google.com
Date: Tue Oct 6 19:22:44 2009
Log: Patch to enable upgrade to latest HtmlUnit snapshots. Created a
temporary dir
where various HtmlUnit snapshots could be tried without polluting GWT_TOOLS.
IMPORTANT:
1. To test bug-fixes for Gwt 2.0 MS1, this
Revision: 6311
Author: sp...@google.com
Date: Wed Oct 7 07:58:15 2009
Log: Creating a snapshot branch.
http://code.google.com/p/google-web-toolkit/source/detail?r=6311
Added:
/branches/snapshot-2009.10.06-r6307
--~--~-~--~~~---~--~~
Revision: 6312
Author: sp...@google.com
Date: Wed Oct 7 08:02:09 2009
Log: adding a branch-info.txt
http://code.google.com/p/google-web-toolkit/source/detail?r=6312
Added:
/branches/snapshot-2009.10.06-r6307/branch-info.txt
===
--- /dev/null
+++
Here is some more information. I ran into this problem while testing the
plugin against GWT 1.7, trunk, and 2.0 MS1.
It looks like whenever we generate the hosted.html we use the timestamp of
that file as it was inside of the gwt-dev-PLAT.jar. It would seem to me
that we want to touch that file
Perhaps I'm wrong to be dismissive of Keith's concerns--we're aiming at
different audiences. He's' generating source that people will work with
directly, I'm generating source that will only be accessed via attribute
settings in a ui.xml file. @Keith, what do you do when you see
Do you have similar handling of dashes?
On Wed, Oct 7, 2009 at 8:39 AM, Keith Platfoot kplatf...@google.com wrote:
Perhaps I'm wrong to be dismissive of Keith's concerns--we're aiming at
different audiences. He's' generating source that people will work with
directly, I'm generating source
Had the same problem on Mac. I fixed it by removing Safari cache from /
Library/Caches.
On Sep 18, 3:37 pm, Marko Vuksanovic markovuksano...@gmail.com
wrote:
I had the same problem.. After struggling for 2 days I figured out
that the embedded jetty loads the hosted.html file form cache (C:
I get this error when I switch from the GWT compiled from Trunk back
to 1.7.1 or any previous versions.
I only know two ways to solve it:
1) Open up war\projectname\hosted.html and edit line 16 from
var $hostedHtmlVersion=2.0;
to
var $hostedHtmlVersion=1.6;
(which I think
I entered the issue
4112http://code.google.com/p/google-web-toolkit/issues/detail?id=4112,
to track this problem.
2009/10/7 Miguel Méndez mmen...@google.com
Here is some more information. I ran into this problem while testing the
plugin against GWT 1.7, trunk, and 2.0 MS1.
It looks like
This is definitely a bug and you should be able to switch between the two
versions.
As a work around try the following:
1) Delete the current war/MODULE/hosted.html file
2) Re-run hosted mode and see the failure and stop hosted mode (this causes
a new hosted.html file with the right version to be
Comment by myonceinalifetime:
I have already made 2 comments on my issue (check so I don't have to repeat
some stuff). I still cannot get oophm to debug. I have tried using the
compiled version of GWT from trunk (retrieved from SVN only yesterday Oct
6th) as well as the latest plugin for
Comment by tamplinjohn:
If it is behaving the same in GWT 1.7.1, it has nothing to do with OOPHM.
I would suggest posting on the GWT mailing list for assistance.
For more information:
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
LGTM
I'm not sure if it's worth the bother of trying to share this with
UiBinder land. The interesting stuff is all shared already, via
GenerateCssAst. (Maybe that'll be less true when we get around to
addressing
http://code.google.com/p/google-web-toolkit/issues/detail?id=4052, but
I'm not
Revision: 6315
Author: rj...@google.com
Date: Wed Oct 7 12:41:48 2009
Log: Tagging the source to release 1.7.1
http://code.google.com/p/google-web-toolkit/source/detail?r=6315
Added:
/tags/1.7.1
--~--~-~--~~~---~--~~
Reviewers: Ray Ryan,
Please review this at http://gwt-code-reviews.appspot.com/77802
Affected files:
M user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
Index: user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
diff --git
Revision: 6316
Author: rj...@google.com
Date: Wed Oct 7 13:03:24 2009
Log: Adds UiBinderUtilTest.
Created this while failing to reproduce a bug. Might as well hold on to it.
Reviewed by: jgw
http://code.google.com/p/google-web-toolkit/source/detail?r=6316
Added:
Committed r6316
http://gwt-code-reviews.appspot.com/77801
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
LGTM
And here I was hoping it wasn't me. Thanks!
http://gwt-code-reviews.appspot.com/77802
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
FWIW, I'm pretty sure I wrote that code myself a long time ago...
On Wed, Oct 7, 2009 at 4:05 PM, rj...@google.com wrote:
LGTM
And here I was hoping it wasn't me. Thanks!
http://gwt-code-reviews.appspot.com/77802
--~--~-~--~~~---~--~~
On 2009/10/07 20:05:36, Ray Ryan wrote:
LGTM
And here I was hoping it wasn't me. Thanks!
Committed at r6317.
http://gwt-code-reviews.appspot.com/77802
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Revision: 6317
Author: j...@google.com
Date: Wed Oct 7 13:08:06 2009
Log: Fix for issue 4111 (comma-decimal-separator bug).
Review: http://gwt-code-reviews.appspot.com/77802
http://code.google.com/p/google-web-toolkit/source/detail?r=6317
Modified:
If any work is going to be done in consideration to 4052, it's probably
worth keeping
http://code.google.com/p/google-web-toolkit/issues/detail?id=4053 in mind,
as they're likely related.
- Amir
On Wed, Oct 7, 2009 at 11:49 AM, rj...@google.com wrote:
LGTM
I'm not sure if it's worth the
Comment by myonceinalifetime:
In my previous posts I said that when I put gwt-dev-oophm.jar to the top of
classpath the swing UI changes from doing hosted mode to the new mode where
it depends on a plugin in the browser to connect the javascript to the java
code. So no, its not running the
Revision: 6318
Author: rj...@google.com
Date: Wed Oct 7 14:54:10 2009
Log: Revert Adds UiBinderUtilTest (tr...@6316) due to IE6 failures.
This reverts commit 0e12ef8016347f2303afcc69627e61af05d45c8d.
http://code.google.com/p/google-web-toolkit/source/detail?r=6318
Deleted:
Hi gwitters,
Before filling any issue, just want to be sure that it's a bug.
Here is my ui.xml
gwt:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:gwt='urn:import:com.google.gwt.user.client.ui'
ui:with field='bundle' type='com.somewhere.client.MyExternalBundle'/
ui:style
Not a bug. You're in charge of MyExternalBundle, including injecting it.
Note that there is no relationship between the bundle generated for the
ui:style block and your MyExternalBundle instance.
On Wed, Oct 7, 2009 at 3:10 PM, Sami Jaber sami.ja...@gmail.com wrote:
Hi gwitters,
Before
Comment by myonceinalifetime:
Basically, the web app runs exactly the same regardless of whether or not
the plugin is installed (both FF and IE). Thus it is behaving the same as
when using hosted mode in GWT1.7.1 but putting the address
(http://localhost:8080/myproject.html) in an external
Comment by tamplinjohn:
You should have a ?gwt.hosted=... portion of the URL -- otherwise the
plugin isn't being loaded in your browser (and requires you to have
compiled your app to JS).
For more information:
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Hmm, I just tried changing between 3 different versions (trunk, 1.7.1
and 2.0MS1) and it worked flawlessly; no error. The hosted.html file
has maintained 2.0 for that variable through each change.
The only thing I can think of that fixed it is that I closed Eclipse
and launched it again before
LGTM
http://gwt-code-reviews.appspot.com/78802
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Comment by myonceinalifetime:
Yes, the address I posted was the one for hosted mode.
Development mode with OOPHM the address
is http://localhost:8080/myproject.html?gwt.hosted=192.168.133.133:9997;
Ya, my app is compiled as well, so maybe the browsers are only being served
those files
Revision: 6320
Author: fabb...@google.com
Date: Wed Oct 7 18:58:00 2009
Log: The old uses of getCanonicalName() blithely assumed that the
symlink-resolved
name was, in fact, still the same as the unresolved name. Oops.
Also tweaked use of List.toArray by giving it an correctly-sized argument
39 matches
Mail list logo
