Heya, As Xan stated, it'd feel a lot more natural to use our representation of the node, and let proven generated code handle GObject wrapping of the native WebCore object.
As a fast hack, we could write and IDL for NotificationContents and refer to it from the Notification one. What do you think ? Happy Coding, Alexandre Le vendredi 01 juillet 2011 à 20:38 +0200, Xan Lopez a écrit : > On Fri, Jul 1, 2011 at 8:17 PM, John Gregg <[email protected]> wrote: > > The data parameters are certainly needed by the UA to show the notification, > > but it seems like you're suggesting they need to be exposed as part of the > > Notification API (i.e., to web pages). I don't see why that would be > > necessary. > > WebCore has a Notification object in C++ which does provide access to the > > fields, and which is passed up through the NotificationPresenter interface > > implemented in the ChromeClient. That's how Chromium does it -- would it > > not work for GTK? > > There's several things there. > > - Indeed we'd use this WebCore Notification object, same than > Chromium. The problem is that this object doubles as the > representation of whatever is in the spec we follow (usually the DOM > spec, not in this case but close enough) and it also has extra things > useful for the UA, as we are discussing. > > - In the normal case we just let our bindings generate automatically a > GObject wrapper for the core object, but since this is generated from > the IDL it would lack the needed accessors. > > - You say that you don't see any need to let binding users access that > information, in that case our version of the DOM object probably > shouldn't allow that either. > > - In that case we can either subclass it and add what we need, or just > not use the DOM objects in this case. The problem with the latter is > that we'd need to reimplement portions of the expected DOM interfaces > in the new class we'd do, so it seems a bit pointless to do so, and > that we'd expose two different versions of the object in different > scenarios (for instance, createNotification would create something > different than what you'd receive from the WebKit API in some cases). > > In any case, I guess the obvious answer is: why is it not interesting > for the web page to access the parameters passed to the object when > it's constructed? Since it will generally be constructed from within > the page itself (unless I'm totally wrong), it seems reasonable. > > Cheers, > > Xan > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
