Quick actions in shell component
We can add some quick actions to the shell component to further improve the UX.
My suggestiond would be:
- Copy button that copies the content of the entire shell
- Copy line button that copies a specific line
- Anchor line, which would change the URL to refer to that line. Makes it easier to share the lines to other users.
More info on: https://github.com/ipfs-shipyard/ipfs-webui/pull/1487
@rafaelramalho19 I'm not quite sure what you mean by "anchor line" ... it sounds cool ;) but can you explain in a little more detail?
It sounds like we might just need an unobtrusive button with "two sides": copy whole shell contents, or copy line (or maybe copy selection; the user can triple-click to select whole line).
The next step is probably to assess Desktop and WebUI to see all the different locations where this button might potentially appear, so we can build a visual asset that fits well in as many of those locations as possible. If you get the time to do this before I do (have some other items on my plate right now), that would be awesome, or we can queue this up to work on later.
Also -- external contribution would be very welcome on this one!
Anchoring lines is basically this: https://dl.dropboxusercontent.com/s/8ktc1s8zzm5zhr8/x7R0ln4MaI.mp4
Aha! Got it. We've got an established visual pattern in the docs already that we might be able to bring over and have make sense: see https://docs-beta.ipfs.io/ and hover over any H2.
As for the copy line/all button, are there any examples elsewhere in the wild that you're a fan of?
I actually don't know examples of copy line, it was just a wild idea 🤷
The copy code exists in a lot of websites, one example is the one from github refined:

I also like this example: https://www.dannyguo.com/blog/how-to-add-copy-to-clipboard-buttons-to-code-blocks-in-hugo/
Adding some more examples of where we'd use this in the IPFS ecosystem, since a proposed fix would need to solve for all of these scenarios - we'd want this to be a reusable pattern at least visually, if not in code.
Web UI with daemon not started or CORS enabled:

Web UI/desktop config file:

ProtoSchool:

IPFS Docs:

Keeping the above in mind, we’d need a solution that would enable us to do the following:
- Copy one line of shell command in an example containing multiple lines of shell commands (and ignore the $ or whatever leading character)
- Copy the entire contents in an example containing some code and/or comments
This could take the following forms:
- An on-hover “copy line” option that appears, probably in the left margin
- A “copy all” option that appears (either persistently or on hover), probably in upper right of code block
However, we wouldn’t want both of these to appear in every instance — for example, having both “copy all” and “copy line” appear for a single-line code excerpt is overkill. And having “copy line” for a CLI feedback illustration (like “initializing daemon…”) doesn’t make any sense.
So that leaves us with either building in a bunch of logic to try to detect what does and doesn’t get what kind of copy option, or having to hand-code in what we specifically want to be copy-able. These both feel awkward. Thoughts welcome.
Maybe we should the current approach from:
<Shell className='mw6'>
<code className='db'><b className='no-select'>$ </b>ipfs daemon</code>
<code className='db'>Initializing daemon...</code>
<code className='db'>API server listening on /ip4/127.0.0.1/tcp/5001</code>
</Shell>
to something like:
<Shell className='mw6'>
<ShellCode>ipfs daemon</ShellCode>
<ShellInfo>Initializing daemon...</ShellInfo>
<ShellCode>API server listening on /ip4/127.0.0.1/tcp/5001</ShellCode>
</Shell>
Pros:
- It allows the Shell component to just copy to the clipboard the text content of each <ShellCode> child component.
- It increases legibility to what is a shell command and what is just information
- It allows for ShellCode to have the copy line in the future if we want.
- It adds the
$prefix automatically so we don't visually pollute the code
Cons:
- We need to add a new "Child" Component to shell every time we want to develop a new type of shell interface (e.g. <ShellComment> - which would add a different color and the
#prefix ?)
I like the logic 😊 Would welcome @lidel’s comments too.
Maybe the shell component could be the first item in a reusable IPFS pattern library ... we started on that in the past but it didn’t gather momentum.
Nice, do you have any links/relevant info to that reusable pattern library discussion?
- I like the idea of having semantics for separating shell input from output. Distinguishing between regular output (stdout) and errors (stderr) would be also useful.
- If we are able to identify individual shell input, I believe it is enough to have copy action for each input, because if user wants to copy anything, thats probably the command to run :)
- If we have that core feature, adding action for copying entire thing feels like diminishing returns, and probably should not be added for the simplicity sake.
@rafaelramalho19 prior discussions see issues linked by @jessicaschilling in https://github.com/ipfs/ipfs-gui/issues/29#issuecomment-610051958