Currently, it's possible to middle-click on an url to open it, but about every other time I do this, I end up missing slightly and pasting a bunch of stuff into the terminal instead. Feature request: let Ctrl+Left Click on an url open the url in a browser. lxde's terminal does this already, so there is a consistency argument as well. And the right-click menu takes too long :-)
Created attachment 5367 proposed patch Hi, I attached a patch adding this functionality.
Created attachment 6459 [PATCH] Add option to use either middle-click or control-click to open URIs Patch adds option "MiddleClickOpenUri" that, if set (default: yes) works as currently. If not set, uses ctrl-click to open URIs instead.
There is another bug with a similar request: https://bugzilla.xfce.org/show_bug.cgi?id=9166 I created a compromise patch that makes this an option.
I've just went to Button2-click on a URL in an IRC client, but the text scrolled by a line, a URL wasn't present, and I pasted something that shouldn't have been pasted. This is a broken UI. Please come up with a plan for how it can be fixed, e.g. Ctrl-Button2 click.
Tatu, patch merged as http://git.xfce.org/apps/xfce4-terminal/commit/?id=a3d06ff421f5ca555daf688b442d9dab8d094f23, thanks! I've changed the option name to MiscMiddleClickOpensUri for it's hidden.
*** Bug 7714 has been marked as a duplicate of this bug. ***
*** Bug 9166 has been marked as a duplicate of this bug. ***
The patch checks that Ctrl is pressed, but not that other modifiers aren't pressed, e.g. Ctrl-Shift-Button1 also works. Perhaps that's fine and in keeping with the rest of the UI. Just pointing it out.
Yeah, I haven't noticed that. Thanks Ralph! Fixed by http://git.xfce.org/apps/xfce4-terminal/commit/?id=bab1e53f6a82522c9d480b5353bd5644e34c198f
Actually. Now that this feature has been added, would it be impossible to add an checkbox into settings UI to toggle it on or off? Or even middle-click / ctrl-click / both -radiobutton? My original patch did not do it since it was just quick&dirty hack I used to apply this possibility directly to FreeBSD ports tree. But it seems many people would be interested in the option, so perhaps making it hidden was a bad idea.
Tatu, no, adding a UI setting is not impossible at all. Do you think a possibility to allow both middle click and Ctrl+left click would also be valuable? I haven't thought about that.
:) as for me, i would love to get rid of the 'middle click opens url' behavoir as its causing lot of accidental url opens during pasting with a middle click.
Another problem with Button2-click opening a URL is it breaks simple pasting into a terminal window. One now has to check what's under the pointer to ensure it's not a URL, otherwise that gets opened instead. And that URL might be NSFW, an unwanted action, e.g. unsubscribe, etc. If the browser is minimised then one might not even notice this has happened and that the paste hasn't, causing further problems down the line. It should be easy to paste several things into a target window, with the window being a big rectangular target, and without having to interpret each time the text in that window. It's an awful UI. I'd suggest changing the default, and having a non-UI option to have Button2-click be its current behaviour, documented in the release notes. It deserves to be buried.
Hmm, it appears that both other terminal apps I have installed on my machine - qterminal and gnome-terminal - are not opening URLs on middle click. This is a good reason for changing the default URL-open action to Ctrl + left click.
yay. Im all for it.
Well, this could be easily achieved by changing the MiscMiddleClickOpensUri default value to FALSE, keeping it hidden. Will everyone be happy with such decision?
Yes, very happy. If you're twiddling that patch again you might want to consider putting event->type == GDK_BUTTON_PRESS first as it avoids the more complex logic if that simple check isn't true.
You are right. I can even move g_object_get() inside the "if (event->type == GDK_BUTTON_PRESS)" block to avoid unnecessary calls.
http://git.xfce.org/apps/xfce4-terminal/commit/?id=f5f1927a35603ccb71cb5b486c9b8d09278bf540 makes the change. Thanks all!
thank you very much :) I owe you
After a system upgrade, middle-clicks on URLs do pasting instead. I thought there was something wrong with my system until I find this....It's more convenient once I get used to it. Anyway, thanks for keeping the old behavior available.
(In reply to lilydjwg from comment #21) > After a system upgrade, middle-clicks on URLs do pasting instead. I thought > there was something wrong with my system until I find this....It's more > convenient once I get used to it. Anyway, thanks for keeping the old > behavior available. All changes between the versions are documented in the NEWS file, might be useful to study it :)
Since an updating 0.6.3 -> 0.8.0 from the Debian repositories I can only open URLs from the right-click menu. Middle-clicking pastes (as expected) and Ctrl+Left Click does nothing. The modifier has some effect though as double clicking does not select the URL with it. Am I missing something? Any way to get some debugging output for this?
(In reply to xfce from comment #23) > Since an updating 0.6.3 -> 0.8.0 from the Debian repositories I can only > open URLs from the right-click menu. > > Middle-clicking pastes (as expected) and Ctrl+Left Click does nothing. The > modifier has some effect though as double clicking does not select the URL > with it. > > Am I missing something? Any way to get some debugging output for this? Weird, Ctrl+click works fine in my Debian installation. Does any of ~/.xsession-errors or ~/.xfce4-session.verbose-log contain any messages related to that?
Is something grabbing the Ctrl-Button1 click? I can confirm with xfce4-terminal 0.8.0-2 on Arch Linux that Ctrl-Button1 double-click on a non-URL doesn't select the word. However, on a URL it opens the URL twice. Perhaps run xev(1) and see if Ctrl-Button1 is reaching that?
Nothing shows up in the two log files when opening the terminal and trying to CTRL-click. xev looks fine to me. I'll attach the relevant part of the output. I can also CTRL-click in other applications, e.g. Firefox.
Created attachment 6882 relevant xev output
(In reply to xfce from comment #26) > Nothing shows up in the two log files when opening the terminal and trying > to CTRL-click. > > xev looks fine to me. I'll attach the relevant part of the output. I can > also CTRL-click in other applications, e.g. Firefox. Well... a stupid question: have you closed all terminal instances or rebooted your machine after upgrading to 0.8.0?
I figured it out. As you can see in the xev output (and I just "discovered" in gdb XD), my state is 0x14 which means GDK_MOD2_MASK is set beside GDK_CONTROL_MASK. I have no idea what GDK_MOD2_MASK actually is, but I think the check is wrong and you want to use gtk_accelerator_get_default_mod_mask() to ignore it, see https://developer.gnome.org/gtk3/stable/checklist-modifiers.html.
Use `xmodmap -pm' to see what keysyms are used for your `mod2', e.g. Num_Lock.
Yes, according to that my mod2 is numlock. I thought I already tested with disabled numlock as well, but now disabling it actually makes Ctrl-Click work in xfce4-terminal. :)
Caps lock also breaks the Ctrl-Click for me. You definitely need to apply something like gtk_accelerator_get_default_mod_mask().
(In reply to xfce from comment #32) > Caps lock also breaks the Ctrl-Click for me. You definitely need to apply > something like gtk_accelerator_get_default_mod_mask(). Yes you're right, thanks for noticing. I will follow your suggestion and fix the code.
Fixed by https://git.xfce.org/apps/xfce4-terminal/commit/?id=9777bcfca4b32ae6343e50a9e31b8085bcc34221
For future reference, folks, breaking people's working systems is a pretty bad idea. This change bit me, too. Next time you consider changing the behavior of something that people are using, it would be wise to leave the default as it has been for years, or if you absolutely must change the default, preserve the old behavior on existing installations.
Sorry you suffered, but the old behaviour was a very broken design for the reasons spelt out above. Bad enough that the default should change. And I suspect many existing users would prefer the new behaviour, but might not find out it was an option if it was left to them to change as the NEWS file often goes unread; again see above.
+1. Old behavior was all broken and Its been making people suffer for years. It will take a day for a person to adapt to a new behavior and finally start a new happy life.
> It will take a day for a person to adapt to a new behavior and finally start > a new happy life. In real life, new software versions land on great many people in batches, when OS distribution upgrades are installed. That means that all the workflow-breaking or system-breaking changes (like this one) add up, and it often takes a lot more than a few hours or days of work to troubleshoot and sort out. Multiply that by hundreds or thousands of users (sometimes at a single site) and you have an example of why it is a bad idea to break working systems. Of course, no single drop believes it is responsible for the flood, so I expect my comment here will fall on deaf ears, but please do at least consider it next time. At the very least, you could have exposed the option required to fix the breakage as an easily-visible menu item, rather than hiding it in as an undocumented config file option and burying the single mention of it in a text file that never gets shown to the user and is buried among thousands of other packages that get upgraded on a real-world system. Reminds me of a certain passage from a certain Douglas Adams novel. Anyway, this breakage is finally solved at my site. I hope you folks will tread more lightly on your users next time.
Hi Forest, As you may have noticed, there has not been a single vote against this change since the bug was created in 2014. Moreover, users of some distributions that are quicker to take upstream updates (such as Arch or Fedora, for example) have been living with this change for almost a year now - and again, no complaining. This is why I don't feel this change was wrong. On contrary, there were plenty of reasons for making it. Still, I think it makes sense to be able to configure this option from the UI - I will expose it to preferences. But I won't change default behavior, sorry if you don't like it.
"Hundreds or thousands of users" will not be accidentally pasting private material into windows because they missed the URL by a few pixels, or opening a (NSFW? Spam?) URL accidentally when trying to paste into a window, all without having to know of the configuration option and turning it on. Again, the above comments cover the configuration already existing, and it being kept out of the UI deliberately when its default value was changed. I too have spent time in the past investigation program behaviour changes on an upgrade, so I know it's tedious. This behaviour was too badly broken, in two ways, to leave users suffering. I'm sure the maintainer would consider each change's impact carefully in the future, but he did this time IMO. :-)
Hi Igor, > Still, I think it makes sense to be able to configure this option from the > UI - I will expose it to preferences. Is it worth it? As you say, some distros lag. Ones that don't will get the UI option promptly, but it will be a long time after the previous change so anyone that wants the non-default will have found the non-UI option by now. Distros that lag will have to wait a long time, just like they did for the first change, and the gap between the two from their point of view will be similar.
(In reply to Igor from comment #39) > As you may have noticed, there has not been a single vote against this > change since the bug was created in 2014. I don't imagine most users spend their days monitoring the bugzilla databases for all the software they use. That means we don't find out about a change until it lands in the distributions. This particular change didn't start to reach Xubuntu users until a month or two ago, and even then it was only the users who upgrade on the bleeding edge of availability. Those of us who wait a little while for the dust to settle in a new release are finding out about this only now. > Moreover, users of some distributions that are quicker to take upstream > updates (such as Arch or Fedora, for example) have been living with this > change for almost a year now - and again, no complaining. A quick scroll up shows me at least one other person who found their way here and took the time to communicate about the breakage. I'd say that's more complaining than none. :) > This is why I don't feel this change was wrong. On contrary, there were > plenty of reasons for making it. I don't feel the change was necessarily wrong, either. The mistakes were pushing the change out in such a way that it unexpectedly breaks working systems during upgrades, and exposing no obvious way to revert. When I make changes to software that people are already using, I take care to avoid this sort of instability. > Still, I think it makes sense to be able to configure this option from the > UI - I will expose it to preferences. But I won't change default behavior, > sorry if you don't like it. Thank you very much. That's all it would have taken in the first place to avoid this whole conversation.
(In reply to Ralph Corderoy from comment #40) > "Hundreds or thousands of users" will not be accidentally pasting private > material into windows because they missed the URL by a few pixels, or > opening a (NSFW? Spam?) URL accidentally when trying to paste into a window, > all without having to know of the configuration option and turning it on. Ralph, you have already made it clear that you feel solving a problem for one group of people justifies causing a problem for another group. I'm just pointing out that you can do better than this. Now that we have both shared our perspectives, let's avoid beating this horse any further, shall we?
> Moreover, users of some distributions that are quicker to take upstream updates (such as Arch or Fedora, for example) have been living with this change for almost a year now - and again, no complaining. I disagree, because I'm on Arch, and it took me a lot time to find this. I thought it was with other parts of my system because GTK 3 was doing breaking changes too. > "Hundreds or thousands of users" will not be accidentally pasting private material into windows because they missed the URL by a few pixels, or opening a (NSFW? Spam?) URL accidentally when trying to paste into a window The former doesn't happen to me, because I take the mouse cursor as a hint. However the latter happens occasionally. I do think the new behavior is better, but we should find a way to inform users of breaking changes. NOT in the NEWS file. Windows and Android and websites and Firefox addons usually pop up a window to do so, maybe xfce can do the same.