[Webkit-unassigned] [Bug 61140] [GTK] Add HTML5 Notifications support

Wed Jun 22 04:12:11 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=61140

--- Comment #23 from Xan Lopez <xan.lopez at gmail.com>  2011-06-22 04:12:11 PST ---
(In reply to comment #21)
> I am really not sure signals are the best tools here: there  will always be only one interested party that will share state across calls. Class are made for that purpose by giving type safety and separation of concerns.
> WebKitWebView and the mirroring EphyWebView are alreadyd kinda bloated IMHO with signals/handlers with unrelated concerns and the respective state. 

This is a false dichotomy. If you really feel it's better you can create a new object (WebKitWebNotificationCenter) that will be in charge of all notification related stuff. Then one would get that from the WebView and use it through signals, as we usually do. Whether we put them in WebView or not is a matter of convenience for the user. Pretending that signals force upon us bad design is disingenuous IMHO.

Once that is gone we are left with concerns about type safety and whatnot, which although valid I think are nowhere near as important as being consistent with the platform we target, which uses signals thoroughly, or any other number of concerns. Not to mention, of course, the multiple features signals provide, like multiplexing or chaining, which are often useful and sometimes a must-have. Signals have their uses, interfaces have their uses, we should use each one when it's appropriate to do so.

In any case I do not want this to derive into a metaphysical debate about OO design. This library is 3+ years old, and the platform we live in more than a decade old. We are not going to radically change how we structure libraries at this point, so let's get on with our work.

> 
> > - We have a notification object with all the data bits and two signals, show and cancel. This is the DOM object defined in the spec and available in our GObject bindings if we enable it (I don't think we are doing this now).
> > 
> 
> Yeah reusing thate would be great, but the generated WebKitDOMNotification do not have fields/properties for the actual notification content (title, body and icon url). Somehow the IDL (Source/WebCore/notifications/Notification.idl) do not declare them.
> 

You are right! Since this is actually an interface, deriving from EventTarget, I guess the right thing to do is to just add the interface to our bindings (see how EventTarget is done in WebCore/bindings/gobject) and create a new object ourselves that implements that as far as it's useful. For instance I think the right thing to do here would be to use the show/cancel functionality through standard add_event_listener methods in the notification object, since that's how it's meant to work apparently.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.