GNOME Bugzilla – Bug 110693
middle click should auto-scroll
Last modified: 2005-08-26 12:35:20 UTC
I think that middle click paste for opening urls is really hackerish and causes usability problems when using hte scroll whell. See bug 109551 for my rationale.
fwiw, i tend to agree with mark. Though i do use the middle click to open a selected url sometimes, frequently I just accidentally middle click opening up (unexpectedly) a new window. I think the whole middle click to open a url feature just is a mask to cover up the issue of cross desktop web handling (ie. clicking a link in any program should always open up a web browser) and I agree it is in no way intuitive to non-unix hacker types. (though middle click copy and paste rules!!!!) All that said i suspect that autoscrolling will need to be handled at the mozilla or gtk level, though marco may prove me wrong.
The autoscroll code can be easily ported from galeon. I'd test it very well though, I dont want to get people asking for a pref to disable it because it's annoying (for example middle click to paste in forms doesnt work etc ...)
just for the sake of mentioning it, shouldn't something like this really be done at the gtk level for consistency amoung apps? Or is this a enough of a browser specific feature where doing it in ephy is appropriate.
It doesnt paste url anymore, moving as enh
Middle click paste in forms works in galeon HEAD, and middle clicking on a link still opens it in a new window. The only issue that I have with it is that when you middle click, scrolling with the mouse whell does not bring you out of "scroll mode", you have to click one of the mouse buttons. This cannot be that hard to fix, but is very important to overcome the problem of accidental clicking while scrolling.
Created attachment 16560 [details] [review] port of the galeon autoscroll code to epiphany
This patch is a direct port of the galeon autoscroll code to epiphany. If someone can point me that signal that is emited when the mouse wheel is scrolled i can fix the issue mark brought up. I think autoscroll is fairly sane here, as the moust is used to scroll, and clicking it just makes scrolling easier actually. Ok to commit this?
I'd wait 0.7 release before checking this in. Dont want to risk bugs ;)
fair enough, when is 0.6.1 due to be released? can you comment on the code too?
marco please review this when you get a chance :)
Please kill this #define NOT_IMPLEMENTED g_warning ("not implemented: " G_STRLOC); //#define DEBUG_MSG(x) g_print x #define DEBUG_MSG(x) In .h the macros should go on one line. These seem to not be aligned, maybe the patch though. static gboolean ephy_embed_autoscroller_mouse_press_cb (GtkWidget *widget, GdkEventButton *e, EphyEmbedAutoscroller *as); static gboolean ephy_embed_autoscroller_key_press_cb (GtkWidget *widget, GdkEventKey *e, I'd appreciate if you could get rid of this: MAKE_GET_TYPE (ephy_embed_autoscroller, "EphyEmbedAutoscroller", A bit of a pain though. EphyEmbedAutoscroller *as); Please do this like we do in other objects: G_OBJECT_CLASS (klass)->finalize = ephy_embed_autoscroller_finalize_impl; Please kill these and all comments like this //gtk_widget_push_visual (gdk_rgb_get_visual ()); //gtk_widget_push_colormap (gdk_rgb_get_cmap ()); A macro or something p->msecs = 33; Sort of crack, maybe use a boolean or something + else if (button == 1 + && !(context & EMBED_CONTEXT_LINK This is the first round of comments. WIll have to review more seriously later. + || context & EMBED_CONTEXT_EMAIL_LINK + || context & EMBED_CONTEXT_INPUT))
Created attachment 16695 [details] [review] updated patch, still too many magic numbers, since i don't quite know what they are yet.
Uhm I dont understand the set_embed get_embed thing and I'm not sure about the scroll logic, it looks like a pain to understand. Need to look at this with more time ... sorry I cant now :/ The code is not bad not thought, thansk.
set_embed and get_embed we're really only there for api completeness i use them to check if the current embed of the autoscroller is the same one as the calling embed in ephy_tab but i'm not sure if thats even necessary really. I don't understand the scrolling logic at all so any insight you have would be nice, damn code without comments.
I disagree completely about this. See #113515.
Remove patch keyword, this is unfinished
Sorry for the spam. Reassigning bugs with a target to our next milestone.
Target 1.2 -> 1.4 due to feature freeze.
Mass-moving Target 1.4 -> 1.6 because of feature and UI freeze. Sorry for the bugspam, search for "mass-move-1.4-1.6" to filter all of it.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Mass-moving bugs from Target Milestone: 1.6 to 1.8 because of feature, UI and string freeze.
Last week someone on #epiphany was talking about building an extension that would do just this.
Target: 1.8 -> 1.10 due to feature and UI freeze.
We now have an extension for this in epiphany-extensions, based on the galeon code.