Gh-dash: A beautiful CLI dashboard for GitHub
github.com
github.com
I have something similar just for checking out PRs in a single bash function, powered by gh and fzf:
function ghpr() {
gh pr list --limit 100 --json number,title,updatedAt,author --template \
'{{range .}}{{tablerow .number .title .author.name (timeago .updatedAt)}}{{end}}' |
fzf --height 25% --reverse |
cut -f1 -d ' ' |
xargs gh pr checkout
}
alias gbs="git branch --sort=-committerdate | fzf | xargs -I{} git checkout {}"Doesn't do native-looking software, but the APIs don't look that bad.
- (Last I checked, which is <1yr ago) Text rendering is fundamentally done wrong, it can’t access any system font, can only use the built-in font, or exactly one custom font you bundle. Good luck supporting any user-generated or web content from people who don’t use the Latin script.
- Very limited selection of widgets, a problem common to all but a few native frameworks.
- Very limited styling options for the small selection of widgets.
- Looks terrible. Okay for personal/internal stuff, definitely don’t want to ship to end users. (Obviously subjective.)
My use-cases would be perfect for a TUI, but I need to be able to display pictures and videos, so I'm stuck with a GUI :)
Tried to do a web ui + local backend setup, but that didn't go too well.
mpv --no-config --vo=tct /my/video.mp4
High resolution images on the other hand is supported natively in many terminals (sixel protocol, iTerm 2 protocol, etc.).
"I don't like static builds"
~ rigid@HN
--
Some things really catch me off-guard.
Then there's the fact that I might have compiled libraries with certain options that a static compilation won't get, ever (such as native CPU instructions or other optimizations).
Even worse, static builds mostly use musl as the libc implementation, for which there are many issues (DNS issues, the fact that most openssl library tests don't pass and are disabled). I wouldn't trust musl/alpine/et al in production for "serious" things.
Static builds are __convenient__, but they shouldn't be the default.
I love the fact that you can just update one single openssl lib and all installed apps use the updated version after a restart.
Static builds have their legitimate use-cases so maybe change that to "mandatory static builds". (iirc go support for dynamic linking is worked on and will become stable eventually)
while unusual in the "python world", there are more or less well supported ways: https://www.askpython.com/python/examples/compiling-applicat...
i'm sure go will support dynamic linking aswell sooner or later
- Why? Strongly suggest updating the README to explain why this is useful, or what kind of workflow makes this useful. Just a list of features isn't that compelling to me because I'm not sure I want it.
- Because this is a gh cli extension, and not a standalone program, searching is unfortunately going to be fairly slow. There doesn't seem to be any local caching or syncing of the Github data.
- Not really a user-impacting issue, just a fun fact: because the pagination is handled via Graphql's PageInfo support in their Graphql API, you'll never be able to page through more than 1000 results in a given response.
- Authors might consider linking to https://docs.github.com/en/search-github/searching-on-github in the README, it makes figuring out how to write a custom search a lot easier.
- I'm happy to see XDG_CONFIG_HOME support, but the authors should consider also checking for a config file in $RepoRoot/.config/gh-dash/ and $RepoRoot/.gh-dash/, so that a single config could be more easily shared by members of a team who all check out the same repository.
I'm working on something like this (customizable filter views for Github; quickly drill down into PRs by different authors, affecting different files, across multiple repos, filtered by regex search on the changed files / pr body / pr title / pr comments) but based in the browser, not a TUI. The primary goal of my project is to help engineering leaders understand what is actually getting shipped, and communicate that to other non-technical leaders. If anyone is interested in being a beta tester let me know, I'm hoping to have a release publicly available at the end of this week!
I don't mean to speak for the author, but: The 10 seconds it took for the GitHub web UI to load the homepage of this project is a great justification for its existence!
Sometimes it's nice to just stay in tmux
I'll browse the code and see how readily it could be converted over to working on Gitlab.... also, Gitlab has a GraphQL API available to get at various bits of data surrounding a repo.
I've not looked at this code yet, perhaps it does something similar....?
It's not an institutional policy (MS owns github after all), so it would have been more clear to say
"Work on a team that uses ADO and don't have a choice in the matter."
Just to restate my position for anyone else reading, I don't believe that the fact that a point could be restated with more clarity means that the original version is misleading.
Everything, everywhere, always could always be made better than it is. The question is not "could this be made better?" but instead "is this clear enough [to avoid accusations of misinformation]?"
Slightly related question - is there any self-hosted github API compatible solution? I’m pretty sure the answer is no, but figured I ask.
It is a client-side application, meaning that it is very simple to host (no backend required).
I’ve used gogs a lot in the past and it’s worked very well for my use case which Gitea is a fork of.
It would be great to have a fully self-hosted setup with this tui interface.
EDIT: got it now, not sure why it didn't work before
That said, what does it actually look like without? The docs say "render properly". I haven't tried it yet, let alone without nerd fonts.
That also said, I'd give this one a bigger break than most. If you're doing development work on a machine you probably got decent control and at least enough space to install fira.
[0] I suspect there are two types of people that are terminally terminal: those that are just in their own shells and can always control their full environment and those that work in many machines. I'm the latter, but I tend to notice the latter are also the former, but make different choices because of this, or at least smarter dotfiles that will change things based on environment or (like me) have source install scripts (you can always build a program locally ;) I'm glad people live in the shells, but I hope people making TUIs can realize that there's a bunch of us that have to move machines constantly.
Which isn’t to poo-poo the project, GitHub adds a bunch of extra features so I can see why someone might want to build up on it. It’s just funny, the winding path our files take to get to our eyeballs.
I guess the decentralisation aspects of a given technology just means it's a resilient building block. And since the only way we make sense of things nowadays is through markets, it's inevitable we starting building and consuming centralised services.
I'm not saying centralisation is good or bad btw, but I do share the irony in your reply, mostly because I find it funny when a new tech is being sold as new way of doing something in a decentralised way.
If everything is already covered without such freedom, or you don’t care about what’s not covered (or failed to conceive it), then you don’t really mind having the freedom or not. It doesn’t change much.
Gmail is a good email client — email being decentralized is only relevant to me if I wanted to get off gmail to go to say fastmail. But if I didn’t, what do I care whether the underlying protocol is centralized or not?
Disagree, or at least think there’s a need to clarify. This makes it look like a freedom is only occasionally relevant.
This kind of freedom derived from decentralization also exists as a persistent threat against bad behavior. If users can leave and bring their stuff with them, that constrains the choices that the platform can even consider.
Attempts to centralize should be seen as strategic attempts to change the landscape in a way that makes it easier to exploit users.
We did the same thing with email but we prefer Gmail.
We did the same thing with Usenet but we prefer Reddit.
We did the same thing with IRC but we prefer Slack.
We did it with shitcoins but we prefer Coinbase.
Turns out people really don't care much for pure decentralization. There's money to be made recentralizing decentralized whatever.
Ofc centralised/decentralised is also part of the UX (what happens when the centralised service goes down), but so far it's not been a net win for decentralised.