[HN Gopher] Superfile - A fancy, pretty terminal file manager
___________________________________________________________________
Superfile - A fancy, pretty terminal file manager
Author : oidar
Score : 236 points
Date : 2024-05-10 13:27 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| teddyh wrote:
| Why is this better than Midnight Commander or GNU Interactive
| Tools?
| hidelooktropic wrote:
| There's not so much as a screenshot of MC on their official
| page. Hard to say.
|
| Did the author say their product was better?
| yjftsjthsd-h wrote:
| I think it's fair to ask of any new program why to use it
| rather than an existing option. And there can be lots of
| reasons - more active development, new features, less buggy,
| smaller program (uses less disk/memory, easier to be less
| buggy), easier to install, easier to use, whatever. And the
| _author_ of a program doesn 't necessarily need to have an
| answer, especially not early on; programming is sometimes its
| own reward, and sometimes advantages only become obvious
| later. But as a _user_ , yeah it's useful to know what
| advantage this thing has over all the other things that do
| the ~same stuff.
| logrot wrote:
| > why to use it
|
| Of course. But that's not what he asked.
| nine_k wrote:
| I won't say that mc is really buggy, nor that it's large.
| But even if it were, it's weird to not even mention it, let
| alone compare with it, while likely most of the target
| audience has been using mc for years (or decades, like me).
| latchkey wrote:
| > _or decades, like me_
|
| Heh, I ported mc to Apple's A/UX back in the early 90's!
| camgunz wrote:
| Is the author really only 16? Wow!
| idunnoman1222 wrote:
| Brew install superfile
|
| Now guess what the executable is called...
| fkyoureadthedoc wrote:
| I _almost_ didn 't even try to figure it out after I installed
| and the `superfile` command didn't work.
| lsllc wrote:
| Yes, I had the same question! (`spf` for the curious!)
|
| EDIT: To be fair, right at the beginning of the tutorial is:
|
| > First, if you want to open superfile by opening a terminal
| and typing spf.
| quesera wrote:
| A symlink would be a good solution.
| eddd-ddde wrote:
| This happens to me quite often.
|
| pacman -Ql <package> | grep bin
|
| There must be similar commands for other package managers.
| micklemeal wrote:
| This looks pretty nice! I like the ability to add multiple file
| panels versus tabs that are common with nnn and ranger. Going to
| give this a spin today.
| TheAmazingRace wrote:
| Wow, this looks super slick! Kudos to the developer for a
| fantastic little project!
| qudat wrote:
| Looks like it's using bubbletea, nice!
| berzzz wrote:
| Very nice!
| schindlabua wrote:
| Love all the terminal tooling that's come out in recent years.
| I'm this close to chrome and rofi being the only gui I'm using on
| my work machine. This looks great!
| ThrowawayTestr wrote:
| Why do Linux users hate GUIs?
| hiatus wrote:
| This program is available for multiple platforms, not just
| linux. Anyway, many people prefer keyboard navigation and
| already have a shell open for other tasks. Navigation by
| keyboard alone is not generally a feature in most GUI
| applications (see things like Vimium to add that capability
| to Chrome, for instance).
| Teever wrote:
| Not only is it multiplatform, but through the magic of SSH
| TUIs are available on any platform.
|
| I think that a lot of people are drawn to the idea of being
| able to customize their UI the exact way they want it and
| have it be that way everywhere.
|
| There are compromises with TUIs but that idea of a
| universal interface is very alluring to some people who
| want to optimize that part of their life.
| satvikpendem wrote:
| Keyboards are often faster than mice.
| eviks wrote:
| GUIs recognize keyboard as a valid input option
| satvikpendem wrote:
| They can but not always. For TUIs, it's mandatory.
| ykonstant wrote:
| That's too much generalization. I like skeuomorphic GUI with
| proper shadows, separators, color gradients, 2.5D borders,
| menus, etc. Nobody is offering those these days, so I
| gravitated towards TUI; I also have a lot of nostalgia for
| the DOS days, and although terminal emulation is worse than a
| proper command line, I make do.
| skydhash wrote:
| I came on macOS on Mojave, but have seen Maverick and Lion
| screenshots and I've used iOS 6 as well. Flat UI can be
| prettier, but the physicality of skeuomorphic design is
| better for interaction. There was something more when
| interacting with Winamp instead of the current batch of
| audio players we have today. Win7 was great.
| schindlabua wrote:
| It's a slippery slope, once you've spent a year tailoring
| your setup it removes so much friction from those tasks you
| do 100 times a day. Sometimes I look at my macos coworkers
| and they have a single application on fullscreen and then
| they shake their mouse or whatever and 20 windows fly over
| the screen and then they scan them all to find the other
| window they are looking for, and I really wonder how they get
| work done.
|
| I use i3 and have 5 credit-card sized terminals open at any
| given time without taking up much screen real estate, and
| it's so great.
|
| Takes some getting used to though.
| something98 wrote:
| > Sometimes I look at my macos coworkers ... and I really
| wonder how they get work done
|
| And I read the sentence before and wonder the same:
|
| > once you've spent a year tailoring your setup
| schindlabua wrote:
| The irony is not lost on me but you can get productive if
| you spend a weekend configuring stuff and then you
| upgrade as you go :)
| sophacles wrote:
| In both cases during the "learn the tool" phase you end
| up spending time having to figure out how to do things,
| understand workflows etc.
|
| In the TUI case though, you can usually tweak that
| workflow and configure it to match your brand of
| thinking. It costs a little more per instance up front,
| but after that year (or whatever time period), you get a
| much less frustrating experience, and the oddball things
| your particular workflow requires have been smoothed out
| - where in the GUI you'd still be frustrated and a bit
| fumbly or suboptimal, so you continue to pay the penalty
| for it over time.
|
| It's really about how you amortize the total time put
| into using the tool.
| tambourine_man wrote:
| >... macos coworkers and they have a single application on
| fullscreen...
|
| They are probably recent ex-Windows users struggling to
| understand a superficially similar but profoundly different
| WIMP paradigm.
|
| >... then they shake their mouse or whatever and 20 windows
| fly over the screen
|
| The fact that they can't handle Mission Control is another
| tell-tale
| kichimi wrote:
| Mac OS itself confuses things by forcing apps to be full
| screen, rather than sizing to the content
| quesera wrote:
| > _Mac OS itself confuses things by forcing apps to be
| full screen, rather than sizing to the content_
|
| I don't understand what you mean.
|
| macOS has never forced apps to be full screen.
| tambourine_man wrote:
| You can option click the green button, but I agree, one
| of the major regressions from Lion, IIRC, that we haven't
| recovered from yet.
| jeffhwang wrote:
| I love the terminal and use vim as my primary text editor
| but I can't remember the last time Mac OS full-screened
| an app for me unless I told it to. I drive most of my mac
| through keyboard shortcuts and minimal pointer
| interaction. Perhaps a mouse-first Mac users are forced
| into full-screen? That still doesn't sound right though.
| utensil4778 wrote:
| Because TUIs _never_ change. No one removes useful options
| from a TUI because "whitespace is clean". No one is writing
| useless changes to TUIs so they can feel like their job means
| something or to chase some bonus.
|
| Because GUI design today is very bad and only getting worse.
| doix wrote:
| Because terminal programs have limitations that limit the
| amount of annoying things programs can do.
|
| The color scheme matches the color scheme I set. They cannot
| change the font size nor the the font. They cannot spawn
| windows that will steal focus. They can run inside tmux which
| has advantages for my workflow.
|
| Hotkeys are a first class citizen and not an afterthought
| when it comes to terminal uis.
|
| That being said, I don't hate GUIs. I just hate a lot of them
| for doing things that annoy me.
| unshavedyak wrote:
| I do wish though that terms had multiple font sizes (with
| some limitations to make it "work"), to allow larger text
| but smaller gutters, etc. Aside from the general
| inefficient use of space, i adore terms.
|
| I do wish and hope more apps become like Zellij, though.
| With possible keybinds on the bottom, etc. I tend to avoid
| TUIs because i can't be arsed to remember the keybinds and
| prefer to just use CLIs since those are in my history.
| skydhash wrote:
| I think emacs have multiple font sizes/weights/families
| support (called font faces) and that's a reason people
| love it. The thing I like about term is that you're not
| confined to a single computer. You only need SSH to
| replicate your workflow anywhere (and a VPN, maybe).
|
| TUIs work better when you're committed to the workflow.
| Discoverability is not often one of the key features
| (although most seem to have great help pages and
| manuals). You chose one, take the time to learn it,
| configure it the way you want and it's better (not
| prettier) than most mouse based workflows.
| atomicnumber3 wrote:
| It's also usually inherently composable, since you can pipe
| and redirect and everything speaks a common language
| (plaintext, for better and worse). If you just naively
| implement a cli tool, you usually end up with something
| that can reasonably be chained or redirect into/out of or
| combined with xargs etc.
|
| It's like if every single GUI program included easy
| recording of macros and had built-in tools for munging of
| data to input fields and from text information.
|
| There is a really solid place for GUI tools though and
| that's where the task is inherently visual (nontrivial
| tabular data, anything with images or video, etc) or where
| discovering your features and guiding people through a
| workflow is more important than it playing a part in a text
| processing pipeline.
|
| Honestly, file managers are probably a good example of
| something that really ought to be a GUI and I've always
| considered it a bit zealous of people to want a TUI for it.
| Just look at this thread alone - people accidentally
| deleting files because navigation and actions are so
| undiscoverable that if you don't just blindly copy vim,
| even highly technical people will have no idea how to use
| your tool.
| friend_and_foe wrote:
| Not just that, there's also that you can run them via SSH,
| there aren't a zillion top heavy GUI frameworks,
| interaction is significantly less cumbersome, and let's
| face it, they look so much better.
|
| For me, hotkeys are the main selling point. I don't want to
| operate my machine with one wrist and one finger. I have a
| panel of switches in front of me, why should it be a
| typewriter 100% of the time? Moving to keyboard focused
| interaction, particularly vim keys but anything really, it
| makes me feel like in operating my machine with my mind, it
| is orders of magnitude less cumbersome once you're past the
| learning curve, such that when I have to use a traditional
| stacking, mouse focused environment I feel like I'm on a
| dial up connection with my hands amputated and cataracts.
| root_axis wrote:
| GUIs are nice for exploration because you can (in principle)
| intuitively iterate through the application behaviors, but
| command line interfaces are far superior when you already
| know what you're doing.
| yjftsjthsd-h wrote:
| > Why do Linux users hate GUIs?
|
| Typically, because we find them inferior to CLIs/TUIs. A few
| possible reasons:
|
| * Graphical programs _tend_ to use more memory /CPU for the
| same task.
|
| * Graphical programs are more likely to prefer/require the
| mouse.
|
| * Graphical programs seem to change their interface more
| frequently.
|
| * Graphical toolkits all seem to suck, in ways that vary by
| toolkit and version, and this suckage tends to make us
| actually notice more than ex. new versions of ncurses
| changing things under the hood.
|
| Don't get me wrong, there are plenty of GUI programs that are
| great - some of them even better than CLI/TUI alternatives -
| but the odds seem to be stacked against them.
| jiehong wrote:
| GUIs aren't composable with other tools easily.
|
| Like, you can pipe CLIs together, and some TUIs accept a
| command and exit, allowing you to chain things together.
|
| On the web, your best bet might be playwright, but that's
| about it. Imagine having GTK and QT applications able to be
| chained and exit automatically.
|
| On MacOS/iOS it's not much better, even if Apple Shortcuts
| can feel ok sometimes, assuming the devs thought about
| allowing some actions to be available through shortcuts.
|
| On Linux, I think dbus was supposed to become the universal
| bus onto which all GUIs could provide services and do things
| together. It hasn't panned out IMO.
| Barrin92 wrote:
| >GUIs aren't composable with other tools easily.
|
| None of the tools on display here are composable either, in
| fact almost all modern TUIs are literally indistinguishable
| from GUIs, using the same widgets and user paradigms you'd
| find in a desktop app, but reimplemented on top a text
| rendering engine, they're not CLI tools.
|
| It's basically the same thing we did on the web where
| webapps sort of pretend that they're not sitting on a text
| protocol but at least there it's out of necessity. On top
| of a functioning graphic stack there's no point for TUIs to
| exist.
| marmakoide wrote:
| A well-made TUIs is really ergonomic and clutter-free. It can
| be maintained to high standard by one person. It doesn't take
| a lot of efforts to make composable tools, ie pipes. It uses
| little resources even for fancy TUIs.
|
| GUIs can be fine, but they are hard to get right, most are
| meh or just bad, and they are human resources sinks.
| techjamie wrote:
| What doix said, but also if I tailor my workflow in the
| terminal, I can toss the same applications and configs onto
| my servers and use them the same way without installing a
| window manager and VNC onto it.
| godelski wrote:
| I'm actually upvoting you. Not because I agree, but because
| this sentiment is so pervasive I need that responses
| highlighted instead of buried.
|
| Linux users don't hate GUIs. I say this as someone who's used
| Linux as a daily driver for 15 years! GUIs have their place,
| but they aren't for everything. There's are two main issues
| here
|
| 1) The terminal is far more flexible and lightweight. I can
| do so much more in my terminal and get far more done in less
| time by using the terminal. Learning a little bash can
| greatly increase your productivity. And on top of that, I can
| do this with little cost to resources. I live in the terminal
| not because it is pretty but because it's faster and more
| efficient. Yes, there's a learning curve but it pays
| dividends.
|
| 2) customization. Don't confuse this for aesthetics. Those do
| matter but you should see yourself as an expert craftsman.
| Your carpenter, engineer, etc all build tools, jigs, and
| other things to help them, especially with organization. Like
| them you should create the best environment for you. I know
| you were told I'm programming classes that the magic is to
| not keep writing the same lines but to wrap those up. This is
| the same thing. The aesthetics are so I can see the things I
| care about the most, not because it's pretty. The aliases and
| scripts I built are to prevent me from wasting time relooking
| up things I do intermittently but not frequent enough to
| memorize. Customization is incredibly hard in GUIs. Dragging
| and dropping things and half the time the whole fucking
| screen scrolls because it's hard to not do this. And even
| then, it gets corrected cluttered and you end up with this
| long tree of menues. But wait you say, just give it a macro!
| And at that point, what's the difference? In the terminal we
| recognize something fundamental: to know it's name is to have
| power over it.
|
| Yes, this isn't everyone. Every person is on a different part
| of their journey. And like I said, the customization is about
| making you productive not trying to find the most optimal,
| because that idea is laughable. There are good defaults but
| optimal is personal.
|
| This is why I'll always trust someone more when they live in
| the terminal. The GUI person might be faster at times but
| they're limited. The person who will fuck around and find out
| is the person who will eventually understand more about the
| complex things they work on. They're more likely to dig deep.
| And this is the thing silicon valley has lost, the sense of
| creating what can be, not what is, not someone else's vision
| but yours.
| jlarocco wrote:
| Even on HN there's no nuance anymore.
|
| I suspect most Linux users don't "hate GUIs" but hate the
| garbage that GUIs enable, like pointless/stupid transition
| animations, hard to see flat UIs, dumbing down of
| preference/setting dialogs, etc.
|
| Most GUI design is focused on dumbing things down for first
| time and beginner users, and most Linux users don't fall into
| that demographic.
|
| If a GUI helps me get my work done faster then I'm all for
| it. If the GUI gets in my way and wastes my time then I'm not
| going to use it.
| jjuel wrote:
| Isn't the terminal program technically a GUI?
| ghodith wrote:
| Technically a TUI?
| hxegon wrote:
| A lot of the new tooling is in Go, superfile included. Noticed
| this after I started using LazyGit (incredible tool btw, I
| can't go back to anything else even after being a die hard
| Magit user for years)
|
| There's some stellar libraries in Go for terminal stuff, in
| particular anything from charmcli. They have an elm style TUI
| framework called bubbletea (which superfile uses), a styling
| library, prebuilt components, it's really incredible. I'm
| building a multiplayer tetris you can play through ssh, which
| is using bubbletea and another lib of theirs called wish.
|
| they have a lot of stuff you can just use in regular shell
| stuff too: https://charm.sh
| copperbrick25 wrote:
| Tried it out for a minute and it crashed because I had a broken
| recursive symlink in my home directory:
|
| 1. Create a recursive symlink to itself: `ln -s test test`
|
| 2. open superfile and navigate to it.
|
| 3. Observe crash
| atlas_hugged wrote:
| Come on, be nice and open an issue dude. You can do it. I
| believe in you!
| dingnuts wrote:
| No, fix the issue and open a PR. This is a personal project.
| They need contributions, not a pile of discouraging issue
| reports for which they'll never have enough time.
| filcuk wrote:
| No, I'll raise an issue. Someone who actually knows Go can
| work on it.
| filcuk wrote:
| No, I'll raise an issue. Someone who actually knows Go can
| work on it.
| hiatus wrote:
| I don't have to be a doctor to know something is wrong in
| my body, but I would have to be a doctor to fix it. Put
| another way: just because you figured out something is
| wrong does not mean you have the ability to fix it.
| klabb3 wrote:
| As a maintainer that just makes it worse. Familiarity with
| the code base is typically necessary to make a good quality
| contribution. Issues are a sign of love, imo, because they
| don't want to stop using your project, they want it to
| improve.
|
| Of course there are also entitled and rude people. But we
| should not set the standards based on a-holes.
|
| > not a pile of discouraging issue reports
|
| This is such a strange way to look at software development.
| Discouraging?
| dewey wrote:
| To be honest, if I'm developing a small project I'm excited
| about and I'm getting an issue report from someone I'd be
| happy to see that someone actually cared enough to spend
| time on writing something (Either in the comments here, or
| as a quick issue on GitHub).
|
| I would not expect someone to get familiar with my young
| code base and fix the issue themselves.
| night_cat wrote:
| Hey, thanks for the report, I fixed it!
| kwhitefoot wrote:
| "You can go to the latest release and download the binary file.
| Once it is downloaded please excrate the file after that enter
| the following in your terminal:"
|
| Is excrate some new jargon meaning to take something out of a
| crate? Or just a boring typo for extract?
| night_cat wrote:
| Just typo..
| nine_k wrote:
| It's a perfectly cromulent word. Let's use it more widely, and
| it _will_ become a real word, like "quiz" or "blog" have
| become.
| NikkiA wrote:
| Or a typo for extricate
| kwhitefoot wrote:
| $ spf spf: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34'
| not found (required by spf) spf: /lib/x86_64-linux-gnu/libc.so.6:
| version `GLIBC_2.32' not found (required by spf)
|
| I'm on Linux Mint 19
| mcbuilder wrote:
| This is a linking issue (you're missing a specific version of a
| dynamically linked standard library), and probably best in the
| issues on the repo, not Hacker News.
| antihero wrote:
| They could build it with CGO_ENABLED=0, if they are using
| Alpine, perhaps.
| opheliate wrote:
| An operating system from 2018 which is no longer maintained by
| its vendor?
| https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php
|
| I think it's somewhat unreasonable to expect software released
| today will necessarily work on your environment without some
| legwork.
| isopede wrote:
| Is it though? I can run Windows programs from 20 years ago on
| my Windows machine just fine.
|
| Issues with Linux binary distribution meanwhile are
| ubiquitous, with glibc probably being the single biggest
| offender. What's worse is that you can't even really
| statically link it without herculean effort. I've spent an
| inordinate amount of my life trying to wrangle third-party
| binaries on Linux libraries and it's just a sorry state of
| affairs.
|
| Try taking a binary package from a vendor from even just 5
| years ago and there's a non-zero chance it won't run on your
| modern distro.
| donio wrote:
| You are talking about backward compatibility, the parent
| thread is about forward compatibility. You won't have much
| luck running a modern executable on XP unless the vendor
| went out of their way to make that happen.
|
| > What's worse is that you can't even really statically
| link it without herculean effort.
|
| The program we are discussing happens to be written in Go
| so it's trivial to build a statically linked executable.
| colatkinson wrote:
| Your version of glibc is too old. Mint 19 is based off Ubuntu
| 18.04, which ships glibc 2.27, whereas this binary seems to
| require symbol versions first shipped in glibc 2.34.
|
| You'll have to compile from source, or update your distro to a
| maintained version. Ubuntu 22.04 ships glibc 2.35, and so Mint
| 21 should work.
|
| Mostly commenting because while this isn't really a tech
| support channel, being able to identify glibc version mismatch
| errors comes up _extremely_ often, even in this day and age.
| anta40 wrote:
| Very cool. Seems like a revamped version of Midnight Commander.
| Let me try..
| lupusreal wrote:
| Looks very swanky. Not sure if I'll replace ranger but this is
| definitely a contender.
| srwest wrote:
| If didn't read the docs, noticed hkjl moved around, and
| accidentally deleted 3 folders with ctrl+d seeing if I could
| scroll down faster. Scary defaults if you have Vim muscle memory.
| likeclockwork wrote:
| Holy shit, thanks for the warning.
| patwie wrote:
| These key-bindings are pure evil for vim users.
| gouggoug wrote:
| Even for non-vim users this default is absolutely horrendous
| StrLght wrote:
| So there's no confirmation for deletion? Oof, that's probably
| the most unsafe default I have seen in a while.
| godelski wrote:
| It really weirds me out how many people use a sprinkling of vim
| keybindings but don't use more. Like how many vim users don't
| know <C-[> (esc) or contextual completion like <C-x><C-p>
| (:help ins-completion). I see so many people use plugins for
| things that already exist in vim but people never discuss.
|
| One that bites me a lot is when a vim keybinding is
| implemented, has insert mode, and they don't also rebind <C-w>.
| Go from trying to delete a word (backwards) but end up losing a
| whole session. It's such muscle memory I sometimes do it on
| webpages, but maybe that one is a feature instead of a bug lol
| jez wrote:
| This is my biggest complaint with keybindings on
| Linux/Windows, that Ctrl means "escape codes" in terminal
| emulator applications and "window/UI operations" in every
| other application.
|
| By contrast, in macOS all the window/UI keybindings are
| typically Cmd (Cmd-W) which means that GUI applications
| attempting to layer on vi keybindings don't have to also
| audit all the Ctrl keybindings that might be doing something
| wildly different compared to what vi users expect.
|
| Cmd for UI and Ctrl for terminal just makes for such a nice
| default convention.
| mikepurvis wrote:
| I agree-- having switched back to Windows five years ago,
| this is one of the biggest things I miss about the Mac
| hardware. Having a separate key just avoids the whole drama
| around whether Ctrl-C is "copy the thing" or "shut it all
| down", and which of those functions is going to get
| remapped to Ctrl-Shift-C and all the fallout from that.
| sshine wrote:
| Configurable windows managers on Linux let you code a
| "super" key. I like the Window key, since it serves no
| other purpose, and never overlaps with default bindings on
| Linux.
|
| So the Cmd/Ctrl split on Mac maps nicely to the Win/Ctrl
| split on Linux.
| godelski wrote:
| While I do this too I understand the above complaint. I
| think naturally linux should have more of a system
| similar to what OSX does. I mean I'm constantly switching
| between OSX and Linux machines but more and more recently
| I've been at at mac computer while inside a linux system
| and that is very seemless because it is the GUI that
| fucks shit up. But now there's so much momentum that I'm
| not sure they can go back. I think the only way to make
| this correction is for a big distro like
| Ubuntu/Pop/Manjaro/Endeavor to switch to a default with
| alt or super as they windowed operating key but have the
| option to switch back (should be implemented in the
| install process and made clear and easy to undo. But
| without making it the default it'll always stay the other
| way. (first introduction should be non-default)).
| moelf wrote:
| >and they don't also rebind <C-w>. Go from trying to delete a
| word (backwards) but end up losing a whole session
|
| This is literally why Vim binding for Jupyter doesn't work
| for me and also why the "terminal" in Jupyter Lab is worse
| than not existing -- I can't help but press C-w
| slim wrote:
| we old vi users don't use key combinations, that's an emacs
| thing :)
| night_cat wrote:
| Btw, this is not actually deleted, but put in the trash can.
|
| But it seems that this hotkey is not good for many people. It
| may be changed in the next version. Thanks for your feedback.
| ghostly_s wrote:
| I use a number of apps where ctrl-d is a common non-
| destructive shortcut, and can't recall ever encountering one
| where it was used for delete.
| 2024throwaway wrote:
| k9s does a delete for ctrl+d
| luqtas wrote:
| what's even the point of downloading something so banal & not
| read the docs; comment at the post WITH the warning of it not
| complaining with Vim shortcuts when it's clear that Emacs is
| ballparks better? /s
| twobitshifter wrote:
| Yes those defaults won't really work for vim. Escape exits the
| program, without even using it, I already know I am going to
| exit a zillion times once my brain thinks I am in Vim.
|
| But the good thing is they are just defaults. Hopefully there
| are already no legions of users resistant to any changes to
| defaults.
| 3523582908 wrote:
| gorgeous!! did you build the ui yourself or did you use a package
| to help? how did that go?
| paranoidxprod wrote:
| Seems like they're using Bubble Tea, a Terminal UI framework
| for Go. I've heard very good things about it and have been
| meaning to check it out.
|
| https://github.com/charmbracelet/bubbletea
| Cu3PO42 wrote:
| The same project has an application called Gum which exposes
| primitives from their UI framework via a single CLI binary.
| It's intended to be used from a normal bash script and I've
| found it really quite pleasant to use.
|
| For example, you could write 'gum choose foo bar baz' to get
| a nice picker over the three provided options.
|
| Their repo has a ton of examples:
| https://github.com/charmbracelet/gum
| safetytrick wrote:
| With a dependency on a font. Wow, it's been a while since I've
| seen that.
| explosion-s wrote:
| Fairly commonplace for TUIs that use icon. Tons of vim plugins
| rely on NerdFonts (A regular monospace font that also includes
| tons of icons)
| terminaltrove wrote:
| superfile looks great, we have this listed on the trove (1) for
| other package managers, we love what's been done recently in the
| terminal / tui space.
|
| I encourage also supporting the author as well on their ko-fi
| page for a new laptop. (2)
|
| 1. https://terminaltrove.com/superfile/
|
| 2. https://ko-fi.com/night_cat
| night_cat wrote:
| Thanks you so much,I really like terminal trove!
| gigatexal wrote:
| play this is very pretty
| insane_dreamer wrote:
| Looks nice! Not sure if it's enough to pry me away from MC, but
| worth a look.
| insane_dreamer wrote:
| very first impression after <30 sec: having to press ^F or any
| key to enable filename/folder search in a folder creates
| friction vs. MC's approach where typing automatically starts
| search of current folder so you can hit a couple of keys, press
| enter, etc. Would be nice if that were a mode here too.
| godisdad wrote:
| Dope. Reminds me of far.exe
| swozey wrote:
| This reminds me of a Windows 3.5 app called List (IIRC) that one
| day I lost the floppy to and as a 7 year old kid was completely
| lost without. So I installed bsd and broke my dads computer
| instead.
| anigbrowl wrote:
| brew install superfile (ok) superfile (not
| found) find superfile (not sound) cd
| /usr/local/Cellar/superfile/1.1.2/bin ls spf
|
| This is mentioned in the tutorial but it's probably worth
| mentioning in the install section to save people 5-10 minutes of
| confusion. Once I found the filename I loved it.
| wkrsz wrote:
| I'm waiting for preview feature:
| https://github.com/MHNightCat/superfile/issues/26
|
| Fortunately it's now on top of the to-do list:
| https://github.com/users/MHNightCat/projects/4/views/1
| qwertox wrote:
| This did send me down a rabbit hole, and I ended up installing
| nnn (n3), only then to land on their GitHub page and staring at
| the keyboard layout and testing stuff out in the terminal. It is
| interesting and I wonder how it's getting used.
|
| [1] https://en.wikipedia.org/wiki/Nnn_(file_manager)
| necrotic_comp wrote:
| so I don't understand what the usecase for a terminal file
| manager is. I've always felt comfortable using cp/mv/mkdir/etc.
| but I feel like I'm missing out. Can someone explain how and why
| you'd use this ?
| wonger_ wrote:
| Three advantages I realized, having done a lot of
| cd/ls/cp/mv/rm and also having used a file manager:
|
| - power user workflows may differ from typical dev workflows.
| Imagine things that a point-and-click file manager solves
| quicker than the command-line. Example: manually organizing a
| bunch of .mp3s, or cleaning out misc downloads. A TUI file
| manager makes these tasks quicker too.
|
| - quick directory navigation. cd is slow. There's solutions for
| a better cd, involving z or fzf or whatever. But a file manager
| should solve it too.
|
| - a file manager, especially a two-pane view, is cognitively
| easier. Better UX. Example: Having a src/ pane on one side and
| dst/ on the other, selecting a few src/ files, then performing
| a copy command. You get instant visual feedback to confirm that
| the files appeared in dst/. Compared to ls, cp file1 file2
| file3 dst/, ls dst/. I always feel the need to ls after
| commands because the command-line doesn't give much feedback.
|
| tldr: speed, ux, comfort. But if you're already comfortable
| with your tools, I think that's the most important thing.
| necrotic_comp wrote:
| Thanks. That makes sense. I guess I'm just super entrenched -
| very comfortable with my tooling and would generally write a
| one-liner for something like the above.
|
| The way I do it is a bit nuts though, and you're right, the
| above is much more consistent and has its advantages
| fernly wrote:
| My goodness but there is a whole lot of these! (Found the below
| table from the Nnn wiki page, mentioned above.)
|
| https://en.wikipedia.org/wiki/Comparison_of_file_managers
| monopoliessuck wrote:
| This looks neat, but has a lot going on.
|
| I really like how minimalist yet extensible lf [0] is and just
| use edir [1] to rename files in bulk. Gluing them both together
| is really easy too.
|
| - [0] https://github.com/gokcehan/lf
|
| - [1] https://github.com/bulletmark/edir
| christophilus wrote:
| I love that there are a lot of great options in this space. This
| one looked nice due to its selection pane: https://xplr.dev/
| sneak wrote:
| The first thing this app does is connect to Microsoft servers to
| download theme files, which for some reason aren't bundled into
| the binary. If you block it from accessing the internet, it
| crashes.
| shdisi wrote:
| I tried this out and within a few minutes had delete a few
| directories. Luckily I was in a git repo but I still immediately
| uninstalled this
| friend_and_foe wrote:
| Just tried this out...
|
| Looks nice. I dig the nerd font thing, I'd never used them
| because all of my TUI stuff is ncurses and the like, it's a nice
| thing to be able to do. I like the outline. I don't like a few
| things.
|
| - Ctrl keys galore. I'm partial to vim keys, a lot of the
| keybinds on here are vim style, why not make it all of them?
|
| - some of the defaults are weird or potentially dangerous.
| There's no confirmation for deletion for example, PageUp and
| PageDown don't work, cursor auto wraparound is a little confusing
| for something like this, and the cursor isn't a highlight, just a
| >.
|
| - Bubbletea always seem to have a minimum terminal size which
| drives me nuts. Btop and other programs I've used have this
| problem.
|
| All in all I like the ability to open multiple panes, the ability
| to open network drives, see ongoing/completed processes and see
| the clipboard. I find I virtually never need more than two panes
| though, and there are plenty of CLI utilities for FTP and stuff.
| I'm probably going to stick with an old school dual pane like
| vifm or MC. I'll keep this on my machine and test it out some
| more next time I need to connect to an ftp server or something, I
| like that it provides most of the functionality that graphical
| file managers like Nautilus have, I do miss some of that stuff in
| my terminal oriented environment, but not enough to go full
| mouse, so it's good to know I have an option that gives me some
| of both.
| Iwan-Zotow wrote:
| Does it work in Windows terminal? Any good?
___________________________________________________________________
(page generated 2024-05-10 23:00 UTC)