10 ms·

With all respect for the hard work done on this client, but is it just me or is the TUI getting too much attention recently?? I think the GUI stacks are too bl

With all respect for the hard work done on this client, but is it just me or is the TUI getting too much attention recently?? I think the GUI stacks are too bloated or too hideous (electron, cpp/qt,c# and it's limitations, etc...) to work with these days so much that the cool kids (hardcore techy people) just gave up and started doing TUIs to solve their own problems directly?

giancarlostoro 7y ago
I think you've hit the nail on the head, I've thought about this as well. I think it's clear that UI's are a problem yet to be solved, which is why Electron took off. If you've got a website, you've got a GUI with Electron, and a looot of people know how to slap together some JS and HTML. I would love to see a language agnostic UI stack that can run across platforms, to an extent Electron is "language agnostic" since you write the UI in whatever language you want, you just then compile it to JS (and eventually WebAssembly).
- vnorilo 7y ago
  As a thought experiment, how would the stack differ from Qt, which runs just about everywhere and has bindings for a huge range of languages?
  - cricalix 7y ago
    The one thing that always put me off of the Qt, Wx etc libraries is that it felt like you have to be fairly deep in the weeds with layouts. HTML + CSS ( + something like a framework perhaps for JS niceness) feels much easier, because the browser does the heavy work of laying out the elements for you, resizing them etc. Maybe I've just not sat down long enough to poke the UI work, but every time I have sat down it's felt like a huge effort to get a few text boxes and a data table to render and flow, whilst over in web land, it's a few input tags and a set of table tags in a loop, and then a smattering of CSS.
    - vnorilo 7y ago
      https://doc.qt.io/qt-5/qtquick-layouts-layouts-qml.html https://doc.qt.io/qt-5/qtquick-layouts-layouts-qml.html Doesn't look that bad?
    - Crinus 7y ago
      Why not use the UI designer? It was made exactly for this reason.
      - giancarlostoro 7y ago
        Back to my prior point: how can I leverage the awesome tooling outside of C++? If I can use any language with the awesome Qt tooling I am set. They seem to be working on making Python such a citizen in the official Qt languages stack but its taking forever and is only 1 single language. Maybe they need to do what Godot did. Implement a bridging programming language that bridges any native language to their engine. With Godot I can write code in Rust, D, probably Nim and so on and all due to GDNative their bridging language to ensure you can use what you are comfortable using.
        Crinus 7y ago
        Ah yeah i agree there. Honestly the only way for this to be properly addressed is for a toolkit to commit to API and ABI stability (meaning C++ and any other language without a stable ABI is out of the picture), then people can build on top of it with other languages and focus on actually making the entire framework stable instead of rewriting everything every 4-5 years.
crispinb 7y ago
I think that's right. It's kind of sad. After decades of explosive tech growth, we're left with there being no really good modern desktop OS, and no cross-platform GUI that approaches the potential of the medium. It's a fragmented mess, full of accidental complexity & user frustration.
- michaelmrose 7y ago
  What is complicated about linux Mint or even Debian?
  - Crinus 7y ago
    Gtk3 is awful and broke backwards compatibility with Gtk2 so you need to have at least those two in your system to run applications (since many still need Gtk2). Gtk2 does not get any meaningful updates anymore. Gtk4 will soon be released and repeat the cycle. Same with Qt5, anything that needs Qt4 or less is now broken unless you use Slackware which tries to keep everything it ever had (it even has Gtk1). Qt5 is made by a company whose income doesn't come from desktop apps anymore and certainly not from being a stable API for a desktop environment. Though even if they wanted, C++ lacking a stable ABI doesn't help much. The only alternative would be Motif but that hasn't got any meaningful update since the 90s and is only limping in life thanks to a company whose income seem to come from consulting about converting your Motif app to Qt. Other toolkits either rely on one of the above, have largely been ignored and/or are even less stable than Gtk. And the majority of all toolkits are way too bloated, not just in terms of resource use but also in terms of how easy they are for a developer to master them.
    - michaelmrose 7y ago
      Neither gtk3 nor qt5 are particularly heavy as far as resources usage. Keeping older versions of libraries like gtk is the cost of keeping a rapidly shrinking cast of existing apps working. Note that qt4 and gtk2 are 7 and 8 years old respectively and can be used with current OS if needed by legacy apps. If your distro opts not to support it the dev or packager can ship it with the application. See flatpak or better nix. The storage consumed is reasonable in terms of modern sizes storage. Purely from the perspective of the end user I'm not sure I understand what the difficulty is. The user doesn't care if the app is gtk 2 or 17. From the user's perspective they click install and an icon appears and their free hard drive space goes down a tiny amount.
cyphar 7y ago
I switched to using TUIs for everything except web browsing ~8 years ago (and I switched from GMail to Mutt ~3 years ago). I honestly can't imagine going back (I'm a Linux user so this might bias my viewpoint). GUIs either feel dated or sluggish, and I find that there are far more mature and continually-maintained TUI projects for most developer-related tasks than GUI ones. This is probably because (Linux) developers have a bias towards TUIs and so write tools that suit their workflow. Another massive benefit is that I can seamlessly use all of the same tools over an SSH/Mosh connection. X11 forwarding over SSH has never practically worked for me (it's too laggy and Australian internet makes doing it between networks basically impossible).
- em-bee 7y ago
  the remote access is the key for me. my email is on a server accessible from any machine. sure, webmail could do that too, but webmail can't keep my state if i switch devices. i now carry a tiny laptop (gpd pocket) where i have all my important stuff, including ssh keys to servers. i use any other available device as a workstation with a browser, and use ssh/mosh to access my tiny laptop to do the important work and access servers through that.
  - jakecopp 7y ago
    Just heard about the GPD Pocket for the first time, it's a fascinating little thing! What is the keyboard like to type on and how fast can you type? Where did you purchase it?
    - em-bee 7y ago
      i am not a trained typist, so i primarily type with index fingers and thumbs. that makes small keyboards much less of a problem than otherwise (before the GPD Pocket i was using an OLPC XO), and i type on it almost as fast as on a bigger one. i got the first model of that series during their crowdfunding campaign. (it's their second product that they released 2 years ago) the keyboard on that was a bit wobbly, occasionally a key would not work (most annoying when typing a password), but for the most part it is usable. the newer model is supposed to have a better keyboard, as i think the keyboard was what most people complained about. it has plenty of diskspace and ram, to be practically usable, and if you got the right charger then you can hook up an external monitor and keyboard when at home or in the office, and have it portable otherwise. (and it really fits into my pant pockets)
rightos 7y ago
I'm still using Thunderbird, which is barely maintained for a decent standalone IMAP client - it's beginning to feel pretty ridiculous. I was having some search issues the other day and I looked at alternatives - the options were basically Outlook, Claws Mail which is ugly as sin, eM Client which is Windows only and Mailspring which actually looked pretty good... right up until it asked me to make an account for use with my own IMAP servers - no thanks. I didn't think this was a big ask but I guess now that most people just use a single Gmail account the market for such things is dwindling. Here I sit with 7 accounts in Thunderbird. Maybe I'm just going to be stuck with eM Client or Outlook and using RDP to check my email. I'm willing to pay, someone please give me a decent cross platform alternative with a GUI, ideally a proper, non-electron one. The TUI clients I've looked at all seem to suffer from some mix of: - Poor mail notifications - Poor multi-account support - Single maintainer that could disappear at any time - Archaic keybindings, or perhaps I'm just too lazy to learn them - HTML mail is used widely now as most people use webmail and just doesn't map well to console applications Overall when I want my mail client to "just work" I've found them to be piss poor compared to Thunderbird. Which is beginning to seem rather silly, but it's still my experience. I don't know what to do. Maybe I should fork Mailspring, strip out the account garbage and just tolerate Electron, but that'd create a whole bunch of maintenance work I just can't take on right now.
- crispinb 7y ago
  I'm kind of in the same situation, except that I've abandoned desktop mail clients since moving away from OS X. Mail.app had its problems, and seemed to be getting worse, but it's the only local mail client I've been able to tolerate for some time. Now I just forward my IMAP accounts to gmail. This is horrible for many reasons (don't lecture me, I know), but I haven't been able to find a good solution and messing about with email is time-consuming. I may just consolidate on Fastmail when my current IMAP provider subscription needs renewing. From a brief test a while back their web client seems to be on a par with gmail.
  - dngray 7y ago
    If you're looking to consolidate your email the best way is imapfilter https://github.com/lefcha/imapfilter https://github.com/lefcha/imapfilter I use this LUA script (this is the Jinja2 template so obviously you'll need to substitute the portions in {{ }} with your real values. It runs on an hourly cronjob on my server and sucks down all the mail from Gmail and another account and then puts it in my main inbox via IMAP (not forwarding) so you don't have to worry about opportunistic transport encryption. It also does not mess with the headers which forwarding emails invariably does. -- crontab -e -- 0 * * * * /usr/local/bin/imapfilter function main () -- See 'man imapfilter_config' for an explanation of -- imapfilter options and functions. -- Some config examples: -- https://github.com/lefcha/imapfilter/blob/master/samples/config.lua -- https://gist.github.com/dylanwh/408810 -- http://www.npcglib.org/~stathis/blog/2012/07/09/linux-task-sorting-mail-with-imapfilter/ -- General Options options.timeout = 120 options.subscribe = true -- Accounts {%- for v in ACCOUNTS | from_json %} local {{ v.serverName }} = IMAP { server = '{{ v.server }}', username = '{{ v.username }}', password = '{{ v.password }}', ssl = '{{ v.ssl }}' } {%- endfor %} -- GMAIL -- Gmail behaves differently to normal imap. With a normal imap acccount -- you can simply use move_messages(). Google stores both inbox -- and sent email in the "[Gmail]/All Mail" folder. An email sent to yourself -- from the same email address exists as a single email and is visible in -- the Inbox and Sent box. If you delete the inbox mail then the sent mail -- is also deleted. Thus it is only safe to delete mail once both the Inbox -- and Sent box is copied. -- Only go ahead and copy inbox/sent/spam from gmail if I have received -- some Inbox email. if (gmail['Inbox']:check_status() > 0) then inbox_mail = gmail["Inbox"]:select_all() inbox_copy_success = inbox_mail:copy_messages({{ PRIMARY }}['Gmail Inbox']) sent_mail = gmail['[Gmail]/Sent Mail']:select_all() sent_copy_success = sent_mail:copy_messages({{ PRIMARY }}['Gmail Sent']) spam_mail = gmail["[Gmail]/Spam"]:select_all() spam_mail:move_messages({{ PRIMARY }}['Gmail Spam']) -- Only clear the All Mail folder if we were successful in moving -- our Inbox and Sent mail. Note: move_messages is supposed to return -- booleans for copying the messages and then marking them as deleted. -- For some reason the mark for deletion return value is 'nil'. -- This may need to be [Gmail]/Bin or [Gmail]/Trash check your account! if (inbox_copy_success and sent_copy_success) then print('Safe to delete both inbox and sent') move_inbox = inbox_mail:move_messages(gmail['[Gmail]/Trash']) move_sent = sent_mail:move_messages(gmail['[Gmail]/Trash']) if (move_inbox and move_sent) then print('Emptying bin'); bin_mail = gmail['[Gmail]/Trash']:select_all() bin_mail:delete_messages() end end end {%- if SECONDARY != '' %} -- {{ SECONDARY }} -- Only go ahead and copy inbox/sent/spam from {{ SECONDARY }} if I have received -- some Inbox email. if ({{ SECONDARY }}['Inbox']:check_status() > 0) then inbox_results = {{ SECONDARY }}['Inbox']:select_all() inbox_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Inbox']) sent_results = {{ SECONDARY }}['Sent']:select_all() sent_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Sent']) spam_results = {{ SECONDARY }}['Junk']:select_all() spam_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Spam']) end {%- endif %} end main()
zzo38computer 7y ago
I also think many GUI are too bloated or other problems (and most widget sets don't implement scrollbars like Xaw, and use antialiased fonts with too much kerning, and other problems). TUI can help many things, although also command-line interfaces are. (I use Heirloom-mailx, which is email program with command-line interface; and I am also writing a NNTP client software with command-line interface too.)
- Crinus 7y ago
  > and most widget sets don't implement scrollbars like Xaw Do you consider Xaw scrollbars a feature? They feel totally inconvenient to use with their weird "the position you click at is the amount to scroll and the button to use is the direction to scroll" behavior. The only way i use such a scrollbar myself is with middle clicking since that is the only way i find them usable.
  - zzo38computer 7y ago
    I consider it a feature. It might be better if right-clicking used the distance from the end instead of from the beginning as the amount to move (so that the clicked position would then be on the bottom of the screen, like left-clicking scrolls the clicked position to the top of the screen) (but also, maybe it isn't better that way), but it is still better than Microsoft scrollbars I think. I use all three clicks on it, and I think it isn't inconvenient; it is good.
agumonkey 7y ago
GUI stacks, since the Mac OS X / CSS3 days have become form over function most of the time, for better or worse. I personally appreciate beyond words nice enough, keyboard oriented TUIs. The lack of cycles dedicated to rendering shit I can't bother with anymore makes my brain ultra happy.
laktak 7y ago
Working in a terminal let's me do everything with the keyboard. Not touching a mouse is a big plus. It may not bother you now but it probably will in a few years.
pushpop 7y ago
TUIs aren’t getting any more or less attention than they’ve always gotten. I guess you could argue that with the recent-ish rise of new CLI-friendly languages and frameworks like Go, Rust and Node that the people are reinventing the wheel in terms of terminal based tooling. However there has always been a strong undercurrent of people favouring the terminal for most types of work (myself included).
- Fnoord 7y ago
  Some TUIs even have mouse (optional) support.
  - em-bee 7y ago
    vim has that, and it drives me nuts. i use the mouse to select text in a terminal to copy it elsewhere outside of the terminal, but when vim is running that doesn't work, and i end up disabling mouse support every time because of that.
    - pushpop 7y ago
      Yeah, mouse support seems a little pointless at the best of times but in vim it’s down right annoying.
hawski 7y ago
I wonder if it would be possible to do a GUI mostly-drop-in replacement for ncurses. Immediate advantages, at least for me: - a possibility to use proportional fonts, it's more pleasant for me and increases content density - borders and other decorations could be smaller, increasing density - smooth scrolling could be implemented, which is nice - it could better integrate with desktop environment Possible and very much desired extensions: - basic image and video support - possibility to use different font sizes It would still be limited to a coarse grid, but that's what makes development easy. I never looked beyond superficial it's possible or easy enough to do. I also don't have much experience, beyond basics with ncurses.
- em-bee 7y ago
  i had similar thoughts. what would a modern terminal look like? one where positions and cursor movements are not defined by obscure escape codes but by a proper API.
- _delirium 7y ago
  Emacs in a way does something like this: just about any emacs app (including mail clients) can run in either terminal emacs or GUI emacs, and the GUI version supports proportional fonts, images, etc. Of course building your TUI app on top of emacs instead of ncurses isn't for everyone.
enriquto 7y ago
> With all respect for the hard work done on this client, but is it just me or is the TUI getting too much attention recently?? I, for one, cannot get enough of this. Faced with the choice of a performant and full-featured GUI and a slightly slower and worse TUI, I get to chose the text interface 100% of the time. It is so much more convenient!
blub 7y ago
You're observing something else: software people are the only ones obsessed enough with improving their tools to continuously debate and re-invent them. Sadly this obsessive search for the ultimate workflow becomes a goal unto itself, leading to a life-long unsuccessful and unsatisfying search that is doomed to fail. Meanwhile, in the real world GUIs have long superseded any text-based UIs, speciality tasks aside. E-mail is not a special task...
- toxik 7y ago
  The reason terminals and TUIs are still prevalent in tech circles is that it is a fairly good lowest common denominator. It makes sense to implement interfaces as TUIs. This then creeps into "higher-order functions" such as the terminal integrations for GitHub, or these new TUIs for e-mail. TUIs are basically 100% portable, there is no "does this work in Firefox and Safari?" worries, and the upfront development cost is lower because there are no inherent network transfers as in HTML/JS.
VvR-Ox 7y ago
No, it didn't get enough before because everyone thought they'd need some shiny sht. Instead TUI's work just fine for a lot of things while consuming less of your computers resources as well as being easy on your eyes and state of mind (no hectic blinking and notification banners and sounds distracting you from everything you do). Just because we have more resources and faster computers doesn't mean we should max them out. Use less and you could have a device with enormous battery duration, blazingly fast and easy on the mind. They even support mouse interaction and enable me to work for some hours with an old thinkpad before the battery dies. With mail it's something different in my opinion. While it was easy to get used to VIM, nmtui, newsbeuter etc. I could never get my head around mutt. I hate to use Thunderbird because of the UI/UX and some missing features and I miss the seamless integration into the OS (click on a date in a mail to create an appointment in your calendar*) but it's the only good working mail client out there I know. Mailspring/Nylas has a really nice interface but as another user wrote it wants to steal your credentials and I don't like that. Electron is okay as long as it helps providing a better UX, for me that is one of the most important features besides stability & security. As a calendar app "MineTime" is the best I've seen out there so far and sometimes I wish I'd have a bunch of apps like these for a great "FOSS Desktop Experience". @author: Great work - hope you create something like mutt and alpine that can enrich the ideas in the world of TUI mail clients.
- Crinus 7y ago
  I wonder about the TUIs consuming less resources. Sure, compared to something like Electron, they will, but on the other hand, pretty much everyone is running a TUI in a graphical terminal - often a terminal with unicode support, utf-8 decoding and antialiasing, sometimes subpixel antialiasing with all that overhead it has. In that environment trying to, e.g., fill a silver rectangular area implies sending all the ANSI escape codes to move the cursor and change the current color, send a ton of characters that represent a "full" block, have the terminal emulator parse all that and then fill the area with lots of tiny rectangles (assuming it does know about the full block character and doesn't just defer to the font engine which does the full block drawing itself using the entire text rendering stack). In comparison a GUI application would just draw a filled rectangle. For a local X11 application or OpenGL application this may even done as a hardware accelerated operation without even touching any pipes. To me the "graphical" side of a TUI (which is pretty much most of it) sounds way more heavy than the equivalent of a GUI.
CalRobert 7y ago
For anyone else unfamiliar with the term, TUI appears to refer to "Text-Based User Interface"
krageon 7y ago
> started doing TUIs Terminal-based interfaces predate GUIs and have never really stopped being popular among a specific crowd. Perhaps they are gaining more traction now because of all the warts that current popular GUI frameworks have, but it is by no means a new development that is suddenly happening.
Fnoord 7y ago
TUIs are as cross-platform and network-able on as many clients as you are able to run SSH clients on. They also support resuming (via a terminal multiplexer such as Tmux/Screen; tmux itself can also support session resuming via a plugin), windowing/tabs (via term mux), scrolling (via term mux). So your TUI program does not need any of these features. If you have a computer running 24/7 you can connect to term mux over SSH from anywhere you want. If you have high latency such as LTE or bad WLAN, you can use Mosh to easy with the latency. Either you, you aren't using a lot of bandwidth with a TUI. You can also use the power of the UNIX shell easily together with a term mux. For example, jessfraz runs all her CLI commands in Docker. Why I like it? Well, if you're a Emacs user and you can get everything to work with Emacs-esque keybinds that's great. Same with vi(m) keybinds. With Mutt, its a matter of setting EDITOR right and you can compose your e-mails with vi(m) (yes, you could set EDITOR to something more nefarious ;). You don't get to make such choices with a GUI e-mail client.
z3t4 7y ago
If it gets the job done, and creates some value for the user, the user will go over hoops in order to use it (even pay money) ... I find it funny that we are still emulating old terminals. And still building new apps for them. Plain text however gets the job done. It's very powerful to search for a solution on the web, and find instructions on how to do just about anything by copy/pasting a bunch of commands into the terminal. Personally however I prefer GUI's because I can't seem to remember all the commands or keyboard-keybindings unless I use them daily. And if done correctly, a graphics interface can be more intuitive and have better feature discovery compared to a text interface.

giancarlostoro 7y ago

I think you've hit the nail on the head, I've thought about this as well. I think it's clear that UI's are a problem yet to be solved, which is why Electron took off. If you've got a website, you've got a GUI with Electron, and a looot of people know how to slap together some JS and HTML. I would love to see a language agnostic UI stack that can run across platforms, to an extent Electron is "language agnostic" since you write the UI in whatever language you want, you just then compile it to JS (and eventually WebAssembly).

vnorilo 7y ago
As a thought experiment, how would the stack differ from Qt, which runs just about everywhere and has bindings for a huge range of languages?
- cricalix 7y ago
  The one thing that always put me off of the Qt, Wx etc libraries is that it felt like you have to be fairly deep in the weeds with layouts. HTML + CSS ( + something like a framework perhaps for JS niceness) feels much easier, because the browser does the heavy work of laying out the elements for you, resizing them etc. Maybe I've just not sat down long enough to poke the UI work, but every time I have sat down it's felt like a huge effort to get a few text boxes and a data table to render and flow, whilst over in web land, it's a few input tags and a set of table tags in a loop, and then a smattering of CSS.
  - vnorilo 7y ago
    https://doc.qt.io/qt-5/qtquick-layouts-layouts-qml.html https://doc.qt.io/qt-5/qtquick-layouts-layouts-qml.html Doesn't look that bad?
  - Crinus 7y ago
    Why not use the UI designer? It was made exactly for this reason.
    - giancarlostoro 7y ago
      Back to my prior point: how can I leverage the awesome tooling outside of C++? If I can use any language with the awesome Qt tooling I am set. They seem to be working on making Python such a citizen in the official Qt languages stack but its taking forever and is only 1 single language. Maybe they need to do what Godot did. Implement a bridging programming language that bridges any native language to their engine. With Godot I can write code in Rust, D, probably Nim and so on and all due to GDNative their bridging language to ensure you can use what you are comfortable using.
      - Crinus 7y ago
        Ah yeah i agree there. Honestly the only way for this to be properly addressed is for a toolkit to commit to API and ABI stability (meaning C++ and any other language without a stable ABI is out of the picture), then people can build on top of it with other languages and focus on actually making the entire framework stable instead of rewriting everything every 4-5 years.

crispinb 7y ago

I think that's right. It's kind of sad. After decades of explosive tech growth, we're left with there being no really good modern desktop OS, and no cross-platform GUI that approaches the potential of the medium. It's a fragmented mess, full of accidental complexity & user frustration.

michaelmrose 7y ago
What is complicated about linux Mint or even Debian?
- Crinus 7y ago
  Gtk3 is awful and broke backwards compatibility with Gtk2 so you need to have at least those two in your system to run applications (since many still need Gtk2). Gtk2 does not get any meaningful updates anymore. Gtk4 will soon be released and repeat the cycle. Same with Qt5, anything that needs Qt4 or less is now broken unless you use Slackware which tries to keep everything it ever had (it even has Gtk1). Qt5 is made by a company whose income doesn't come from desktop apps anymore and certainly not from being a stable API for a desktop environment. Though even if they wanted, C++ lacking a stable ABI doesn't help much. The only alternative would be Motif but that hasn't got any meaningful update since the 90s and is only limping in life thanks to a company whose income seem to come from consulting about converting your Motif app to Qt. Other toolkits either rely on one of the above, have largely been ignored and/or are even less stable than Gtk. And the majority of all toolkits are way too bloated, not just in terms of resource use but also in terms of how easy they are for a developer to master them.
  - michaelmrose 7y ago
    Neither gtk3 nor qt5 are particularly heavy as far as resources usage. Keeping older versions of libraries like gtk is the cost of keeping a rapidly shrinking cast of existing apps working. Note that qt4 and gtk2 are 7 and 8 years old respectively and can be used with current OS if needed by legacy apps. If your distro opts not to support it the dev or packager can ship it with the application. See flatpak or better nix. The storage consumed is reasonable in terms of modern sizes storage. Purely from the perspective of the end user I'm not sure I understand what the difficulty is. The user doesn't care if the app is gtk 2 or 17. From the user's perspective they click install and an icon appears and their free hard drive space goes down a tiny amount.

cyphar 7y ago

I switched to using TUIs for everything except web browsing ~8 years ago (and I switched from GMail to Mutt ~3 years ago). I honestly can't imagine going back (I'm a Linux user so this might bias my viewpoint). GUIs either feel dated or sluggish, and I find that there are far more mature and continually-maintained TUI projects for most developer-related tasks than GUI ones. This is probably because (Linux) developers have a bias towards TUIs and so write tools that suit their workflow. Another massive benefit is that I can seamlessly use all of the same tools over an SSH/Mosh connection. X11 forwarding over SSH has never practically worked for me (it's too laggy and Australian internet makes doing it between networks basically impossible).

em-bee 7y ago
the remote access is the key for me. my email is on a server accessible from any machine. sure, webmail could do that too, but webmail can't keep my state if i switch devices. i now carry a tiny laptop (gpd pocket) where i have all my important stuff, including ssh keys to servers. i use any other available device as a workstation with a browser, and use ssh/mosh to access my tiny laptop to do the important work and access servers through that.
- jakecopp 7y ago
  Just heard about the GPD Pocket for the first time, it's a fascinating little thing! What is the keyboard like to type on and how fast can you type? Where did you purchase it?
  - em-bee 7y ago
    i am not a trained typist, so i primarily type with index fingers and thumbs. that makes small keyboards much less of a problem than otherwise (before the GPD Pocket i was using an OLPC XO), and i type on it almost as fast as on a bigger one. i got the first model of that series during their crowdfunding campaign. (it's their second product that they released 2 years ago) the keyboard on that was a bit wobbly, occasionally a key would not work (most annoying when typing a password), but for the most part it is usable. the newer model is supposed to have a better keyboard, as i think the keyboard was what most people complained about. it has plenty of diskspace and ram, to be practically usable, and if you got the right charger then you can hook up an external monitor and keyboard when at home or in the office, and have it portable otherwise. (and it really fits into my pant pockets)

rightos 7y ago

I'm still using Thunderbird, which is barely maintained for a decent standalone IMAP client - it's beginning to feel pretty ridiculous. I was having some search issues the other day and I looked at alternatives - the options were basically Outlook, Claws Mail which is ugly as sin, eM Client which is Windows only and Mailspring which actually looked pretty good... right up until it asked me to make an account for use with my own IMAP servers - no thanks. I didn't think this was a big ask but I guess now that most people just use a single Gmail account the market for such things is dwindling. Here I sit with 7 accounts in Thunderbird. Maybe I'm just going to be stuck with eM Client or Outlook and using RDP to check my email. I'm willing to pay, someone please give me a decent cross platform alternative with a GUI, ideally a proper, non-electron one. The TUI clients I've looked at all seem to suffer from some mix of: - Poor mail notifications - Poor multi-account support - Single maintainer that could disappear at any time - Archaic keybindings, or perhaps I'm just too lazy to learn them - HTML mail is used widely now as most people use webmail and just doesn't map well to console applications Overall when I want my mail client to "just work" I've found them to be piss poor compared to Thunderbird. Which is beginning to seem rather silly, but it's still my experience. I don't know what to do. Maybe I should fork Mailspring, strip out the account garbage and just tolerate Electron, but that'd create a whole bunch of maintenance work I just can't take on right now.

crispinb 7y ago
I'm kind of in the same situation, except that I've abandoned desktop mail clients since moving away from OS X. Mail.app had its problems, and seemed to be getting worse, but it's the only local mail client I've been able to tolerate for some time. Now I just forward my IMAP accounts to gmail. This is horrible for many reasons (don't lecture me, I know), but I haven't been able to find a good solution and messing about with email is time-consuming. I may just consolidate on Fastmail when my current IMAP provider subscription needs renewing. From a brief test a while back their web client seems to be on a par with gmail.
- dngray 7y ago
  If you're looking to consolidate your email the best way is imapfilter https://github.com/lefcha/imapfilter https://github.com/lefcha/imapfilter I use this LUA script (this is the Jinja2 template so obviously you'll need to substitute the portions in {{ }} with your real values. It runs on an hourly cronjob on my server and sucks down all the mail from Gmail and another account and then puts it in my main inbox via IMAP (not forwarding) so you don't have to worry about opportunistic transport encryption. It also does not mess with the headers which forwarding emails invariably does. -- crontab -e -- 0 * * * * /usr/local/bin/imapfilter function main () -- See 'man imapfilter_config' for an explanation of -- imapfilter options and functions. -- Some config examples: -- https://github.com/lefcha/imapfilter/blob/master/samples/config.lua -- https://gist.github.com/dylanwh/408810 -- http://www.npcglib.org/~stathis/blog/2012/07/09/linux-task-sorting-mail-with-imapfilter/ -- General Options options.timeout = 120 options.subscribe = true -- Accounts {%- for v in ACCOUNTS | from_json %} local {{ v.serverName }} = IMAP { server = '{{ v.server }}', username = '{{ v.username }}', password = '{{ v.password }}', ssl = '{{ v.ssl }}' } {%- endfor %} -- GMAIL -- Gmail behaves differently to normal imap. With a normal imap acccount -- you can simply use move_messages(). Google stores both inbox -- and sent email in the "[Gmail]/All Mail" folder. An email sent to yourself -- from the same email address exists as a single email and is visible in -- the Inbox and Sent box. If you delete the inbox mail then the sent mail -- is also deleted. Thus it is only safe to delete mail once both the Inbox -- and Sent box is copied. -- Only go ahead and copy inbox/sent/spam from gmail if I have received -- some Inbox email. if (gmail['Inbox']:check_status() > 0) then inbox_mail = gmail["Inbox"]:select_all() inbox_copy_success = inbox_mail:copy_messages({{ PRIMARY }}['Gmail Inbox']) sent_mail = gmail['[Gmail]/Sent Mail']:select_all() sent_copy_success = sent_mail:copy_messages({{ PRIMARY }}['Gmail Sent']) spam_mail = gmail["[Gmail]/Spam"]:select_all() spam_mail:move_messages({{ PRIMARY }}['Gmail Spam']) -- Only clear the All Mail folder if we were successful in moving -- our Inbox and Sent mail. Note: move_messages is supposed to return -- booleans for copying the messages and then marking them as deleted. -- For some reason the mark for deletion return value is 'nil'. -- This may need to be [Gmail]/Bin or [Gmail]/Trash check your account! if (inbox_copy_success and sent_copy_success) then print('Safe to delete both inbox and sent') move_inbox = inbox_mail:move_messages(gmail['[Gmail]/Trash']) move_sent = sent_mail:move_messages(gmail['[Gmail]/Trash']) if (move_inbox and move_sent) then print('Emptying bin'); bin_mail = gmail['[Gmail]/Trash']:select_all() bin_mail:delete_messages() end end end {%- if SECONDARY != '' %} -- {{ SECONDARY }} -- Only go ahead and copy inbox/sent/spam from {{ SECONDARY }} if I have received -- some Inbox email. if ({{ SECONDARY }}['Inbox']:check_status() > 0) then inbox_results = {{ SECONDARY }}['Inbox']:select_all() inbox_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Inbox']) sent_results = {{ SECONDARY }}['Sent']:select_all() sent_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Sent']) spam_results = {{ SECONDARY }}['Junk']:select_all() spam_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Spam']) end {%- endif %} end main()

zzo38computer 7y ago

I also think many GUI are too bloated or other problems (and most widget sets don't implement scrollbars like Xaw, and use antialiased fonts with too much kerning, and other problems). TUI can help many things, although also command-line interfaces are. (I use Heirloom-mailx, which is email program with command-line interface; and I am also writing a NNTP client software with command-line interface too.)

Crinus 7y ago
> and most widget sets don't implement scrollbars like Xaw Do you consider Xaw scrollbars a feature? They feel totally inconvenient to use with their weird "the position you click at is the amount to scroll and the button to use is the direction to scroll" behavior. The only way i use such a scrollbar myself is with middle clicking since that is the only way i find them usable.
- zzo38computer 7y ago
  I consider it a feature. It might be better if right-clicking used the distance from the end instead of from the beginning as the amount to move (so that the clicked position would then be on the bottom of the screen, like left-clicking scrolls the clicked position to the top of the screen) (but also, maybe it isn't better that way), but it is still better than Microsoft scrollbars I think. I use all three clicks on it, and I think it isn't inconvenient; it is good.

agumonkey 7y ago

GUI stacks, since the Mac OS X / CSS3 days have become form over function most of the time, for better or worse. I personally appreciate beyond words nice enough, keyboard oriented TUIs. The lack of cycles dedicated to rendering shit I can't bother with anymore makes my brain ultra happy.

laktak 7y ago

Working in a terminal let's me do everything with the keyboard. Not touching a mouse is a big plus. It may not bother you now but it probably will in a few years.

pushpop 7y ago

TUIs aren’t getting any more or less attention than they’ve always gotten. I guess you could argue that with the recent-ish rise of new CLI-friendly languages and frameworks like Go, Rust and Node that the people are reinventing the wheel in terms of terminal based tooling. However there has always been a strong undercurrent of people favouring the terminal for most types of work (myself included).

Fnoord 7y ago
Some TUIs even have mouse (optional) support.
- em-bee 7y ago
  vim has that, and it drives me nuts. i use the mouse to select text in a terminal to copy it elsewhere outside of the terminal, but when vim is running that doesn't work, and i end up disabling mouse support every time because of that.
  - pushpop 7y ago
    Yeah, mouse support seems a little pointless at the best of times but in vim it’s down right annoying.

hawski 7y ago

I wonder if it would be possible to do a GUI mostly-drop-in replacement for ncurses. Immediate advantages, at least for me: - a possibility to use proportional fonts, it's more pleasant for me and increases content density - borders and other decorations could be smaller, increasing density - smooth scrolling could be implemented, which is nice - it could better integrate with desktop environment Possible and very much desired extensions: - basic image and video support - possibility to use different font sizes It would still be limited to a coarse grid, but that's what makes development easy. I never looked beyond superficial it's possible or easy enough to do. I also don't have much experience, beyond basics with ncurses.

em-bee 7y ago
i had similar thoughts. what would a modern terminal look like? one where positions and cursor movements are not defined by obscure escape codes but by a proper API.
_delirium 7y ago
Emacs in a way does something like this: just about any emacs app (including mail clients) can run in either terminal emacs or GUI emacs, and the GUI version supports proportional fonts, images, etc. Of course building your TUI app on top of emacs instead of ncurses isn't for everyone.

enriquto 7y ago

> With all respect for the hard work done on this client, but is it just me or is the TUI getting too much attention recently?? I, for one, cannot get enough of this. Faced with the choice of a performant and full-featured GUI and a slightly slower and worse TUI, I get to chose the text interface 100% of the time. It is so much more convenient!

blub 7y ago

You're observing something else: software people are the only ones obsessed enough with improving their tools to continuously debate and re-invent them. Sadly this obsessive search for the ultimate workflow becomes a goal unto itself, leading to a life-long unsuccessful and unsatisfying search that is doomed to fail. Meanwhile, in the real world GUIs have long superseded any text-based UIs, speciality tasks aside. E-mail is not a special task...

toxik 7y ago
The reason terminals and TUIs are still prevalent in tech circles is that it is a fairly good lowest common denominator. It makes sense to implement interfaces as TUIs. This then creeps into "higher-order functions" such as the terminal integrations for GitHub, or these new TUIs for e-mail. TUIs are basically 100% portable, there is no "does this work in Firefox and Safari?" worries, and the upfront development cost is lower because there are no inherent network transfers as in HTML/JS.

VvR-Ox 7y ago

No, it didn't get enough before because everyone thought they'd need some shiny sht. Instead TUI's work just fine for a lot of things while consuming less of your computers resources as well as being easy on your eyes and state of mind (no hectic blinking and notification banners and sounds distracting you from everything you do). Just because we have more resources and faster computers doesn't mean we should max them out. Use less and you could have a device with enormous battery duration, blazingly fast and easy on the mind. They even support mouse interaction and enable me to work for some hours with an old thinkpad before the battery dies. With mail it's something different in my opinion. While it was easy to get used to VIM, nmtui, newsbeuter etc. I could never get my head around mutt. I hate to use Thunderbird because of the UI/UX and some missing features and I miss the seamless integration into the OS (click on a date in a mail to create an appointment in your calendar*) but it's the only good working mail client out there I know. Mailspring/Nylas has a really nice interface but as another user wrote it wants to steal your credentials and I don't like that. Electron is okay as long as it helps providing a better UX, for me that is one of the most important features besides stability & security. As a calendar app "MineTime" is the best I've seen out there so far and sometimes I wish I'd have a bunch of apps like these for a great "FOSS Desktop Experience". @author: Great work - hope you create something like mutt and alpine that can enrich the ideas in the world of TUI mail clients.

Crinus 7y ago
I wonder about the TUIs consuming less resources. Sure, compared to something like Electron, they will, but on the other hand, pretty much everyone is running a TUI in a graphical terminal - often a terminal with unicode support, utf-8 decoding and antialiasing, sometimes subpixel antialiasing with all that overhead it has. In that environment trying to, e.g., fill a silver rectangular area implies sending all the ANSI escape codes to move the cursor and change the current color, send a ton of characters that represent a "full" block, have the terminal emulator parse all that and then fill the area with lots of tiny rectangles (assuming it does know about the full block character and doesn't just defer to the font engine which does the full block drawing itself using the entire text rendering stack). In comparison a GUI application would just draw a filled rectangle. For a local X11 application or OpenGL application this may even done as a hardware accelerated operation without even touching any pipes. To me the "graphical" side of a TUI (which is pretty much most of it) sounds way more heavy than the equivalent of a GUI.

CalRobert 7y ago

For anyone else unfamiliar with the term, TUI appears to refer to "Text-Based User Interface"

krageon 7y ago

> started doing TUIs Terminal-based interfaces predate GUIs and have never really stopped being popular among a specific crowd. Perhaps they are gaining more traction now because of all the warts that current popular GUI frameworks have, but it is by no means a new development that is suddenly happening.

Fnoord 7y ago

TUIs are as cross-platform and network-able on as many clients as you are able to run SSH clients on. They also support resuming (via a terminal multiplexer such as Tmux/Screen; tmux itself can also support session resuming via a plugin), windowing/tabs (via term mux), scrolling (via term mux). So your TUI program does not need any of these features. If you have a computer running 24/7 you can connect to term mux over SSH from anywhere you want. If you have high latency such as LTE or bad WLAN, you can use Mosh to easy with the latency. Either you, you aren't using a lot of bandwidth with a TUI. You can also use the power of the UNIX shell easily together with a term mux. For example, jessfraz runs all her CLI commands in Docker. Why I like it? Well, if you're a Emacs user and you can get everything to work with Emacs-esque keybinds that's great. Same with vi(m) keybinds. With Mutt, its a matter of setting EDITOR right and you can compose your e-mails with vi(m) (yes, you could set EDITOR to something more nefarious ;). You don't get to make such choices with a GUI e-mail client.

z3t4 7y ago

If it gets the job done, and creates some value for the user, the user will go over hoops in order to use it (even pay money) ... I find it funny that we are still emulating old terminals. And still building new apps for them. Plain text however gets the job done. It's very powerful to search for a solution on the web, and find instructions on how to do just about anything by copy/pasting a bunch of commands into the terminal. Personally however I prefer GUI's because I can't seem to remember all the commands or keyboard-keybindings unless I use them daily. And if done correctly, a graphics interface can be more intuitive and have better feature discovery compared to a text interface.