Hi all,
all the stuff that FocusWidget does is maybe too much for my case. I
only need to cast to something that has setEnabled(boolean) method. In
other words I want to create a widget that would act similar to
TextBox and similar input widgets. Then I want to checkout Widgets out
of my
Comment by hong.zhu.hzhu:
I am having the same problem. any resolution to this?
Thank you
For more information:
http://code.google.com/p/google-web-toolkit/wiki/ClientBundle
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Interesting question. It's not immediately obvious to me whether we ought to
be shunting all js-java calls through $entry(). This should really only be
necessary when a call into java is coming from js that is at the top of the
stack. This usually means only event handlers, though if it were
Comment by rj...@google.com:
GWT 2 isn't done yet. There is a preview release in the downloads area,
2.0-ms1, but you'll note that it's marked deprecated to as a warning that
it is not intended for production use, and that its API will certainly
shift. Or you can build from svn trunk,
Comment by hong.zhu.hzhu:
Thank you! One follow-up question: Can I only use the ClientBundle with
GWT1.7.1?
For more information:
http://code.google.com/p/google-web-toolkit/wiki/ClientBundle
--~--~-~--~~~---~--~~
Revision: 6417
Author: rj...@google.com
Date: Mon Oct 19 09:31:20 2009
Log: Revert Cleans up SOYC options: , tr...@6416, due to
checkstyle build break.
http://code.google.com/p/google-web-toolkit/source/detail?r=6417
Deleted:
Reviewers: jat,
Description:
Description:
Running 1 thread per processor is too taxing for some test systems,
especially our build systems which all run selenium servers and
BrowserManager. The build files do not provide any more granularity
than this.
Fix:
Added the
Revision: 6418
Author: jlaba...@google.com
Date: Mon Oct 19 10:28:15 2009
Log: Adding option to set a specific threadCount for ant test targets.
Patch by: jlabanca
Review by: jat
http://code.google.com/p/google-web-toolkit/source/detail?r=6418
Modified:
/trunk/common.ant.xml
Revision: 6419
Author: rj...@google.com
Date: Mon Oct 19 12:21:04 2009
Log: Deleting the MS1 version of this branch to clear the decks
for for MS2 (and the march to release) as a straight copy
from tr...@6417.
The source for MS1 is still available as tags/2.0.0-ms1
Revision: 6420
Author: rj...@google.com
Date: Mon Oct 19 12:22:30 2009
Log: Creates the 2.0 release branch for MS2 and beyond as a
straight copy of tr...@6417.
svn cp -r 6417 https://google-web-toolkit.googlecode.com/svn/trunk \
https://google-web-toolkit.googlecode.com/svn/releases/2.0
Revision: 6421
Author: rj...@google.com
Date: Mon Oct 19 12:30:46 2009
Log: 2.0 branch-info.txt
http://code.google.com/p/google-web-toolkit/source/detail?r=6421
Added:
/releases/2.0/branch-info.txt
===
--- /dev/null
+++ /releases/2.0/branch-info.txt
So, here's the deal on deRPC. It doesn't yet have the miles on it that we'd
like, so we're pretty much on the fence as to whether to really ship it in
GWT 2.0 or not.
It has been included in MS1 and will be in MS2, but we may still make a no
go decision before the GWT 2.0 RC comes out.
If you (as
Following a question I asked privately to Bruce and Amit.
Thanks for your response gwitters
Sami
On Mon, Oct 19, 2009 at 9:38 PM, Bruce Johnson br...@google.com wrote:
Sami, would you mind asking this question directly on the Contributors
list? We can answer it so that everyone has a chance
IMHO, It would be a mistake not to make it happen for GWT 2
deRPC is a huge step forward in terms of performance, extensibility, command
sinking, serialization extensibility, security and so forth
Everybody know that GWT 2 will introduce new API and many new
functionalities, why deRPC would not
Love the enthusiasm!
Anyone else?
On Mon, Oct 19, 2009 at 4:26 PM, Sami Jaber sami.ja...@gmail.com wrote:
IMHO, It would be a mistake not to make it happen for GWT 2
deRPC is a huge step forward in terms of performance, extensibility,
command sinking, serialization extensibility, security
I also vote for deRPC. I am already using it in many places without
any problems. It has even less problems because of the missing script
took too long warning.
I run into one problem so far and that was already listed here:
On Mon, Oct 19, 2009 at 11:19 AM, Joel Webber j...@google.com wrote:
Interesting question. It's not immediately obvious to me whether we ought to
be shunting all js-java calls through $entry().
I would say yes, that GWT Exporter should be updated to support
$entry, if for no other reason than
Hi,
We've been building GWT application for about 3 years now, and we've
reached the point where compiling the internationalization strings
into the WAR file is no longer servicable. Today the GWT I18N support
is primarly based on Constants and Messages which is solely built on
Java property
Hi, perhaps a stupid question, have you tried putting in checks for
the parameters? Like:
public void add(SerializableObject child) {
if (child == this) {
throw new IllegalArgumentException(Cannot add self as
child!);
}
child.setParent(this);
children.add(child);
}
Hi,
Create an interface, like:
public interface HasState {
void setEnabled(boolean enabled);
boolean isEnabled();
}
...and then implement this with your composite widget. And don't try
to cast objects, GWT supports 'instanceof'. :-)
I hope this was to any help.
P.s. I'm actually
Revision: 6422
Author: b...@google.com
Date: Mon Oct 19 16:08:21 2009
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=6422
Modified:
/wiki/CssResource.wiki
===
--- /wiki/CssResource.wiki Fri
How does this interact with or supersede JsInliner.DuplicateXORemover?
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
On Mon, Oct 19, 2009 at 5:23 PM, Thoka thobias.karls...@gmail.com wrote:
We've been building GWT application for about 3 years now, and we've
reached the point where compiling the internationalization strings
into the WAR file is no longer servicable. Today the GWT I18N support
is primarly
Good question. Right now, it is a subset of what DuplicateXORemover can do,
since it does no inter-block propagation of data. The intent is that once
the full CFG is built, we'll use classical dataflow to track clinit calls
across blocks. For example, something like this:
if(cond) {
clinit1();
}
I've uploaded the updated patch set. This patch contains the pair
programming work that you and I did to re-work MessageTransport to use
the JRE's higher-level concurrency constructs. This patch also has unit
tests for the MessageTransport class.
Patch sets #2 and #3 are identical; I think the
@Thobias: I want to make sure I'm understanding the root motivation. Is the
problem that compiles are taking too long when you create permutations per
locale? Perhaps the more fundamental question I should ask is: would you
describe exactly what's unserviceable about the current static approach
26 matches
Mail list logo
