[webkit-dev] No getters for iconURL/title/body in Notification.idl

[Alexandre Mazari]

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 <johnnyg at google.com> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev