Hyper: Dragging tabs not possible by preventing default on mouse down on Header

[patrik-piskay]

Hi,

this line prevents drag&drop API from working on anything inside Header component (in my case, it's tabs).

This is blocking https://github.com/patrik-piskay/hyperterm-tabs/issues/6 and it was working correctly until 0.8 (this release introduced the ev.preventDefault() line). Is there a better solution or at least a possibility to override the default onMouseDown handler?

I am happy to submit a PR that will fix this, just want to discuss possible approaches.

Thanks!

[eamodio]

It would be great to have this resolved -- it is one of my only gripes with hyper.

[nkkollaw]

Yes!

I'd gladly switch to Hyper if I was able to reorder tabs.

[andradei]

And color them for that matter. It is a great feature to organize different shells.

[Spaxe]

Why are we voting down a +1 vote?

[chabou]

Maybe because 'reactions' are a better way to express a vote/feeling

[Arrow7000]

Because you can just add a thumbs up to the original comment, adding a separate comment purely to say '+1' doesn't add much.

[andradei]

And you can also subscribe to this issue, increasing the list of people interested, which draws developers attention when looking for features its community wants. At least it makes easier to get the conversation started than doing +1s like on old forums.

[Stanzilla]

Any chance this could get looked at?

[chabou]

In order to achieve this, we must find a compatible solution that let user moving the window even when clicking on tabs.
What do you think to apply onMouseDown default only after a delay without any move (~500ms)?

[Stanzilla]

Why do window and tab header have to be the same though?

[nkkollaw]

In order to achieve this, we must find a compatible solution that let user moving the window even when clicking on tabs.
What do you think to apply onMouseDown default only after a delay without any move (~500ms)?

Too slow.

CTRL + drag = reorder tabs, drag = move window.

[ELLIOTTCABLE]

I'm in agreement on a delay being a terrible solution … if it's invisible. That is, not a behaviour that's surfaced, visually, to the user.

Here's my thought: on click and quickly drag, the whole window moves. But, if the user clicks, and holds the mouse in the same (approximate — 5px diameter, maybe?) place, then we “attach” the tab (as opposed to the window) to the user's mouse-cursor. Crucially, this should be visible-and-obvious to the user — to make this behaviour discoverable.

For instance (and this is hard to describe without me simply implementing it, but I'll take a stab) … the user clicks a tab, holds, after 750ms, the tab's entry on the tab bar brightens and slightly shrinks towards the mouse — maybe by 10px on each edge? — indicating that the user has ‘picked up’ the tab. Then, they can drag the tab around; detaching it from the window to spawn a new window, or seeing a highlighted ‘insertion’ bar between two existing tabs as it's dragged around.

(This is all fairly similar to the behaviour of chrome, bar the described delay — I hate having to find the very tippie-top of the actual menubar in Chrome before I can drag the window, so tbh, Hyper's behaviour would be a step up, imho.)

[Zodiase]

In order to achieve this, we must find a compatible solution that let user moving the window even when clicking on tabs.

Why is that still a requirement when the tab thingy (and its behavior) is becoming a de facto design since macOS Sierra (e.g. in Terminal, Finder, Safari)? Maybe that doesn't apply to Windows and Linux but... meh :p.

If the tabs are covering too much real estate, causing users unable to find a spot for moving the window, then don't make it so. Leave some space around the tabs for moving the window. I use many apps that adopt this design and so far I don't find it troubling.

Leave margin around tabs.

Highlighted area is usable for moving the window.

[hpohlmeyer]

How about enabling drag and drop of tabs through the config for now?

Atom has the option of disabling the default mac application bar, which will leave you with the same problem. However, you can move your window at any time if you go to the side of the window and drag in the opposite direction of the arrow.

If you can enable it in the config, you should be aware of the downsides, but you are still able to move the window.

[ELLIOTTCABLE]

@Zodiase :-1: on this — small click/drag targets, like the tiny area of the top bar not covered by tabs in your example, are a UX antipattern, and an accessibility problem to boot. (Same response to @hpohlmeyer's comment about the macOS trick of dragging window-edges orthogonally to the direction-of-resize — the edge is a tiny target, for such a common operation as moving the window.)

Both are better than the current behaviour, but I still think something more user-friendly is possible (even if you don't like my suggestion above 🤣)

[Onfire7]

While I don't think that it's a bad idea to put the tabs in the menu bar, though I do think it's very bad how it is implemented currently...

Hyper appears to have tabs in different places on different platforms. This whole issue is irrelevant on Windows, which has a separate title bar and tab bar. Effectively making drag and drop reordering (which is beyond a UI standard for user generated application tabs now, it's expected by users) not being available on Windows for reasons that are completely irrelevant to Windows users. As a new Hyper user I feel like I'm getting the middle finger from the UI as it's one of the few areas that apparently even plugins can't be used to fix...

So, taking into account everything that has been mentioned here, and the principle of least surprise, I propose the following guidelines:

• There must be enough room to grab the window:
  
  
  
  • Small drag targets are annoying, and an accessibility nightmare.
  
  
• Users must be able to reorder the tabs with drag and drop.
  
  
  
  • Almost all modern applications with user-generated tabs allow users to re-organize tabs with drag and drop, without holding a key, and without delay. This is the least surprising behavior for dragging a tab.
  
  
• Moving the window by its tabs is counter-intuitive:
  
  
  
  • It contradicts the least surprising behaviour of reordering a tab, and could be very surprising to a new user...
  
  
• Application UX must be consistent and so it should either:
  
  
  
  • A) Be the same experience across all platforms (All tabbars on the titlebar or all under it.)
  
  
  • B) Follow the UX standards of each operating system to the letter. (Tabbars implemented the same way as the apps that ship with the OS by default.)
  
  
  • C) Create an option and let the users decide.
  
  

With those guidelines I only see 2 viable options for fixing the tabs, and 3 ways to implement them:

Application UX should be consistent across platforms and so the interface should either:

• Implementation 1) Be the same experience across all platforms (All tabbars on the titlebar or all under it.)
• Implementation 2) Follow the UX standards of each operating system to the letter. (Tabbars implemented the same way as the apps that ship with the OS by default.)
• Implementation 3) Create an option and let the users decide, with implementation 1 or 2 as a default.

Fixing the issues of not being able to drag both the window and the tabs should be fixed by:

• Option A) Have the tabbar a part of the titlebar:
  
  
  
  • Add a large space (75-100px) between the titlebar buttons and the tabs to drag the window.
  
  
  • A new tab button can be added to help fill some of the extra space and can still drag the window.
  
  
  • A small space between the top of the tabs and the top of the titlebar can be added, increasing the height of the titlebar if necessary. (Primarily for dragging the window when it is fullscreen...)
  
  
  • Dragging tabs should reorder them, and dragging them outside of the window, should create a new window and move it there.
  
  
• Option B) Move the tabs below the titlebar.
  
  
  
  • If option A has a new tab button, then this one should have one too.
  
  
  • Dragging tabs should reorder them, and dragging them outside of the window, should create a new window and move it there.
  
  

I think tabs in the titlebar are great, but you can't have your cake and eat it too, and frankly, dragging tabs to reorder is a FAR more established UI practise then having tabs in the titlebar is, so if Option A can't be made to give as much room as you would like to drag the window, then B must be implemented for all platforms...

[ELLIOTTCABLE]

Although I had some trouble parsing through most of @Onfire7's suggestion, what looks like the ‘meat’ of it is definitely :+1: from me:

• Add a large space (75-100px) between the titlebar buttons and the tabs to drag the window.
• A new tab button can be added to help fill some of the extra space and can still drag the window.

Also, explicit :+1: from a macOS-exclusive user, on doing whatever is necessary to make the app fit-in on Windows! (Having had the experience of using designed-for-Windows-and-then-ported applications on Macs, back in the day, I'd really like to avoid “exporting” that shitty experience back to Windows in 2017! 🤣)

One particular note, from my rather-vague knowledge of Windows 10 / fullscreen: iirc, it's a common operation over there to use the infinite-target of the screen-edge for resizing windows? (“Throw” a window that you're dragging to the top of the screen to make it full-screen; then click up there and drag back down to restore it to its original size?) If so, then it sounds like we do need an additional, thin, draggable area at the top, even if we also have the large click-targets on the left (traffic lights) and right (new tab), so that the target for un-fullscreen'ing on Windows becomes effectively infinite?

Here's my terrible mockup:

┌────────────────────────────────────────────────────────────────────────┐
├─────────┬──────────────────┬──────────────────┬──────────────────┬─────┤
│         │                  │                  │                  │     │
│ ▢ ▢ ▢   │      $ foo       │      $ bar       │      $ baz       │   ✚ │
│         │                  │                  │                  │     │
│         └──────────────────┴──────────────────┴──────────────────┘     │
│                                                                        │
│                                •                                       │
│                                •                                       │
│                                •                                       │
│                                                                        │
│                                                                        │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

---

I actually want to bring up a closely-related, but slightly tangential, issue, while we're here.

One of my favourite, extremely subtle, but amazingly helpful, things about Safari (as opposed to Chrome), is how it handles closing tabs:

When opening new tabs in Safari, the current set of tabs is always the full width of the window. (i.e. they're stretched out, and the stretching is dynamically adjusted to fit all of them equally.) Correspondingly, if you close the last tab, they immediately re-size to remain full-width (showing you as much of each title as is possible.)

However, if you click the [x] to close a tab in the middle of the tab-set, they do not immediately resize themselves to fit, again! The tabs stay exactly the same size they were, for a moment¹. In particular, this means that the next tab to the right has now shifted left, and the [x] button of that tab is now underneath your cursor.

This has the effect that you can quickly close a bunch of sequential tabs, easily, by hovering over the first one you want to close, and then spamming the mouse-button: as you move your mouse around, the close-button targets won't re-arrange themselves out from under you!

1. (They actually, it turns out, re-arrange themselves as soon as you move your mouse out of the tab-bar. This makes the above effect almost unnoticeable, when closing a single tab and returning the mouse to the viewport.)

I'd love to see this behaviour duplicated, if we're re-implementing resizing/closing/dragging of tabs, in Hyper.

Hope that's welcome input!

[hectorqin]

I've submit a PR to solve the problem. And with the hyper-reorderable-tabs plugin, we can drag to reorder tabs and drag the window.

[LeandroVCastro]

I've submit a PR to solve the problem. And with the hyper-reorderable-tabs plugin, we can drag to reorder tabs and drag the window.

This solved to me. Thanks.