[webkit-gtk] Custom Filechooser dialog
Hi, in Sugar [1] we have a custom file chooser dialog. When our browser was using xulrunner we did override NsIFilePicker [2] and displayed our custom file chooser dialog instead. I am looking now around how I would do this in webkitgtk. The API does not seem to be prepared for anything like that. Grepping around in the code the dialog seems to get created in 'gtk/WebCoreSupport/ChromeClientGtk.cpp' in 'runOpenPanel'. But no idea how I would intercept here. Any ideas how I could handle that special case? Regards, Simon [1] http://sugarlabs.org/ [2] https://developer.mozilla.org/En/NsIFilePicker ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
[webkit-gtk] Roadmap for 1.8?
Hi, I was wondering what the Roadmap for 1.8 is? I looked around on the page and in the ml-archives but could not find something, yet. For me it would be interesting to know if/when I can base my work on the unstable API [1] and make usage of the new shiny additions (e.g. SpellChecker). At least Fedora seems to already packaging the latest 1.7.x. Regards, Simon [1] http://webkitgtk.org/reference/webkitgtk/unstable/index.html [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=10635 ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] Roadmap for 1.8?
On 16/01/12 16:56, Martin Robinson wrote: On Mon, Jan 16, 2012 at 5:07 AM, Simon Schampijersi...@schampijer.de wrote: I was wondering what the Roadmap for 1.8 is? I looked around on the page and in the ml-archives but could not find something, yet. For me it would be interesting to know if/when I can base my work on the unstable API [1] and make usage of the new shiny additions (e.g. SpellChecker). At least Fedora seems to already packaging the latest 1.7.x. Recently [1] we decided to follow the Gnome schedule [2] for stable releases. 1. http://trac.webkit.org/wiki/WebKitGTKStableReleases 2. http://live.gnome.org/ThreePointThree Thanks Martin for the quick reply. Sugar is following the GNOME schedule as well [1], so this model fits me perfectly well. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.96/Roadmap ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] hovering-over-link signal and HitTestResult in WebKit2 API
On 01/27/2012 02:56 PM, Carlos Garcia Campos wrote: Looking at liferea code I've noticed that they use WebKitWebView::hovering-over-link signal (ephy uses it too). This signal comes from ChromeClient::mouseDidMoveOverElement() and I was wondering whether it would be useful to expose it as a general signal in the API, instead of just for links. ChromeClient::mouseDidMoveOverElement receives a HitTestResult, in WebKit1 we are checking whether it's a link or not and then emitting WebKitWebView::hovering-over-link in case it's a link. In WebKit2 mouseDidMoveOverElement is a callback of the UI Client, that also receives a HitTestResult, so what do you think about exposing WebKitWebView::hovering-over-element? That also made me think about how to expose HitTestResult in the API. In WebKit1 it's only used by webkit_web_view_get_hit_test_result() (it sounds like a getter, but it actually performs a hit test and returns the result). In WK2 there's no API to make a hit test from the UI process, and I'm not sure it's actually needed. However, I think a HitTestResult object can be useful in the API, probably with a different name WebKitWebElement or something like that. This could be passed as an argument to the WebKitWebView::hovering-over-element signal, and it could be used for the context menu API. We could use a similar approach than WK1 HitTestResult object, it has flags to get information about the hoevered thing (whether it's a link, or image, or text selected, whether the area is editable, etc.) and the uri or the image, link or media. It also has the inner node, we can add later once we have DOM bindings in WK2. What do you think? Hi Carlos, that is interesting. I am working on the port of the Sugar browser from xpcom to webkit and was wondering about something similar. My intended behavior is the following: when you 'right-click' on an element (e.g. link or image) in the page I want to associate a custom menu (e.g. copy/save) with it. When the mouse leaves the element the menu is hidden (the menu is as well hidden when the mouse leaves the menu but that logic is inside the menu itself), will look something like this [1]. xpcom has something like an event listener [2], so you could either listen on all of the dom (an element has been clicked for example) but you could also associate it with a specific element. For example I did code the 'right-click'-menu for an element with that - when you right click on an element (e.g. link) a menu (with save/copy etc) was displayed and then on the 'mouse-out' event on the element we did popdown the menu. With webkitgtk, I used now the 'button-press'-signal on the webview and then used the WebKit.HitTestResult [3] to determine what type of element I am dealing with. Like you describing above actually. To me it would be interesting to know as well when we have the 'mouse-out' event for a specific element so I can popdown the menu. In Chrome/Epiphany/Firefox you have to hit esc to popdown the menu or click outside of it, in Sugar we have as well the 'hover-out' way of popping down a menu. Regards, Simon [1] http://wiki.sugarlabs.org/images/d/df/Browse_0.86_palettes_improved.png [2] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIDOMEventListener [3] http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#webkit-web-view-get-hit-test-result ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] Custom Filechooser dialog
On 01/19/2012 05:10 PM, Martin Robinson wrote: On Thu, Jan 19, 2012 at 12:22 AM, Simon Schampijersi...@schampijer.de wrote: Thinking about it, would it maybe be a good addition to the API to have an 'upload-requested' signal similar to the 'download-requested' [1] one and then the listener decides whether to handle it or not, and if 'False' is returned the standard dialog is used? This functionality does seem like a reasonable addition to me. --Martin Hey, thanks Martin for your reply. What is the path forward on this one? I am wondering how to proceed: - is the approach above with a 'upload-requested' signal a good one that you would consider of adding as public API or are there other better approaches to solve the issue of having a custom file-chooser? - is this an easy addition for someone familiar with the codebase? Is there someone willing to do it or do I have to try and rip my hair out and write an ugly patch first? :) - API additions for webkit vs webkit2? Thanks a lot in advance for any clarification, Simon ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
Re: [webkit-gtk] Custom Filechooser dialog
Hi Martin,
thanks for getting back on this!
On 02/06/2012 06:17 PM, Martin Robinson wrote:
On Mon, Feb 6, 2012 at 7:44 AM, Simon Schampijersi...@schampijer.de wrote:
- is the approach above with a 'upload-requested' signal a good one that you
would consider of adding as public API or are there other better approaches
to solve the issue of having a custom file-chooser?
I think it makes a lot of sense. There's some kind of generic run an
open panel signal that the WebKit layer gets. We could pipe that out
to a WebKitWebView signal.
Ok, I did an initial patch (attached) to pipe an upload-requested
signal out, the return value is a boolean to indicate whether the
application handles the upload or not.
We have to get back the information from the application which file(s)
should be uploaded as well. I wonder how the API would best look like
for this. We could handle that in the return value, if we get a filename
back it was handled, if NULL is returned we display the default upload
dialog. This would be similar signal handling as in
'create-plugin-widget' where we return a widget from the signal
callback. Looks like we would have to write a custom GSignalAccumulator
for this. Other ideas suggestions?
- is this an easy addition for someone familiar with the codebase? Is there
someone willing to do it or do I have to try and rip my hair out and write
an ugly patch first? :)
It's a little hairy to get and build WebKit, but you can always drop
by the channel and ask for help. :) There's also a lot of good
documentation:
http://trac.webkit.org/wiki/BuildingGtk
http://www.webkit.org/coding/contributing.html
Yeah, it uses a lot of disk resources actually :) I am patching the
Fedora rpm for the moment.
- API additions for webkit vs webkit2?
It'd make sense to have it in both ports actually.
Agreed,
Simon
diff -ru webkit-1.6.1/Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp webkit-1.6.1-upload/Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp
--- webkit-1.6.1/Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp.old 2011-09-26 22:55:01.0 +0200
+++ webkit-1.6.1/Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp 2012-02-09 22:24:05.930973589 +0100
@@ -606,6 +606,12 @@
{
RefPtrFileChooser chooser = prpFileChooser;
+gboolean handled;
+g_signal_emit_by_name(m_webView, upload-requested, handled);
+if (handled) {
+return;
+}
+
GtkWidget* dialog = gtk_file_chooser_dialog_new(_(Upload File),
GTK_WINDOW(gtk_widget_get_toplevel(GTK_WIDGET(m_webView))),
GTK_FILE_CHOOSER_ACTION_OPEN,
diff -ru webkit-1.6.1/Source/WebKit/gtk/webkit/webkitwebview.cpp webkit-1.6.1-upload/Source/WebKit/gtk/webkit/webkitwebview.cpp
--- webkit-1.6.1/Source/WebKit/gtk/webkit/webkitwebview.cpp.old 2011-09-26 22:55:01.0 +0200
+++ webkit-1.6.1/Source/WebKit/gtk/webkit/webkitwebview.cpp 2012-02-09 23:24:06.085892079 +0100
@@ -178,6 +178,7 @@
PASTE_CLIPBOARD,
CUT_CLIPBOARD,
DOWNLOAD_REQUESTED,
+UPLOAD_REQUESTED,
MOVE_CURSOR,
PRINT_REQUESTED,
PLUGIN_WIDGET,
@@ -2000,6 +2001,21 @@
G_TYPE_OBJECT);
/**
+ * WebKitWebView::upload-requested:
+ * @webView: the object on which the signal is emitted
+ *
+ * A new Upload is being requested.
+ */
+webkit_web_view_signals[UPLOAD_REQUESTED] = g_signal_new(upload-requested,
+G_TYPE_FROM_CLASS(webViewClass),
+(GSignalFlags)G_SIGNAL_RUN_LAST,
+0,
+g_signal_accumulator_true_handled,
+NULL,
+webkit_marshal_BOOLEAN__OBJECT,
+G_TYPE_BOOLEAN, 0);
+
+/**
* WebKitWebView::load-started:
* @webView: the object on which the signal is emitted
* @frame: the frame going to do the load
___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
[webkit-gtk] Password field doesn't get input method
Hi, when using WebKitGTK with touch I came across the issue that the password field does not allow to use an input method in the password field, an on screen keyboard [1]. This behavior seem to be only desired on MAC platforms, does leave Epiphany or the Sugar browser with this issue. Logging into a web service with an OSK is currently not working. There is a patch on the ticket but after some discussion on the approach, things got stuck. It would be great to have this fixed, one more missing piece resolved for a great touch experience in a WebKitGTK browser. In the hope that someone can chime in. Regards, Simon [1] https://bugs.webkit.org/show_bug.cgi?id=34285 ___ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-gtk
