Hyper: Mouse over instead of click to select terminal

[radare]

• OS version and name: OSX 10.11.6 (15G1108)
• Hyper.app version: Version 1.0.0 (1.0.0.1303)

Having to click to select a different terminal is somewhat anoying, i think mouse over should be implemented and enabled by default

[timothyis]

I assume you mean the split panes? I don't think this is a good idea. Terminals are based a lot on the text input of users. Mouse hover to change focus could be _extremely_ annoying.

_Side note:_ you can use keyboard shortcuts to navigate the panes.

[kleinfreund]

I highly doubt this would be an expected interaction for the majority of users. I don’t like it.

[radare]

Well thats my default config in all my machines and i use the shell everyday for already so many years. Its the behaviour for plan9, and its a feature supported in iterm, twm, dwm, terminator and many other window managers and terminal apps.

Despite not liking you its a useful feature already used by tons of users. But maybe i'm too old and doing unnecessary steps to achieve something bores me

On 13 Dec 2016, at 08:43, Philipp Rudloff [e-mail] wrote:

I highly doubt this would be an expected interaction for the majority of users. I don’t like it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[OJFord]

doing unnecessary steps to achieve something bores me

Then don't use the mouse at all, in favour of the keyboard shortcuts. (cf. #828)

I tried mouseover to switch pane for a while, but found it happening accidentally far too often, and if I'm already moving my finger adding a tap at the end isn't a big deal.

[radare]

you dont have keybindings in plan9. and yes, keybindings will be nice too, but im used to the touchpad because im 99% of my time in a laptop and find it handier to use hover than having to click all the time. i don’t see why this is a problem at all for all you. even having this feature as an option even if not enabled by default.

On 13 Dec 2016, at 14:50, Ollie Ford [e-mail] wrote:

doing unnecessary steps to achieve something bores me

Then don't use the mouse at all, in favour of the keyboard shortcuts. (cf. #828 https://github.com/zeit/hyper/issues/828)

I tried mouseover to switch pane for a while, but found it happening accidentally far too often, and if I'm already moving my finger adding a tap at the end isn't a big deal.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/zeit/hyper/issues/1143#issuecomment-266743075, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-luElryBXOijRAScEIh6nVvz6p5p2ks5rHqKygaJpZM4LLGSF.

[Asuza]

I started using mouseover focus in my OS recently, and quickly learned to love it. Having the ability to mouseover a pane to focus it would be a nice to have, but it should not be enabled by default. As far as I'm aware, most people don't use that behavior.

Is this perhaps a feature that could be implemented via a plugin?

[iamstarkov]

dont implement this pls

[OJFord]

@iamstarkov There's no harm in it being implemented as an option or plugin, but I agree it would be a surprising default.

[timothyis]

I agree, this is much better supported as a plugin. The reason for Hyper having plugins is so that use-cases like this can exist without extending Hyper's codebase and not bloating all user's config files with an extra option.

[timneutkens]

I agree, doable as plugin 👍

[albinekb]

Yeah, this should definitely be a plugin 👍 and as @CodeTheory that's the reason Hyper supports plugins!

If you can't do it yourself, I could take the time to do such a plugin for you 👼

[iamstarkov]

@OJFord such default is not good, but as a plugin its totally fine 🎉

[timothyis]

@radare I think the people that have commented here can clearly represent the Hyper community. Are you happy with it being a plugin? @albinekb's offer is amazing 🙌

[radare]

I dont care if its a plugin or an option disabled by default. I just think this is a vital feature for my workflow in all machines i use. And was the first complain after testing it.

I will obviously prefer this behaviour as an option rather than a plugin and i dont think implementing this could take more than 10 lines of js. And i dont think this should be any problem for hyper which is already bloated in design already.

Up to you

On 14 Dec 2016, at 20:20, Timothy [e-mail] wrote:

@radare I think the people that have commented here can clearly represent the Hyper community. Are you happy with it being a plugin? @albinekb's offer is amazing 🙌

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[kleinfreund]

I will obviously prefer this behaviour as an option rather than a plugin and i dont think implementing this could take more than 10 lines of js. And i dont think this should be any problem for hyper which is already bloated in design already.

@radare Why are you "obviously prefer[ing]" this as an option instead of a plugin? The outcome for you would be virtually the same. The argument to not bloat the code base with all kinds of features is a sensible one. The argument that an already bloated app is safe to bloat even more is not.

[timneutkens]

@kleinfreund @radare also, would like to know what is bloated about the design @CodeTheory could give insight into it 👍

On topic: I don't like the I want this. I want it now. And I'm not going to build it myself attitude, we're all doing this for fun, not profit. We're not getting paid to work on Hyper, but we still do out of passion for the software and the ideas behind it. When you're saying it will not take more than 10 lines of code to implement, why haven't you done so already in a plugin? 🤔

Just my thoughts on the subject. ❤️

[albinekb]

@radare
To add to @timneutkens's answer:

.. and i dont think implementing this could take more than 10 lines of js.

If we thought that for every little thing like this, it will end up bloated/even more bloated.

And i dont think this should be any problem for hyper which is already bloated in design already.

We're actually going leaning towards have most of the functionallity in core:plugins, like atom does

Therefore, it's a smart move to start doing stuff like this as plugins now, and not needing to take it out and then we need to make it a plugin later.

Does that answer your question(s)?

[timothyis]

So, I think we've gathered the majority opinion from those who want to respond to this issue and I believe we'll just argue about it more if we continue to go on.

As @albinekb said; Hyper is starting to go into the direction of core plugins, like atom. So, in the future, we will push for any functionality to be inside a plugin. For things as this suggestion, which is apparently a uncommon preference, we're going to suggest that they be third party plugins since that's why we have a plugins system in the first place.

If you say that Hyper's code is bloated, why even add 10 lines of JS rather than trying to contribute with a third party package that's entirely optional? That's nonsensical to me.

What I suggest is that you either create the plugin yourself, if you know it's going to take only 10 lines of JS, or accept the very kind offer from @albinekb to create the plugin for you.

Thanks for your issue, please submit another if you have any more and we will take it into consideration just like this one.

[albinekb]

And as i said, I'll happily make this plugin for you! 🎉

Lastly, I feel like this discussion went out of hand, but remember: No hard feelings 💓

[radare]

Also a way to visually determine which terminal have focus (with a colored border or a dimmed/greyedout filter on the non focused ones) will be good. The cursor is not the best way for the eye to find which terminal is focused

On 14 Dec 2016, at 20:20, Timothy [e-mail] wrote:

@radare I think the people that have commented here can clearly represent the Hyper community. Are you happy with it being a plugin? @albinekb's offer is amazing 🙌

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[radare]

Why is this issue closed now? Is there another repository to hold the issues for plugins? should i assume @albinekb is working on this? because he hasn't been assigned to the issue? no hard feelings, im just shocked by the way you manage issues.

[OJFord]

Why is this issue closed now?

Because it's a plugin request that @CodeTheory decided should be third-party - which I take to mean "PR welcome, but no need to keep this issue open".

@albinekb has very kindly to be said third-party for you; I for one am very appreciative of the work he and others put into Hyper, even if some of it's on plugins for features I won't use.

Also a way to visually determine which terminal have focus (with a colored border or a dimmed/greyedout filter on the non focused ones) will be good. The cursor is not the best way for the eye to find which terminal is focused
should i assume @albinekb is working on this? because he hasn't been assigned to the issue? no hard feelings, im just shocked by the way you manage issues.

You'd do well to say 'thank you', and keep quiet while waiting patiently now.

[rauchg]

We're working on creating a GitHub project to hold the plugin ideas. We'll update the README when we do so ❤️

[ppot]

@radare For terminal focus it was already addressed: https://github.com/zeit/hyper/pull/905

[dimitrieh]

@albinekb just reading about this discussion now, would love to have this functionality be available as a plugin! perfect 😄

is it already available?

[radare]

i have downloaded latest Hyper and checked all the HPM plugins, but i can't find the plugin that allows to change focus on mouse over instead of having to click to select a different panel. Am I missing something?

[woyczek]

Hello. Just a post-mortem point on this conversation, about the “I don't think users will agree with this feeling”.
Mouse focus is the standard behaviour in many windowed environments, Unix being the first of one, Linux (before Gnome/KDE environments) but so is NeXTstep (and openstep of course), MacOS beautiful iTerm2, and even Windows with the X-Mouse microsoft supported registry hack.
On MacOS, without stealing the focus, the mouse scroll is applied on the mouseover scrollbar.
Every shell user would be able to use, at least once in his computer life, a mouse focus aimed environment.
So, regarding those historical en environmental considerations, the mouvever trick would be a great default feature.
Regards,

[chabou]

hyper-pane has this feature now with its config param: focusOnMouseHover
Enjoy