Open in new tab vs open in new window

[hanse]

For some workflows I find it more convenient that the workflow opens in a new tab instead of a new window if there is already a window open.

I don't need this to be the default, but I'm thinking this can be an opt-in for supported applications by passing an openInNewTab flag or something.

Motivating Example

I'm already in an iTerm window and run workflow. I want the new iTerm panes to open in a new tab in the same window that I'm in rather than a new window.

export default render(
  <Workspace name={'example'}>
    <Chrome url="http://localhost:3000" openInNewTab />
    <ITerm openInNewTab>
      <SplitH>
        <SplitV>
          <Vim file={__filename} />
          <Terminal cwd={'~/dev/github.com/hanse/pace-calculator'} cmd={'git status'} />
        </SplitV>
        <SplitV>
          <Terminal
            cwd={'~/dev/github.com/hanse/pace-calculator'}
            cmd={'yarn start'}
          />
        </SplitV>
      </SplitH>
    </ITerm>
  </Workspace>
);

I can work on an implementation of this (at least for macOS). What do you think about adding this as an optional feature for certain workflow-app-*s?

[havardh]

This is actually a simplified step in the direction (albeit not the exact same direction) that I want to take workflow. I believe this functionality is much easier to achieve on certain apps on OSX than on windows or linux-i3.

My goal is to make workflow a complete declarative windows manager. In this entails figuring out and doing the minimal amount of work to navigate from one flow to the next. In your example you want a new tab in an already open Terminal, but in general this is about talking to individual apps which are already open, and making them apply the desired layout. Now I have a few PoCs on this, but it is going to require some time, thus my focus has been on always opening new apps.

There is only one question I have to your proposal. Your example contains an iTerm instance with two terminal windows, and a vim instance. And you where executing this in a terminal. Are you expecting the above execution to result in three open terminals and one vim instance? The question is really about are you expecting the flow to be declarative of the expected result or if it needs to take the context into account.

I'd be happy to work with you on adding this functionality to workflow. In fact this actual proposition should not be too much work to incorporate. I really do not see a future where there is complete feature parity on all platforms, and I rather want to build a fondation where anyone can build what they want/need. Depending on your answer above I would want you to consider naming the flag useExistingApp or something a long those lines.

[hanse]

Let’s say I’m playing around in my terminal doing something random, and then I suddenly fell an urge to work on a specific project that has a defined workflow. It would be nice if I could just run workflow ProjectName and have it open its iTerm-stuff in a new tab in the same window I was initially playing around in.

See this (incredibly large) GIF to get an idea:

I was not quite sure how and when to use the <Terminal />. Looking at the example in the workflow-app-iterm package and the readme of workflow-app-terminal this seemed like the way to be able to open shells in inside iTerm. And it does seem to end up the way I expect.

[havardh]

Ah, sorry, I didn't realize what you actually meant with extra tab in iTerm.

So what if we do this with two flags.

1. openInExistingWindow - try to reuse an existing window, letting the top-most win create a new one if it does not exist.
2. openInNewTab - implies openInExistingWindow and opens a new tab in that window

Now this might seem redundant as you would always add openInExistingWindow when you add openInNewTab which is your use case. However, I would want to make this distinction as using only openInExistingWindow would in your gif result in the exact same layout, except that the existing tab was overwritten with the new layout. This will be the default behavior of workflow in the long run. Which makes your feature an exception applicable to be behind a flag. (At that point we would probably have a flag for openInNewWindow, to have the current behavior.)

workflow-app-terminal is as you said intended to be leaf nodes in the child tree of a terminal like iTerm. It can however delegate to workflow-apps-defaults.Terminal given that it is executed in a gui context. (terminal context is used by workflow-wm-terminal, and inside workflow-app-iterm and workflow-app-tmux etc, gui context is used by workflow-wm-i3, workflow-wm-osx etc.). So on OSX Terminal could mean either iTerm or a visible terminal inside an application, depending on where you use it.

I'm not sure that this was a good decision. And there is already some naming confusion around the name Terminal. You have const {Terminal} = require("workflow-apps-defaults") and const Terminal = require("workflow-app-terminal);. The problem is that it is a valid use-case to use both at the same time. For that you could use just the workflow-app-terminal package as it delegates to workflow-apps-defaults in the appropriate context. But this might be a bit obvious.

Maybe we should rename workflow-app-terminal => workflow-app-shell and remove the delegation so that the user must be explicit?