hyper
hyper copied to clipboard
Not possible to rearrange tabs by dragging
The whole Hyperterm window is moved when dragging a tab with the mouse.
Version: 0.2.1
(I'm filing a bunch of UI stuff now, to keep track of them. Can be triaged).
Yep. This is gonna be a tricky one. I'm thinking about a "3d touch" / prolonged click and hold type thing where the tab will become manageable to drag around.
I believe that if we constrain ourselves to the HTML5 API, it should be possible to "receive" it in other windows in fact :)
Might be some learnings in here: https://github.com/atom/tabs
Yeah, I would have a short delay and then have the grabbed tab visually pop out somehow to indicate to the user that they are dragging the tab now.
Is there already a command to do this via keyboard?
I've just published a plugin for tabs drag&drop - https://github.com/patrik-piskay/hyperterm-tabs
Unfortunately, I had to set the title bar to be visible as I wasn't able to make it work without it (and still have the possibility of moving term window around). I've tried the approach of a long click that would make the terminal window not movable (and tabs drag&droppable) but it wouldn't take effect until after mouse button was released - probably an OS constraint but if somebody will find/know a solution for it, let me know!
Fixing this should be a priority.
I went back to iTerm just because of being able to rearrange tabs, which I do often.
Otherwise the project is awesome.
hyper-term-tabs has this feature.
Hi @chabou, it used to have this feature but Hyper v0.8 made it not possible anymore. I've opened an issue for that in this repo. So currently hyperterm-tabs
supports tabs reordering by keyboard shortcuts only, no drag&drop at the moment.
Ok. Maybe it should be a core feature
Problem is: how to have tab dragging and not impacting window dragging. Add margin is not ideal. Maybe enable tab dragging after a long (~500ms) press?
It might make sense exploring the -webkit-user-drag property.
If I understand how it works, if you have:
<ul class="tab-bar">
<li class="tab">Tab 1</li>
<li class="tab">Tab 2</li>
</ul>
And you do:
.tab-bar {
-webkit-user-drag: .tab
}
Dragging would work on the tab instead of the tab bar.
I don't know much else about it, though. Is there someone smarter than me that can give it a try?
Might as well toss an opinion in here: maybe option-click could reorganize tabs, while regular click just moves the window?
Very nice. I personally rarely reorganize them, but it's frustrating not being able to do it when I do want to do it.
@chabou
Problem is: how to have tab dragging and not impacting window dragging. Add margin is not ideal. Maybe enable tab dragging after a long (~500ms) press?
You can find possible solutions (UX-wise) over here: https://github.com/zeit/hyper/issues/911#issuecomment-333417354
Thanks for linking the related issue @mischah.
Really looking forward to this feature!
I would be satisfied if I could even right click on the tab and "move left" or "move right". It would be tedious but it's better than nothing! 😄
Check out Firefox. It has tabs in the chrome, but there's still room on either side of the tabs to grab the window itself.
It's really unbelievable that you guys are still talking about this, like Hyper was the first software to use tabs.
What is there to talk about? Either Hyper devs want to support this feature, or not.
@nkkollaw I'm scared to even request being able to tear off tabs as new windows, preserving the session hosted by the tab.
I think this is a perfect example of how inefficient FOSS is when there is a decision to make.
It's tabs.
- every browsers has tabs
- every terminal in existence has tabs
- file managers have tabs
- Hyper: "mmm... how should tabs work? Wow can we both have tabs and drag the window at the same time? Let's think about for a few years
Haven't touched Hyper since 2016 mainly for this reason. I could use tmux
to solve this, but meh. iTerm is a great terminal.
This is a great project, however, a terminal powered by web tech can do amazing things.
@andradei : same here.
I tried again yesterday to see if it was fixed, I'm just posting here because of that. It's really a pity, because otherwise it looks really good.
I'll try again in 2020 or something.
Well it is marked 'help wanted', meaning they'll accept a pull request, and since this is OSS, the people that want it most should do the work when possible. The maintainer(s) is not obligated to fulfill every request in x amount of time, or ever.
This is a legend, @knownasilya.
First of all, a huge number FOSS projects are sponsored by a big company that pays people to develop it.
Even when this is not the case, it's not a democratic process. If the devs don't want to do something, they won't merge the request or they'll merge it and not maintain the feature, and the only way to do it is forking. That's why you have so many forked projects.
Not to pile-in on the discussion too much, but there's a huge number of unresolved or stuck PRs. There seems to be quite a bit of churn in making concrete progress, exacerbated by a lack of automated testing (and thus confidence) in some key areas. These aren't easy problems to solve, but it's definitely bigger than just opening PRs :smile:
@knownasilya I agree the maintainers don't have any obligation to tackle this issue, I'm not mad at them. I'm rather amazed at the project actually. I also want this feature and wish I had the time to learn how to contribute. It is clear that the maintainers have other priorities and that's how it should be. So I'll check next year to see if the feature has been implemented.
I also suggest that people that want this feature badly recognize a few things:
- This project is awesome, that's why you want your favorite features in it so badly
- FOSS are great just by making code available in general, authors have a life and don't have to answer ASAP to every issue
- Don't be mad at authors who give code to you for free, even when the code is incomplete
What's going on with this political correctness, @andradei? Everyone knows that FOSS devs are not under any obligation, we don't have to compliment them every time an issue is opened.
The point is just: is this "WONTFIX", or not. It's just crazy to keep talking about how tabs should work when hundred of apps have been using tabbed content for years.
EDIT: "WONTIFX", or "sooner or later" is fine, too, or "fuck off we don't want to", just not "but... should we long-press for tabs? Otherwise, how do we not drag the whole window?". That's my point.
@nkkollaw I agree with you about
The point is just: is this "WONTFIX", or not. It's just crazy to keep talking about how tabs should work when hundred of apps have been using tabbed content for years.
But disagree with
What's going on with this political correctness, @andradei? Everyone knows that FOSS devs are not under any obligation, we don't have to compliment them every time an issue is opened.
I'm not being politically correct. I've stated the issue and my frustration while deliberately showing gratitude for this project existing. I don't compliment them because I have to, but because I want to. Even if that's not directly related to the issue.
@andradei
I'm not being politically correct. I've stated the issue and my frustration while deliberately showing gratitude for this project existing. I don't compliment them because I have to, but because I want to. Even if that's not directly related to the issue.
Jesus Christ, man! Whatever.
Is this labelled "Wont fix" by the maintainers, I am wondering because I have my hopes up?