[Webkit-unassigned] [Bug 17171] [Gtk] script-confirm and script-prompt signals are not binding-friendly

[bugzilla-daemon at webkit.org]

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





--- Comment #9 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-02-22 11:01:13 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > I like the the idea of using a single signal for the 3 dialogs, but showModalDialog has nothing to do with these dialogs imo. 
> 
> I feel that it's related, but the process of creating one is so different (create a web view, prepare it, run it as modal) that I'm not sure how cleanly it will be to adapt to this API. In any case, the idea that Zan proposed seems sound to me.

alert, prompt and confirm are not dialogs to contain a web view, I don't think they are related. modal dialogs are relates to create/ready-to-show/close. It's just a additional step to the process of create a popup window that makes the newly created window run in modal mode.

> > With the current api that is pretty clear, because you have to return the result as an out parameter, but passing an object might give the idea that you can ref the object and handle the request later asynchronously, like policy client api. 
> 
> I think we can solve this problem by just being clear in the documentation.  Note that this is almost precisely the same as the file chooser API that Mario is making, so there is some precedence. 

No, run-file-chooser is async. 

> > So, I would suggest rename the signal as run-modal-javascript-dialog, and the object passed be a simple boxed type (instead of a full gobject) that we can allocate on the stack so that its scope is the signal emission.
> 
> I prefer script-dalog or run-dialog.

run-script-dialog? run usually gives the idea they it will be modal because of gtk_dialog_run()

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