Summary: | [GTK] Change the mouse pointer state to busy while loading a page | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Salvatore De Paolis <iwkse> | ||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED WONTFIX | ||||||||
Severity: | Enhancement | CC: | alp, bunk, christian, diegoe, evan, mrobinson, pnormand, pochu27, xan.lopez | ||||||
Priority: | P2 | Keywords: | Gtk | ||||||
Version: | 523.x (Safari 3) | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Salvatore De Paolis
2007-11-02 07:59:26 PDT
This is a duplicate of bug http://bugs.webkit.org/show_bug.cgi?id=16205 *** Bug 16205 has been marked as a duplicate of this bug. *** So, bdash told me yesterday that WebKit does not do this (and has never done it). If it should be done on Application side this bug should be closed as INVALID/WONTFIX. Unlike for example gtkmozembed WebKit does not normally apply a loading pointer on its own. In many non-browser use cases this is the desired behavior. Instead you should make use of gdk_window_set_cursor in a "load-progress-changed" callback. BTW: while I don't have anything against doing this in app-side, we need some API hooks to do it correctly I think. Unconditionally setting cursor on load-progress-changed is wrong: if you are hovering a link, for example, the cursor should remain as a "hand" all the time, but we'd switch it to a "watch/wait" when the next progress-change happens.A signal would a good way of doing this, but any other way would do. Or if anybody knows how Safari or other WebKit browser handles this, that might help too :) Yeah, I think it's OK for us to support this in WebCore directly, though it might be worth providing a way to turn it off. Xan, can you try adding a setPointerCursor() (or maybe pushPointerCursor()/pop if you're feeling elaborate) to Cursor.h? Then we can just call this from somewhere doing the loading. Created attachment 18875 [details]
useloadingcursor.diff
Quick and dirty patch.
- I'm using just a bool value in CursorGtk to decide if I return pointerCursor or waitCursor in the pointerCursor function. I think this is good enough? The static variable might be anathema in C++, maybe we can replace it with some class variable or something...?
- Might want to cache the value of the setting in FrameLoaderClientGtk and connect to notify::use-loading-cursor to update the value.
Tested this with Epiphany, it works ok.
*** Bug 26579 has been marked as a duplicate of this bug. *** Found this old bug. In Chrome we have to do some work to get the cursor+hourglass cursor that Firefox (and now Chrome) uses. You can take a glance through the Chrome cursor code to see how it works. (It's pretty hacky.) Created attachment 225352 [details]
Patch
Comment on attachment 225352 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=225352&action=review > Tools/MiniBrowser/gtk/BrowserWindow.c:485 > + GdkWindow *gdk_window = gtk_widget_get_window(GTK_WIDGET(window->webView)); We use camelCase here, I think. So, gdkWindow ? > Tools/MiniBrowser/gtk/BrowserWindow.c:493 > + gdk_window_set_cursor(gdk_window, lastCursor); I suppose it's alright to not check lastCursor is non-null here, right? Passing NULL means use the cursor of the parent window. Pretty sure we don't want this ATM. |