[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
@mP: That would be great if you're interested in moving it into GWT proper.
It's one of those things we've always known was a big can of worms, and no
one's had much time to look into it.
On Mon, Aug 17, 2009 at 5:30 PM, Miroslav Pokorny
miroslav.poko...@gmail.com wrote:
Re/ Selections
I have Selections for all the big 4 in my library. Ive implemrmted most of
the needed functionality to mimic the w3c interfaces including:
• creation by specifying end points ( Elements, offset)
• testing if a selection exists.
• expanding / moving either the start / end.
• deletion
• clearing a selection.
• extracting a selection (the cut so it can be pasted somewhere else).
• surrounding - inserting a parent making it easy to add a span with
styling.
• enabling/ disabling selection for a dom fragment.
• retrieve selected text
Most of what you need is there. I might be wrong but if memory serves me
tight i could not defeat the way Ie rounds selections to the nearest whole
word once they grow bigger than a minimal size.
This is all 1.5 compatible code but it should be no big deal to sex it up
if interest exists in taking it.
Hth
On 18/08/2009, at 4:16 AM, Matt Mastracci matt...@mastracci.com wrote:
Joel,
This is definitely a can of worms! I spent some time thinking through
the some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good
a time as any to bring it up. In fact, there are several such
classes that need to be moved out of gwt.user.client into a more
sensible place (and others that still need to be written). What they
have in common is that they have nothing to do with widgets, but are
not core because they assume the existence of a real web browser
(as opposed to other potential Javascript targets such as Flash).
The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]())
- History (there are both the native history object, and the GWT
history implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires
Timer to work)
One consideration this raises is that some have internal state
associated with them. For instance, both the Cookies class and
Location classes have precomputed maps of data. How can you ensure
that a service is a singleton for a given native object (or is it best
to provide this for the default window and document only)? There's
also the issue with cleaning up objects when documents/windows are
unloaded, since the lifetime of the GWT module may be significantly
longer than the windows it references. I suppose the cleanup could be
handled via some global per-window unload cleanup queue attached to a
specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may
reference the same native window or document?
History and location may be useful to expose as simple JSO wrappers
over the native browser's objects. The full GWT history
implementation would probably be less useful on a window that didn't
contain a GWT module (esp. considering that newItem() is so different
on every browser).
For Timer and IncrementalCommand, I suspect there wouldn't be much
lost if they were left as global services. The only advantage to
having per-window timers that I can think of right now would be
scoping the lifetime of the timer to the window itself (is this even
consistent across browsers?). I think it might be sufficient to
create a rebind point for creating timers for different environments.
FWIW, this is the code we use to simulate Timer when running as a
Firefox extension. It would be a lot cleaner as a timer rebind and I
imagine that AIR and other JS-but-not-HTML environments would be very
similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer;
1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager
::safeCallback(Lcom/
google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager
::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
One thing I didn't make clear from the beginning, btw, was that I *am* in
favor of doing something about Window sooner rather than later, even if we
don't resolve the rest of this stuff. More than anything, I wanted to get
buy-in on the appropriate package/module, and the general approach for
moving old APIs to new locations. See below for further comments.
On Mon, Aug 17, 2009 at 2:16 PM, Matt Mastracci matt...@mastracci.comwrote:
Joel,
This is definitely a can of worms! I spent some time thinking through the
some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good a
time as any to bring it up. In fact, there are several such classes that
need to be moved out of gwt.user.client into a more sensible place (and
others that still need to be written). What they have in common is that they
have nothing to do with widgets, but are not core because they assume the
existence of a real web browser (as opposed to other potential Javascript
targets such as Flash). The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]())
- History (there are both the native history object, and the GWT history
implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires Timer to
work)
One consideration this raises is that some have internal state associated
with them. For instance, both the Cookies class and Location classes have
precomputed maps of data. How can you ensure that a service is a singleton
for a given native object (or is it best to provide this for the default
window and document only)? There's also the issue with cleaning up objects
when documents/windows are unloaded, since the lifetime of the GWT module
may be significantly longer than the windows it references. I suppose the
cleanup could be handled via some global per-window unload cleanup queue
attached to a specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may reference
the same native window or document?
History and location may be useful to expose as simple JSO wrappers over
the native browser's objects. The full GWT history implementation would
probably be less useful on a window that didn't contain a GWT module (esp.
considering that newItem() is so different on every browser).
My inclination would be to avoid the caching stuff for the core browser
APIs, for precisely the reasons you point out. History is a big question
mark, but could easily be avoided for the time being (though it *does* at
least belong in its own module, but that's a separate issue).
For Timer and IncrementalCommand, I suspect there wouldn't be much lost if
they were left as global services. The only advantage to having per-window
timers that I can think of right now would be scoping the lifetime of the
timer to the window itself (is this even consistent across browsers?). I
think it might be sufficient to create a rebind point for creating timers
for different environments. FWIW, this is the code we use to simulate Timer
when running as a Firefox extension. It would be a lot cleaner as a timer
rebind and I imagine that AIR and other JS-but-not-HTML environments would
be very similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer
;1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager
::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager
::safeCallback(Lcom/google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager
::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C selection
API is very useful, but I'm not sure if there's a compelling use case
outside of Google Wave to merit the effort required (I had experimented with
this a while back, but it's difficult to get consistent results between
webkit/gecko, let alone with IE in the picture :)!).
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
One thing I didn't make clear from the beginning, btw, was that I *am* in
favor of doing something about Window sooner rather than later, even if we
don't resolve the rest of this stuff. More than anything, I wanted to get
buy-in on the appropriate package/module, and the general approach for
moving old APIs to new locations. See below for further comments.
On Mon, Aug 17, 2009 at 2:16 PM, Matt Mastracci matt...@mastracci.comwrote:
Joel,
This is definitely a can of worms! I spent some time thinking through the
some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good a
time as any to bring it up. In fact, there are several such classes that
need to be moved out of gwt.user.client into a more sensible place (and
others that still need to be written). What they have in common is that they
have nothing to do with widgets, but are not core because they assume the
existence of a real web browser (as opposed to other potential Javascript
targets such as Flash). The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]())
- History (there are both the native history object, and the GWT history
implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires Timer to
work)
One consideration this raises is that some have internal state associated
with them. For instance, both the Cookies class and Location classes have
precomputed maps of data. How can you ensure that a service is a singleton
for a given native object (or is it best to provide this for the default
window and document only)? There's also the issue with cleaning up objects
when documents/windows are unloaded, since the lifetime of the GWT module
may be significantly longer than the windows it references. I suppose the
cleanup could be handled via some global per-window unload cleanup queue
attached to a specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may reference
the same native window or document?
History and location may be useful to expose as simple JSO wrappers over
the native browser's objects. The full GWT history implementation would
probably be less useful on a window that didn't contain a GWT module (esp.
considering that newItem() is so different on every browser).
My inclination would be to avoid the caching stuff for the core browser
APIs, for precisely the reasons you point out. History is a big question
mark, but could easily be avoided for the time being (though it *does* at
least belong in its own module, but that's a separate issue).
For Timer and IncrementalCommand, I suspect there wouldn't be much lost if
they were left as global services. The only advantage to having per-window
timers that I can think of right now would be scoping the lifetime of the
timer to the window itself (is this even consistent across browsers?). I
think it might be sufficient to create a rebind point for creating timers
for different environments. FWIW, this is the code we use to simulate Timer
when running as a Firefox extension. It would be a lot cleaner as a timer
rebind and I imagine that AIR and other JS-but-not-HTML environments would
be very similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer
;1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager
::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager
::safeCallback(Lcom/google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager
::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C selection
API is very useful, but I'm not sure if there's a compelling use case
outside of Google Wave to merit the effort required (I had experimented with
this a while back, but it's difficult to get consistent results between
webkit/gecko, let alone with IE in the picture :)!).
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Matt, Thanks for bringing this up; I've been meaning to do so for a long time. When the original Window class was written, it was basically infeasible to support multiple-window code in GWT, and JavaScriptObject was opaque and non-extensible. Such are the problems of writing libraries against rapidly-evolving compiler tech :) At any rate, we *do* need something like this, and now seems as good a time as any to bring it up. In fact, there are several such classes that need to be moved out of gwt.user.client into a more sensible place (and others that still need to be written). What they have in common is that they have nothing to do with widgets, but are not core because they assume the existence of a real web browser (as opposed to other potential Javascript targets such as Flash). The ones that come to mind are: Existing: - Window - Location - Cookies (though maybe Document just needs its cookie property implemented) - Timer (this is implemented on top of Window.set[Interval Timeout]()) - History (there are both the native history object, and the GWT history implementation to consider) - [Incremental Deferred]Command (Smells like core, but requires Timer to work) New: - Selection (this is pretty tricky, because selection on IE is so amazingly weird) - Others? The main hold up for me has been figuring out how to move the existing classes to a more sensible module, and precisely what that module is. Selection and Window could arguably be considered par of DOM (WebKit has a DOMWindow class, even though the W3C doesn't consider it part of the DOM per se). It is not immediately obvious to me where the others should live, though -- should we have a Browser module, for example? Then there's the question of how to move them in a sensibly backwards-compatible manner. With the DOM module's Element class, I kept the names the same, because they have to be typed so often. I'm still not 100% certain that was the best approach, but I guess it's worked ok. How weird would everyone find it if Window, Cookies, Timer, History, and DeferredCommand all showed up in two places, with the originals eventually deprecated? It makes me a little nervous, to be honest, but so does trying to come up with new names for all of them and confusing matters further. Cheers, joel. On Thu, Aug 13, 2009 at 2:45 PM, Matt Mastracci matt...@mastracci.comwrote: Hi all, I've been hacking around the lack of a true JavaScriptObject window in GWT for a while and I was wondering if there was any interest in me providing a patch for it. While the current com.google.gwt.user.client.Window works for most cases, you aren't able to interact with other windows in the system without resorting to hand-rolled JSNI. For example, calling com.google.gwt.user.client.Window::open() doesn't provide you a way to close the window that was just opened. I propose adding a JSO subclass to the com.google.gwt.dom.client package. For the first patch there would be a handful of uncontroversial methods on it (further patches could provide the remainder of the functionality that exists in the com.google.gwt.user.client.Window): Document getDocument(); void alert(String); String prompt(String); void close(); I would also propose adding the following method to Document to get its associated window. On standards-compliant browsers, this would map to defaultView. On IE, this would map to parentWindow: Window getParentWindow() Thoughts? Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Joel,
This is definitely a can of worms! I spent some time thinking through
the some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good
a time as any to bring it up. In fact, there are several such
classes that need to be moved out of gwt.user.client into a more
sensible place (and others that still need to be written). What they
have in common is that they have nothing to do with widgets, but are
not core because they assume the existence of a real web browser
(as opposed to other potential Javascript targets such as Flash).
The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]())
- History (there are both the native history object, and the GWT
history implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires
Timer to work)
One consideration this raises is that some have internal state
associated with them. For instance, both the Cookies class and
Location classes have precomputed maps of data. How can you ensure
that a service is a singleton for a given native object (or is it best
to provide this for the default window and document only)? There's
also the issue with cleaning up objects when documents/windows are
unloaded, since the lifetime of the GWT module may be significantly
longer than the windows it references. I suppose the cleanup could be
handled via some global per-window unload cleanup queue attached to a
specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may
reference the same native window or document?
History and location may be useful to expose as simple JSO wrappers
over the native browser's objects. The full GWT history
implementation would probably be less useful on a window that didn't
contain a GWT module (esp. considering that newItem() is so different
on every browser).
For Timer and IncrementalCommand, I suspect there wouldn't be much
lost if they were left as global services. The only advantage to
having per-window timers that I can think of right now would be
scoping the lifetime of the timer to the window itself (is this even
consistent across browsers?). I think it might be sufficient to
create a rebind point for creating timers for different environments.
FWIW, this is the code we use to simulate Timer when running as a
Firefox extension. It would be a lot cleaner as a timer rebind and I
imagine that AIR and other JS-but-not-HTML environments would be very
similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer;
1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C
selection API is very useful, but I'm not sure if there's a compelling
use case outside of Google Wave to merit the effort required (I had
experimented with this a while back, but it's difficult to get
consistent results between webkit/gecko, let alone with IE in the
picture :)!).
There's a few miscellaneous DOM services that would be useful, such as
the DOM tree walking service and xpath functions. Neither of those is
complex enough to be consequential, so they probably wouldn't factor
into any design.
The main hold up for me has been figuring out how to move the
existing classes to a more sensible module, and precisely what that
module is. Selection and Window could arguably be considered par of
DOM (WebKit has a DOMWindow class, even though the W3C doesn't
consider it part of the DOM per se). It is not immediately obvious
to me where the others should live, though -- should we have a
Browser module, for example?
I
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Additionally, DOM overlay types could be generalized with JSO Single
Impl interfaces.
On 17 ago, 15:16, Matt Mastracci matt...@mastracci.com wrote:
Joel,
This is definitely a can of worms! I spent some time thinking through
the some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good
a time as any to bring it up. In fact, there are several such
classes that need to be moved out of gwt.user.client into a more
sensible place (and others that still need to be written). What they
have in common is that they have nothing to do with widgets, but are
not core because they assume the existence of a real web browser
(as opposed to other potential Javascript targets such as Flash).
The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]())
- History (there are both the native history object, and the GWT
history implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires
Timer to work)
One consideration this raises is that some have internal state
associated with them. For instance, both the Cookies class and
Location classes have precomputed maps of data. How can you ensure
that a service is a singleton for a given native object (or is it best
to provide this for the default window and document only)? There's
also the issue with cleaning up objects when documents/windows are
unloaded, since the lifetime of the GWT module may be significantly
longer than the windows it references. I suppose the cleanup could be
handled via some global per-window unload cleanup queue attached to a
specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may
reference the same native window or document?
History and location may be useful to expose as simple JSO wrappers
over the native browser's objects. The full GWT history
implementation would probably be less useful on a window that didn't
contain a GWT module (esp. considering that newItem() is so different
on every browser).
For Timer and IncrementalCommand, I suspect there wouldn't be much
lost if they were left as global services. The only advantage to
having per-window timers that I can think of right now would be
scoping the lifetime of the timer to the window itself (is this even
consistent across browsers?). I think it might be sufficient to
create a rebind point for creating timers for different environments.
FWIW, this is the code we use to simulate Timer when running as a
Firefox extension. It would be a lot cleaner as a timer rebind and I
imagine that AIR and other JS-but-not-HTML environments would be very
similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer;
1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C
selection API is very useful, but I'm not sure if there's a compelling
use case outside of Google Wave to merit the effort required (I had
experimented with this a while back, but it's difficult to get
consistent results between webkit/gecko, let alone with IE in the
picture :)!).
There's a few miscellaneous DOM services that would be useful, such as
the DOM tree walking service and xpath functions. Neither of those is
complex enough to be consequential, so they probably wouldn't factor
into any design.
The main hold up for me has been figuring out how to move the
existing classes to a more sensible module, and precisely what that
module is. Selection and Window could arguably be considered par of
DOM (WebKit has a
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Re/ Selections
I have Selections for all the big 4 in my library. Ive implemrmted
most of the needed functionality to mimic the w3c interfaces including:
• creation by specifying end points ( Elements, offset)
• testing if a selection exists.
• expanding / moving either the start / end.
• deletion
• clearing a selection.
• extracting a selection (the cut so it can be pasted somewhere
else).
• surrounding - inserting a parent making it easy to add a span with
styling.
• enabling/ disabling selection for a dom fragment.
• retrieve selected text
Most of what you need is there. I might be wrong but if memory serves
me tight i could not defeat the way Ie rounds selections to the
nearest whole word once they grow bigger than a minimal size.
This is all 1.5 compatible code but it should be no big deal to sex it
up if interest exists in taking it.
Hth
On 18/08/2009, at 4:16 AM, Matt Mastracci matt...@mastracci.com wrote:
Joel,
This is definitely a can of worms! I spent some time thinking through
the some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good
a time as any to bring it up. In fact, there are several such
classes that need to be moved out of gwt.user.client into a more
sensible place (and others that still need to be written). What they
have in common is that they have nothing to do with widgets, but are
not core because they assume the existence of a real web browser
(as opposed to other potential Javascript targets such as Flash).
The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]
())
- History (there are both the native history object, and the GWT
history implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires
Timer to work)
One consideration this raises is that some have internal state
associated with them. For instance, both the Cookies class and
Location classes have precomputed maps of data. How can you ensure
that a service is a singleton for a given native object (or is it best
to provide this for the default window and document only)? There's
also the issue with cleaning up objects when documents/windows are
unloaded, since the lifetime of the GWT module may be significantly
longer than the windows it references. I suppose the cleanup could be
handled via some global per-window unload cleanup queue attached to a
specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may
reference the same native window or document?
History and location may be useful to expose as simple JSO wrappers
over the native browser's objects. The full GWT history
implementation would probably be less useful on a window that didn't
contain a GWT module (esp. considering that newItem() is so different
on every browser).
For Timer and IncrementalCommand, I suspect there wouldn't be much
lost if they were left as global services. The only advantage to
having per-window timers that I can think of right now would be
scoping the lifetime of the timer to the window itself (is this even
consistent across browsers?). I think it might be sufficient to
create a rebind point for creating timers for different environments.
FWIW, this is the code we use to simulate Timer when running as a
Firefox extension. It would be a lot cleaner as a timer rebind and I
imagine that AIR and other JS-but-not-HTML environments would be very
similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer;
1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C
selection API is very useful, but I'm not sure if there's a compelling
use case outside of Google Wave to merit the effort required (I had
experimented with this a while back, but it's difficult to
