Terminal Data Entry And Keyboard UI/UX improvements

[davidrenne]

Discord username (optional)

No response

Describe the solution you'd like?

Here's the basic issue with this terminal that is super annoying compared to any standard terminal and it can be improved so easily in your source code.

There is such a small hit box to land inside your terminal space to enter in new commands.  Make it so you can drag an adorner of some kind and configure and stretch the height of the entry of where you enter your commands.  Its hard to get your mouse in a hit box of 75 pixels so I can run my next command.  This would improve area height to click and users can scroll higher to see more output of previous commands

You have to remember that every terminal always is ready to accept the next command, but yours is different with the output grouping and as you are interacting with it and ALT-TABing with a mouse, you most likely will select the output which is a problem (most people dont care about copying the output of the last command, they are trying to send another command).  So I would say that after the application is out of focus, always focus the caret into the command execution 75pixel area so they can just type and not have to move the mouse down to the small hit box to actually run a command.  So even if an output was previously selected, unselect it and focus on the entry of a new terminal command.

I shouldnt have to write scripts against your terminal to make the user experience better, this needs to be done ASAP.

Next, for output of each command above there, Its neat how you can use the up arrow to select commands to either copy the command and its output, but the problem with this is when you hit the bottom of the stack and you are pressing down key, it should focus the area of your command so you can enter another command easily.

With these simple UX improvements my workflow will be vastly improved and I my hatred of using it when these problems arise will begin to wane.

Is your feature request related to a problem? Please describe.

No response

Additional context

No response

How important is this feature to you?

5 (Can't work without it!)

Warp Internal (ignore) - linear-label:770f6576-d6c0-4e4f-a259-fc64b5156087

No response

[elviskahoro]

There are a couple keybindings that can help. CMD-L focuses the Input Editor. CMD-Down is what you can use to return back to the Input Editor once you've hit the bottom of the Block list. Or CMD-L, should work anywhere except for when dialogs are in view.

I'll share over any updates from eng when there any.

[davidrenne]

Thanks for the support and knowledgebase, but still this is bad UI/UX. If stdout stderr is focused previously and you tab to another app, the input should be ready to accept new commands.

Why would I have to enter CMD+DOWN when there is nothing left in the stack pressing down should basically be smart enough to jump to the input editor.

Can you take these into account and think about making adjustments? Also the size of the input editor is very small, it would be ideal to make this configurable for long commands its very small to even read what command you are sending.

[blakewatson]

I have a similar problem. What happens is I run a webserver that gives me back a local URL I can click on. So I do that (this is one of the cool features of Warp—the little popover that lets me follow the URL).

After doing some development for a time, I will flip back over to the terminal and hit ctrl+c to stop the server. But the focus is somehow not right. I have to click again somewhere in the output to get the keyboard focus to be right.

I assume clicking the URL popover is somehow moving the keyboard focus from where it should be, but this isn't obvious.

I basically just have to click somewhere in the output to get the focus back. But like I said, that isn't obvious.

[davidrenne]

@blakewatson precisely why I uninstalled the app. A few of my git issues were enough. Still some UI issues to make it feel like a normal terminal. Once these few are closed I will try it out again. This one is plain annoying. The focus of a terminal is not previous output, its new input. So it should be focused when you come back to it. Even if I navigated to some output block it should put the cursor ready for commands in the input box when I focus back to the app.

[blakewatson]

@davidrenne Yeah I agree. I mean I can see how it got in its current state—being able to interact with blocks of output is a unique UI pattern and does change how things work.

But like you said, when one flips over to their terminal, they (I believe correctly) expect to be able to start issuing commands—especially if there’s a running process.

[suranyami]

Gotta say I 100% agree with this issue. It's a constant daily frustration with me and it's only the fact that I like everything else about Warp that keeps me using it.

The baffling thing for me is, I can't even reproduce when text-focus is lost. At first I thought it because I was clicking on blocks, then I thought it may have been mouse-hover, but I've never been able to reliably determine what action will cause it.

I have to solidly reiterate with the OP: text input on an active pane should never be blocked!

I honestly can't imagine any situation (except for a modal dialog) where I would ever want my text input to be ignored.

Can the authors explain how or why this constantly happens? To me, it seems like a bug.

[davidrenne]

Thanks for reading @suranyami and agreeing. I'm enjoying iterm until this is closed. They lost a customer because of this bad UX

[blakewatson]

@suranyami @davidrenne Yeah, I switched back to iTerm as well. But Warp was cool in other ways and if they can ever get this sorted I would be willing to give it another try. But yeah, after a dozen false starts—focusing Warp, starting to type, and realizing nothing is happening—I had to go back to iTerm.

[davidrenne]

@elviskahoro any response to recent comments about this issue? Can it be escalated further?

[zachbai]

Hey all -- we actually shipped a relevant fix but looks like we lost track of this specific GH issue.

If you switch focus to a different window and switch back to Warp, the input editor is focused. @blakewatson I just verified that this should work when in the middle of a long running process (like when you click on that local server URL and then switch back to Warp). Let me know if this is not the case.

The exception is if you previously had a command/output block selected/highlighted, we keep focus on that block when switching back to Warp. The rationale is that selecting a block is an explicit action, so we believe you'd expect that resulting state to be maintained across focusing multiple windows.

[davidrenne]

@zachbai why can't we just make a settings flag to disable your default behavior of keeping a block highlighted for those who want to send commands. You'd be surprised at the analytics of usages of people who want to alt tab out of the command prompt and be able to enter commands (JUST LIKE EVERY OTHER TERMINAL KNOWN TO MAN EXCEPT WARP!) . No one cares about stderr or stdout of blocks in a terminal only to view them. If I click a block it's usually to copy and I maybe lose focus of the warp terminal. When I go back it's ready to accept commands based on this setting I turn on to override this desired default behavior. People click things a lot, it doesn't mean they necessarily want to perform an action. They may just want the highlighted styling of the last known stdout stderr.

[davidrenne]

@zachbai im not going to press a cmd hot key to give focus to the most important thing of a pty session, input from my damn keyboard to send commands. Output is always secondary and is in the past.

I'm not sure who I need to shake at warp to make them realize that past output blocks are nice. But a terminal tty session is to map my keyboard to an operating system shell environment with keyboard input.

[suranyami]

This latest release seems to have delivered this fix for me (macOS 13.4.1).

Awesome work!

[davidrenne]

@suranyami on build v0.2023.08.15.08.03.stable_00 I verified that when I type, the last known warp window does accept keyboard input, @zachbai the only bug is that the carrot is missing so I didnt think the feature was working. Can you make a hot fix for this too? It just overall lets the developer know what warp window they last touched and is ready to type in commands.

Great work! I am baaaaack!