4 ms·

Maybe I'm biased because I work on a git GUI, but even if you ignore the discoverability and accessibility argument, I think graphically displaying information

Maybe I'm biased because I work on a git GUI, but even if you ignore the discoverability and accessibility argument, I think graphically displaying information is useful. Think about a kanban application - it's just not something that makes sense as a CLI thing. And yes, you could take exclusive control of and draw to the whole screen and use special characters to draw the board, but at that point you're just making a GUI out of text. Usable via terminal emulator does not necessarily mean CLI tool to me, at least within the context of OP's arguments. A lot of the things OP argues have to do with composition. CLI tools are useful in scripts because you can pass them inputs programmatically access and use their output; in this sense, a tool like vim or lynx doesn't fit OP's definition of a CLI tool, they're more like text-based GUIs.

earenndil 8y ago
I'm not making any of the arguments; just thought it would be an interesting discussion piece.
- chuckdries 8y ago
  In this case I was using OP to refer to the content of the post, the 'original post'
j1elo 8y ago
Funnily enough, I scroll down the HN frontpage and see: "Taskbook: Like Trello but for the Terminal" I didn't open that yet, but the coincidence just made me smile (if you can call trello a "kanban" board)
- chuckdries 8y ago
  So the git client I work on has a built in kanban that syncs with github issues, and I work on that part of the application as opposed to the git graph itself - Having dedicated the last 6 months of my life to a kanban, I'd be really interested to see how they solve a bunch of the UX issues surrounding not having a drag and drop pointing device, which in my mind is like the central interaction in a kanban board. Thanks!
Osiris 8y ago
Which git GUI do you work on? I'm a big fan of GUIs for git mostly because I'm able to combine several views into one, such as commit log, file status (staging, etc), and diff. Show this all at the same time is such a huge time saver. SourceTree is my go-to, but alas, there isn't a Linux version. GitKraken is a little... over the top. tig works in a pinch.
- chuckdries 8y ago
  Gitkraken lol
  - Osiris 8y ago
    Waaay too much whitespace. I have to maximize the window to make it useful. It's really easy to shrink the window down to where the graph becomes completely useless. Even in the image/GIF on the homepage there's only room for about 20 characters of the commit message if you want to see the whole branch graph. Compare to SourceTree how the graph window uses a small/normal font, not much padding, and tiny little commit dots and thin, close together lines. Seriously, try to use it reduced to half the screen space on a 1080p monitor.
    - chuckdries 8y ago
      I'll pass the feedback along!
muratsu 8y ago
The argument here is that every tool should have a programmatically accessible core (prob pipelines in linux, apis in windows, etc) and that the GUI should be built in addition to this core. vim didn't do this correctly, so neovim was born (which sort of proves his point imho). One of the goals of the neovim project is to enable the implementation of new/modern user interfaces without any modifications to the core source since the existing C89 code is hard to deal with.
majewsky 8y ago
> And yes, you could take exclusive control of and draw to the whole screen and use special characters to draw the board, but at that point you're just making a GUI out of text. That's called a TUI (text user interface), by the way.
hliyan 8y ago
This made me think: Invoke features via command line, but display results graphically.
flukus 8y ago
> Think about a kanban application - it's just not something that makes sense as a CLI thing. mkdir kanban cd kanban mkdir 0todo 1doing 2done touch 0todo/task1.md ls * 0todo: task1.md 1doing: 2done: A 5 second kanban board.

earenndil 8y ago

I'm not making any of the arguments; just thought it would be an interesting discussion piece.

chuckdries 8y ago
In this case I was using OP to refer to the content of the post, the 'original post'

j1elo 8y ago

Funnily enough, I scroll down the HN frontpage and see: "Taskbook: Like Trello but for the Terminal" I didn't open that yet, but the coincidence just made me smile (if you can call trello a "kanban" board)

chuckdries 8y ago
So the git client I work on has a built in kanban that syncs with github issues, and I work on that part of the application as opposed to the git graph itself - Having dedicated the last 6 months of my life to a kanban, I'd be really interested to see how they solve a bunch of the UX issues surrounding not having a drag and drop pointing device, which in my mind is like the central interaction in a kanban board. Thanks!

Osiris 8y ago

Which git GUI do you work on? I'm a big fan of GUIs for git mostly because I'm able to combine several views into one, such as commit log, file status (staging, etc), and diff. Show this all at the same time is such a huge time saver. SourceTree is my go-to, but alas, there isn't a Linux version. GitKraken is a little... over the top. tig works in a pinch.

chuckdries 8y ago
Gitkraken lol
- Osiris 8y ago
  Waaay too much whitespace. I have to maximize the window to make it useful. It's really easy to shrink the window down to where the graph becomes completely useless. Even in the image/GIF on the homepage there's only room for about 20 characters of the commit message if you want to see the whole branch graph. Compare to SourceTree how the graph window uses a small/normal font, not much padding, and tiny little commit dots and thin, close together lines. Seriously, try to use it reduced to half the screen space on a 1080p monitor.
  - chuckdries 8y ago
    I'll pass the feedback along!

muratsu 8y ago

The argument here is that every tool should have a programmatically accessible core (prob pipelines in linux, apis in windows, etc) and that the GUI should be built in addition to this core. vim didn't do this correctly, so neovim was born (which sort of proves his point imho). One of the goals of the neovim project is to enable the implementation of new/modern user interfaces without any modifications to the core source since the existing C89 code is hard to deal with.

majewsky 8y ago

> And yes, you could take exclusive control of and draw to the whole screen and use special characters to draw the board, but at that point you're just making a GUI out of text. That's called a TUI (text user interface), by the way.

hliyan 8y ago

This made me think: Invoke features via command line, but display results graphically.

flukus 8y ago

> Think about a kanban application - it's just not something that makes sense as a CLI thing. mkdir kanban cd kanban mkdir 0todo 1doing 2done touch 0todo/task1.md ls * 0todo: task1.md 1doing: 2done: A 5 second kanban board.