This is totally awesome! I have the tour of heros working with angular2 as
per a project post by Lte Consulting a year ago. Is there the Angular4 tour
of heros example working and published? I work a very large government
department that is just starting to use Angular 4 now and i would like to
Hi,
I'm developing a JS library using GWT. I have a JSNI function and I'm able
to pass in premitive types to it from js. I'm looking for a way to pass in
an htmlElement and an EventHandler. Is this something that' supported?
Thanks,
--
You received this message because you are subscribed to
I believe it is, though I think they may have taken Gmail's Javascript
rich-text editor (the one from the Closure library). I'm pretty happy with
it, too.
On 10:55 am, stuckagain david.no...@gmail.com wrote:
Hi, I'm writing this message using the new Groups... and what do I
see... it is now
Ready for review now?
On 2:32 pm, Ray Ryan rj...@google.com wrote:
http://gwt-code-reviews.appspot.com/1163801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Paul,
First off, I'd like to applaud your diligent efforts to track down these
leaks. It's often very hard in practice, especially with the paucity of good
tools and no access to the browser's source.
That Microsoft leak detector is definitely the right one to be using -- Drip
(which I wrote
The point of that method being protected is that under normal circumstances
you don't want to be able to add handlers to a widget that's not capable of
firing them in the first place. So a widget subclass creates
addFooHandler(), then uses this method internally.
Are you saying you want to add a
[+rjrjr]
I haven't put much thought into widget interfaces recently (I've been busy
wrestling low-level stuff on other fronts), but clearly Ray and others have
been thinking about this problem (based upon the appearance of IsWidget,
which seems to have worked out well). Thoughts?
--
Specific examples might be helpful here. I can see how this might be useful
in some specific cases, but wrapping every new in a template method sounds
like a horribly contorting way to have to write all one's code.
Le 13 octobre 2010 05:19, cokol eplisc...@googlemail.com a écrit :
many other
Hmm... I didn't even realize AttachEvent had been added. John Ray, you
might want to take a look at this -- in the original design this super
invocation wouldn't have mattered, because widget's onLoad() was empty
(onAttach/Detach() weren't really meant to overridden outside of Panel and
Composite
Thanks for pointing these out, Jay. If you could put together a quick patch,
we'd be glad to commit it.
Le 6 octobre 2010 16:52, jay jay.gin...@gmail.com a écrit :
While debugging my code I ran across two things within the TabBar
class that I seemed strange... (Line numbers are from svn 8960.)
getOffsetWidth/Height() always read the current state of the widget's
backing element, which won't be updated until the layout panels are done
laying themselves out. All the layout panels have the potential to be
animated, and defer actually laying things out until the end of the current
event (in
Sorry about that. Will look at it this afternoon (US/EST).
Le 20 septembre 2010 04:45, johan.rydb...@gmail.com a écrit :
Ping!
On 2010/09/07 16:49:52, rjrjr wrote:
Please!
On Tue, Sep 7, 2010 at 8:01 AM, Joel Webber mailto:j...@google.com
wrote:
@rjrjr: I notice you own the bug
Daniel,
Which HTML5 features are you thinking of emulating on older browsers? It
seems to me that the only ones realistically emulatable are a few of the
input types -- most of the stuff like canvas, audio/video, et al would be
impossible without direct browser support. It might be kind of
This is slightly off-topic, but I'm curious -- would having a formal nightly
build actually be acceptable for use within your locked-down environment?
And would the same go for offline dev-mode plugin installers?
Le 12 septembre 2010 08:43, David david.no...@gmail.com a écrit :
Eric,
No I'm
@jlabanca: Sounds like a bit of an anachronism in the code. Is this
something we can clean up now (and do you need a hand getting it done if
so)?
Le 13 septembre 2010 03:50, stuckagain david.no...@gmail.com a écrit :
Hi,
While factoring out a dependency on GWT incubator I stumbled upon the
Whoops, looks like I missed a rename :)
Thanks for the heads-up.
Le 13 septembre 2010 11:03, dflorey daniel.flo...@gmail.com a écrit :
...in ResizeComposite:25
java.lang.AssertionError: LayoutComposite requires that its wrapped
widget implement HasLayout
should be
Don't worry, I'm sure it will come back next time we need to do something
big that needs time to settle. This ended up being a much, much better
pattern than the incubator, which just became a dumping ground with
version-skew hell...
Le 10 septembre 2010 03:28, edwin...@gmail.com a écrit :
Wait, are you saying that your compile time went down *by* 2/3 (meaning to
1/3 of its original duration)?
And this is a result of pulling the incubator off of the classpath (and
hoisting out a couple of widgets)?
That would seem to be a pretty big difference!
@Eric: This might be interesting
Allez Nicolas!
Le 9 septembre 2010 09:18, nicolas de loof nicolas.del...@gmail.com a
écrit :
For info,
I'll speak at JugSummerCamp http://www.jugsummercamp.org/ conference
tomorrow on GWT 2.
Long live GWT :D
Nicolas
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
@rjrjr: I notice you own the bug -- do you have time to look at this, or
would you like me to take it off your hands?
Le 6 septembre 2010 04:48, johan.rydb...@gmail.com a écrit :
Reviewers: ,
Description:
Let MenuItem implement HasEnabled and update MenuBar to use this
information when
growth in a compiled GWT 1.5.4
application?
On Aug 27, 12:52 pm, Joel Webber j...@google.com wrote:
Hmm... I've tried to reproduce this on IE7 and IE8 (both quirks
standards), to no avail. I doubt it's anything in the outer HTML file,
but just in case, here's what I used
Hmm... I've tried to reproduce this on IE7 and IE8 (both quirks
standards), to no avail. I doubt it's anything in the outer HTML file,
but just in case, here's what I used:
!DOCTYPE HTML
html
head
titleHello/title
script type=text/javascript language=javascript src=hello/
[+some people who have looked at this problem in the past]
Le 19 août 2010 09:36, stuckagain david.no...@gmail.com a écrit :
Hi,
I found out that using something like addStylename() in an onmouseover
can have really catastrophic effects on performance in IE (6/7 and 8).
In fact IE8 seems to
Le 15 août 2010 10:40, Cristiano cristiano.costant...@gmail.com a écrit :
Hello all,
I need to work with new HTML5 elements: video and SVG's tags.
Now I'm doing some experiment and I'm working out this HTML5 support
by myself on a modified src of GWT: I'm adding some new Element
subclasses
Bob Lex,
I just ran into an interesting error message while experimenting with some
JSO stuff that you might be able to shed some light on. First, here's the
error:
InternalCompilerException: Already seen an implementing JSO subtype
(DocumentImpl) for interface (Node) while examining
Le 11 août 2010 15:11, BobV b...@google.com a écrit :
At first glance, this would appear to anger the SingleJSO gods. However,
because NodeImpl contains implementations of all Node methods, there is
no
actual ambiguity as to which method implementation to bind to. The this
is
a bug
instead of document.write, which seems
to work, and would like you to look at it. How can I send this file to
you?
On Jul 23, 3:17 pm, Joel Webber j...@google.com wrote:
We've tried to get rid of the document.write() tricks before, but with no
success. There's always some squirrely case
[+matt, who's one of the few people I know outside of Google creating custom
linkers]
I'm 100% on board with this as well. These things weren't all that carefully
designed for extension from the beginning, so it's going to be difficult to
make significant changes to them without breaking existing
We've tried to get rid of the document.write() tricks before, but with no
success. There's always some squirrely case that crops on (especially on IE)
that's forced us to put them back in. There are also a couple of specific
corner cases that rely on document.write(), which would need to be
Thanks, Brendan. I entered issue 5125 to capture the general IE9 support
issue. I agree that it seems likely we'll be able to shift to an IE9 that
derives from the standard browser base classes. Nothing would make me
happier :)
Le 24 juin 2010 15:08, Brendan Kenny bcke...@gmail.com a écrit :
I
Konstantin,
I've not gone over these proposals in great detail, but it does seem like a
reasonable idea to build design time hooks into UiBinder-generated code.
One very important caveat would be that it must be possible for the compiler
to strip them out completely in production mode (this seems
@rjrjr: What say ye? Have you considered doing something like this before,
and perhaps found a way to generalize it such that we don't have to create a
separate attribute parser for every enum?
Le 22 juin 2010 07:14, konstantin.scheg...@gmail.com a écrit :
Reviewers: jgw,
Description:
It
Le 22 juin 2010 07:03, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
Pretty much everything we've done so far has been limited to
automatically
exposing the Java-level APIs in all their ugliness. The h/v alignment
values
are implemented somewhat manually, but for things
Just to let everyone know, I've finally gotten around to picking up this
task again, and have updated the linked wave with my proposals. Please feel
free to chime in; I could use the feedback.
Le 11 juin 2010 11:13, Thomas Broyer t.bro...@gmail.com a écrit :
On Thu, Jun 10, 2010 at 11:59 PM,
We're also working to get the new widgets libraries stabilized well before
that, though we don't have hard dates. One thing to look for would be the
removal of the Note: This class is new and its interface subject to
change. warnings in the javadoc. Or just ask here :)
Le 21 juin 2010 14:29,
Thanks, Stephen.
@Dan: Is this still applicable, or has it been fixed already?
Le 9 juin 2010 13:21, Stephen Haberman step...@exigencecorp.com a écrit :
Hi,
I was playing with the Mail example this morning and saw a stack trace
casting the Message class to Comparable for the TreeMap inside
Le 19 juin 2010 10:34, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
Why existing horizontal/vertical alignment parsers use so unfriendly
names for alignments? ALIGN_RIGHT looks not very good in XML. Why
not just right? This would be more natural for people with HTML
That certainly looks like a leftover implementation detail that could be
cleaned up. If you don't mind putting together a patch I'd be happy to
commit it.
Le 18 juin 2010 08:23, Konstantin.Scheglov konstantin.scheg...@gmail.com a
écrit :
Is there reason to have separate handling for
added also other patch yesterday and would like to add more
of them in future (TextAlignConstant parser, AbsolutePanel support,
etc). What is procedure for asking review? Sorry if I'm too
impatient. ;-)
On Jun 18, 5:26 pm, Joel Webber j...@google.com wrote:
That certainly looks like
Even if that were a stupid thing to do, it shouldn't be crashing like that
:) I suspect that most browsers would either silently fail or throw an
exception under those circumstances, but that should be pretty harmless.
What browser/platform are you seeing this on? At a glance, the bug looks
like
in a FlowPanel?
On Wed, May 26, 2010 at 8:41 AM, Joel Webber j...@google.com wrote:
Well... HorizontalPanel is still useful in some instances, and we have no
way of providing the same behavior in a general way because CSS layout is a
bloody mess. I'd be ok with deprecating the others (StackPanel
at 8:36 AM, Ray Ryan rj...@google.com wrote:
Joel, can we @Deprecate all the redundant non-flow panels yet? It's
getting harder and harder for people to discover the right thing to do.
On Wed, May 26, 2010 at 7:15 AM, Joel Webber j...@google.com wrote:
The FlowPanel (just a simple div
Crap, sorry. I/O ate my brain. Reviewing now.
Le 2 juin 2010 10:04, b...@google.com a écrit :
Ping.
http://gwt-code-reviews.appspot.com/335802/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
The FlowPanel (just a simple div that leaves its children's styles
unmodified) already allows you to do this. For the vertical case, this tends
to happen naturally with block-level children.
The horizontal case is trickier, however. Using float:left captures some,
but definitely not all cases
...@google.com a écrit :
Joel, can we @Deprecate all the redundant non-flow panels yet? It's
getting harder and harder for people to discover the right thing to do.
On Wed, May 26, 2010 at 7:15 AM, Joel Webber j...@google.com wrote:
The FlowPanel (just a simple div that leaves its children's
We should definitely consider how we're going to bring gesture/touch events
into the existing event framework. I went ahead and wrote this the simple
way because it will only ever need to work on mobile webkit browsers, which
all safely support addEventListener() and don't leak memory.
Le 14 mai
Erin,
The DOCTYPE of the script HTML won't affect the behavior of the outer page.
You should only have to put a simple !DOCTYPE html in the outer page --
that's it. If you're still having troubles with LayoutPanel after that, ping
me.
Cheers,
joel.
Le 13 mai 2010 15:04, Erin
I'm not the right one to review this, but I just wanted you to (a) apologize
for your email getting caught by the spam filter (which I just fixed), and
(b) let you know that we're all pretty slammed getting ready for I/O, so it
might be a while before anyone has time to take a look. This looks
I've added comments to the bug so they don't get lost.
The short form of the story is that I'm not sure it's possible to make this
work in the general case because of various cross-browser issues (I'm always
happy to be proven wrong, though!)
Le 6 mai 2010 18:58, jarrod jarrod.carl...@gmail.com a
You can always just put it up in a little code.google.com (or github, as you
see fit) project. That usually makes it easier for others to try it out.
Le 30 avril 2010 14:03, kozura koz...@gmail.com a écrit :
Ok, understood, just didn't want it to get lost in the mix. Maybe for
now I'll just
Kerr,
Can you show me roughly the code needed to get into this state? It sounds
like it could be a problem, but I'm having a slightly hard time imagining
the precise code that got you here.
Cheers,
joel.
Le 15 avril 2010 12:34, kerrr kerr.rai...@gmail.com a écrit :
Hi,
I've been playing
Allahbaksh,
That seems like it would be useful, though looking at the code I'm a little
wary as to whether it works in all circumstances (font-size changes, etc).
The first step would be to convert it to Java (usually pretty
straightforward) and test it under all the circumstances you can think
[I just commented directly on the linked issue]
On Thu, Apr 8, 2010 at 11:17 PM, jarrod jarrod.carl...@gmail.com wrote:
I would really like to see a way to distinguish between
SelectionEvents (and BeforeSelectionEvents) in TabLayoutPanel based on
whether the event occurred in response to a
Brendan,
At a quick glance, this looks pretty much like I would have expected a good
workers library to look like. Is there any way I *could* convince you to
make a wave of it? It's a pretty big description, and would probably diverge
badly on a mailing list (@everyone: If anyone who frequents
[+cromwell: What's the current state of the enum optimizations? I seem to
recall they were partially done, but forgot where the doc is]
On Mon, Apr 12, 2010 at 11:28 AM, codesite-nore...@google.com wrote:
Comment by piotr.swigon:
Joel,
I would like to ask if anything has changed regarding
[+gwt group]
Konark,
I actually don't see an attached screenshot (perhaps you forgot the
attachment -- I do that all the time). I would normally recommend just
looking at the Showcase source (it's part of the GWT distribution, and you
can find it online here:
I was hoping that because most people (not using the Maps API) wouldn't need
this, it wouldn't be necessary to provide a special case for layout
complete outside of the existing animation callbacks. Does it not work to
put the Map in a RequiresResize container and call its layout method when
John,
Sorry for the slow response -- I've had a browser window open for several
days to respond, but I keep getting pulled off onto other things.
It sounds like this is indeed an ordering bug. It's hard to be sure
precisely when IE's going to call onresize() (onmove() and onresize() are
obscure
On Wed, Mar 24, 2010 at 1:01 PM, dflorey daniel.flo...@gmail.com wrote:
I've been missing that one as well.
I can provide patches if desired.
--
On Wed, Mar 24, 2010 at 11:40 AM, dflorey daniel.flo...@gmail.com wrote:
I just needed a TabLayoutPanel with Tabs on the bottom instead of tabs
I just installed the preview the other day as well, and most things seem to
be working ok (the UA script should detect it as IE8 for the time being). As
others point out on this thread, the DOMContentLoaded thing is expected
(because they added addEventListener()) but likely harmless.
I haven't
[+matt]
I can't speak to any experience with either of these libraries, but this
also sounds like the work Matt's been doing here:
http://code.google.com/p/gwt-rpc-plus/
http://code.google.com/p/gwt-rpc-plus/Can anyone speak to the relationship
between these libraries? I'd love to see a
I think we're talking about two different things here. Rodrigo's (valid)
point is that implementing immutability sanely early on is a good idea. And
this implementation is pretty much analogous to the one you describe from
Cocoa.
The question at hand is whether it makes sense to get an immutable
I am able to reproduce this leak as well, and can confirm that it only
happens on IE6 (not 7+). If I use a standard image url rather than a
ClientBundle, the leak goes away. Interestingly, though, it doesn't appear
to be a standard circular-ref leak, because Microsoft's own leak detector
doesn't
That's definitely a valid point, and I understand how it would defeat
caching. However, I believe using a hash for the callback name would make it
impossible to properly deal with two requests to the same URL, because there
would be no way to distinguish which AsyncCallback should get which
John,
The background behind that weird type hierarchy is that it stems from a time
before overlay types existed. Originally c.g.g.user.client.Element was a
simple opaque handle that had to be passed to the DOM.*() methods to get
anything done (same for Event). After the compiler got overlay type
This is Avira, isn't it? Ddi you ever hear anything back from them about
this? It seems like it really ought to be fixed on their end, though I
applaud your spelunking for a workaround :)
On Tue, Mar 16, 2010 at 3:08 PM, Matt Mastracci matt...@mastracci.comwrote:
On Mar 16, 12:42 pm, Matt
That's great news, and will really help with efforts to make our linkers
more sane. Out of curiosity, what's the strategy for loading fragments into
the enclosing namespace (and yes, that's the sound of me being too lazy to
dig into the patch)?
On Mon, Mar 15, 2010 at 6:17 PM, sp...@google.com
First of all, there have always been widgets that have used tables, and
those that don't. When we started designing them, tables were pretty much
the only way to get sane layout behavior, especially before anything like
standards mode was widely supported. But it's always been possible to
avoid
Thanks, George. I'll put these on our schedule to look at as soon as we can.
On Fri, Mar 5, 2010 at 9:41 AM, ggeorg georgopoulos.georg...@gmail.comwrote:
Hi,
please have a look at:
- http://code.google.com/p/google-web-toolkit/issues/detail?id=4720can=4
-
@Ian: I know, it's nasty. These things have gotten a bit out of hand, and we
have a big, fat TODO to come back and clean this up (as well as to bring
together various other linkers under a more coherent umbrella). But we
probably won't be able to get around to it for at least another quarter,
We could argue the merits of method chaining (I'll let the compiler guys
speak to whether or not this is better, worse, or indifferent for code
generation) -- but the bigger problem is that we'd have to change the style
of code throughout the system to make it useful, but any attempt to do so
I can assure you that this is not a general problem -- we've built plenty of
applications (including the Mail sample) which work fine using a structure
very much like the one you describe. If it's only happening on IE, there's a
very good probability that you're running using a quirks-mode doctype
What Thomas said. But yes, if we could make a good safe-eval JSON parser
available, that would be great. The old json library is both unsafe
(because it uses eval()) and ugly (because it was written long before
overlay types).
On Sat, Feb 20, 2010 at 10:22 AM, Thomas Broyer t.bro...@gmail.com
across browsers.
On Mon, Feb 15, 2010 at 10:46 AM, Joel Webber j...@google.com wrote:
I'm not sure if it's possible to do this correctly in the general case.
You can currently override setVisible(), but that only works if it's called
explicitly. Most importantly, there's no way I know of to get
That's great news. I'm particularly happy given that (IIRC) Ray confirmed
that these have no negative impact on parse time (please tell me I'm
remembering this correctly!).
On Tue, Feb 16, 2010 at 8:21 PM, Ray Cromwell cromwell...@gmail.com wrote:
Awesome, thanks a lot for the data and
[+jlabanca: can you take a look at this?]
On Mon, Feb 15, 2010 at 9:06 AM, stuckagain david.no...@gmail.com wrote:
People,
Somehow testings needs to be a bit enhanced. GWT 2.0.2 which is
supposed to fix issue 4585 does not seem to work correctly. Although
the original stack is no longer
I'm not sure if it's possible to do this correctly in the general case. You
can currently override setVisible(), but that only works if it's called
explicitly. Most importantly, there's no way I know of to get the DOM to
tell you when an element becomes visible/hidden; to synthesize this would
Sebastian,
Sorry it's taken so long for anyone to respond. This sounds like useful
functionality, and I would suggest creating an issue (
http://code.google.com/p/google-web-toolkit/issues/) and a patch for public
discussion (http://gwt-code-reviews.appspot.com/). That way it will be
easier for
Thanks, Marko. I'll take a look at it today.
On Tue, Feb 9, 2010 at 4:07 AM, Marko Vuksanovic
markovuksano...@gmail.comwrote:
I thought it would be nice if it was possible to have hovering effect
on StackPanelLayout header so I created an issue for that (issue nuber
is 4561, or direct link
This may be a problem with SmartGWT. I'm not familiar with the details of
how they deal with wrapping events from the native SmartClient widgets, but
if they fail to properly punt exceptions to the UncaughtExceptionHandler,
dev mode will eat the exceptions.
On Thu, Feb 4, 2010 at 12:58 PM, J-Pro
=4584
On Feb 4, 6:36 pm, Joel Webber j...@google.com wrote:
It shouldn't be -- if you kick off History's static initializer, it will
GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
believe it's been this way for a long time. Are you sure you're not
referencing
=4584
On Feb 4, 6:36 pm, Joel Webber j...@google.com wrote:
It shouldn't be -- if you kick off History's static initializer, it will
GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
believe it's been this way for a long time. Are you sure you're not
referencing
Karl-Heinz,
We are planning on adding built-in support for the HTML5 AppCache, but have
not done so yet. I believe there are some projects already in existence
working to do this, such as gwt-mobile-webkit (
http://code.google.com/p/gwt-mobile-webkit/). I haven't used this project
personally, but
It shouldn't be -- if you kick off History's static initializer, it will
GWT.create(HistoryImpl.class), and thus attempt to find the iframe, but I
believe it's been this way for a long time. Are you sure you're not
referencing History somewhere?
On Thu, Feb 4, 2010 at 10:34 AM, stuckagain
To be clear, we do recognize the importance of starting to support HTML5
constructs that don't work on all browsers, though we need to find a clear
way to indicate to developers that a particular library or widget won't work
in some cases. None of us have ever worked through all the nuances of how
Feb., 17:23, dflorey daniel.flo...@gmail.com wrote:
What about Fred Sauer's gwt voices project?
AFAK it has an elegant approach how to provide flash based fallback if
certain capabilities are not supported by the browser itself.
On 1 Feb., 14:25, Joel Webber j...@google.com wrote
Correct me if I'm wrong, but isn't the closure collections library more like
JRE-ish collections than simple JSO wrappers? My impression of most JS code
was that if it needed a string map or simple array, people tended to just
use raw objects, knowing that there are certain strange behaviors they
[+gwt-contrib]
That's pretty impressive. Have you tried it on any larger scene graphs? I'd
love to see how it scales. It looks quite smooth on Chrome already.
On Fri, Jan 22, 2010 at 3:05 AM, Neil Halelamien ne...@caltech.edu wrote:
I quasi-ported the Phys2d Java physics library to run with
[+gwt-contrib]
That's pretty impressive. Have you tried it on any larger scene graphs? I'd
love to see how it scales. It looks quite smooth on Chrome already.
On Fri, Jan 22, 2010 at 3:05 AM, Neil Halelamien ne...@caltech.edu wrote:
I quasi-ported the Phys2d Java physics library to run with
Sure thing. Looking now.
On Fri, Jan 22, 2010 at 11:17 AM, John LaBanca jlaba...@google.com wrote:
ping - can you get to this today? It should go into GWT 2.0.1
Thanks,
John LaBanca
jlaba...@google.com
On Wed, Jan 20, 2010 at 2:32 PM, jlaba...@google.com wrote:
Reviewers: jgw,
Agreed that this is a really irritating bug in Firefox. Have you tried
w/h:100% just on the button itself? This is required for table and
iframe on all browsers, though it's not baked into the Layout code by
default, because it mis-lays-out slightly (pushes borders and margin off the
edge).
On
(is it called
on one of the parent panels?)
On Jan 19, 5:07 pm, Joel Webber j...@google.com wrote:
On Mon, Jan 18, 2010 at 6:17 AM, dflorey daniel.flo...@gmail.com
wrote:
Hi,
I've been trying to usw the new TabLayoutPanel for different layouts.
Here are my findings:
1. The .gwt
To be clear, the inclusion of more core widgets and libraries won't impose
any size overhead on projects that don't use them. If you *do* use them, you
can always use code-splitting to divide your app into logical components
that are demand-loaded.
On Wed, Jan 13, 2010 at 10:25 AM, Deanna Bonds
Say I have a GWT-powered eBook reader.
That would be really cool :)
Ok, fair enough. Let's just leave it as is then.
LGTM.
On Wed, Jan 13, 2010 at 3:55 PM, Isaac Truett itru...@gmail.com wrote:
I like it except for one scenario:
Say I have a GWT-powered eBook reader. I hide some navigation
If you're not explicitly selecting the RTA's text (using
formatter.selectAll(), and it's becoming selected by default, please do file
a bug for this. It's likely a mozilla bug, but there's probably something we
can do to forcibly work around it. Do post a snippet that reproduces the
exact behavior
at 2:26 PM, Joel Webber j...@google.com wrote:
If you're not explicitly selecting the RTA's text (using
formatter.selectAll(), and it's becoming selected by default, please do file
a bug for this. It's likely a mozilla bug, but there's probably something we
can do to forcibly work around it. Do
Ok, I'm a complete idiot. Please ignore stupid chatter between me and John
about our internal repository. There is nothing in GWT (internally or
externally) called RichTextEditor, so I just assumed RichTextArea was being
referred to on this thread.
On Fri, Jan 8, 2010 at 2:45 PM, Joel Webber j
createUniqueId() guarantees a unique id for the document, but makes no
guarantees about uniqueness within the global namespace ($wnd). I think it
would be a worthwhile addition to create such a method in the future,
though.
On Thu, Jan 7, 2010 at 4:12 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Thu, Jan 7, 2010 at 9:57 AM, John LaBanca jlaba...@google.com wrote:
createUniqueId() guarantees a unique id for the document, but makes no
guarantees about uniqueness within the global namespace ($wnd). I think it
would be a worthwhile addition to create such a method in the future,
Whoops, thanks. Added, and will commit momentarily.
On Wed, Jan 6, 2010 at 5:47 AM, dflorey daniel.flo...@gmail.com wrote:
reminder
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
1 - 100 of 342 matches
Mail list logo
