vercel / hyper

A terminal built on web technologies
https://hyper.is
MIT License
43.47k stars 3.52k forks source link

Dragging tabs not possible by preventing default on mouse down on Header #911

Open patrik-piskay opened 8 years ago

patrik-piskay commented 8 years ago

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 commented 7 years ago

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

nkkollaw commented 7 years ago

Yes!

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

andradei commented 7 years ago

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

Spaxe commented 7 years ago

Why are we voting down a +1 vote?

chabou commented 7 years ago

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

Arrow7000 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Any chance this could get looked at?

chabou commented 7 years ago

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 commented 7 years ago

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

nkkollaw commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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. image Highlighted area is usable for moving the window. image

hpohlmeyer commented 7 years ago

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.

move

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 commented 7 years ago

@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 commented 7 years ago

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:

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:

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

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 commented 7 years ago

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 commented 5 years ago

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 commented 4 years ago

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.

digitaljhelms commented 2 years ago

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.

@hectorqin curious, what's the difference between your plugin and what @patrik-piskay published 3 years prior to your comment? Your plugin uses the gif from @patrik-piskay as well, but I don't see yours is a fork of his.

JJJ commented 2 years ago

@hectorqin curious, what's the difference between your plugin and what @patrik-piskay published 3 years prior to your comment? Your plugin uses the gif from @patrik-piskay as well, but I don't see yours is a fork of his.

Perhaps oddly, at least for me on macOS, neither plugin appears to work as advertised 😅


I would like to see shortcuts added for an underlying API to allow for moving tabs left/right, to match "Select Tab" and "Select Pane". In addition, the core code should unblock the ability of plugins to jazz up their own styling & implementations, so tab reordering can be customized the way that Tab & Pane Selection can be. Anything more in Hyper core starts to be more opinionated than is necessary to coincide with the projects core goals. 💞

hectorqin commented 2 years ago

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.

@hectorqin curious, what's the difference between your plugin and what @patrik-piskay published 3 years prior to your comment? Your plugin uses the gif from @patrik-piskay as well, but I don't see yours is a fork of his.

Yes, it's based on @patrik-piskay, and i fixed some bugs. To publish npm package, i push the code directly not fork his.

hectorqin commented 2 years ago

@hectorqin curious, what's the difference between your plugin and what @patrik-piskay published 3 years prior to your comment? Your plugin uses the gif from @patrik-piskay as well, but I don't see yours is a fork of his.

Perhaps oddly, at least for me on macOS, neither plugin appears to work as advertised 😅

I would like to see shortcuts added for an underlying API to allow for moving tabs left/right, to match "Select Tab" and "Select Pane". In addition, the core code should unblock the ability of plugins to jazz up their own styling & implementations, so tab reordering can be customized the way that Tab & Pane Selection can be. Anything more in Hyper core starts to be more opinionated than is necessary to coincide with the projects core goals. 💞

Maybe you can find some plugin else, since i'm not using this terminal for a long time.