I love this particular type of software, I have been considering doing the same in python/urwid, but I have had trouble thinking up which modules would be useful and/or interesting.
I would welcome suggestions of similar software, or modules that would be useful if implemented for this, just for something to read or think about.
We are forced to use a combination of Slack and Microsoft Teams at $megacorp. Slack CLI has always been lacking, and Teams is fairly new so I haven't even looked. Having a working module for these would probably get me from tire kicking to daily driver.
I am a unique butterfly and do not like needing a web browser to interface with the company. /s
> but I have had trouble thinking up which modules would be useful and/or interesting
Anything interactive with a readable API: mail inboxes and IM services.
Calendar entries and other notifications published via online calendars.
Other online resources: RSS feeds, TV/film listings - modules to simply display static data and/or filter & highlight specific items of interest.
Anything normally monitored by tools such as cacti/collectd/similar: disk IO, connections, CPU use, memory, application status, ...
Remote versions of the above (either the core module supporting remote calls or a generic server that allows modules to be run and their results read remotely.
Though the key to writing software to scratch an itch is to make sure it supports the things that would be useful and/or interesting to you.
Wednesday-Thursday-Friday looks like an excellent permanent pane for my tmux to have a hotkey assigned to. I'm always resentful at myself that I haven't figured out a way to replace ~/todo after 20 years of using (almost) the same environment.
In the config.yml file can define the column and row sizes to whichever screen size you like. No reason it couldn't work with those dimensions. Take a look at simple_config.yml in the repo.
Can't this be made more general and modular by creating a windowing system for terminals first, and then write little programs that operate in that system?
There are already curses bindings included with python; urwid is intended to be a higher level console UI library (widgets, text input boxes, dialogues, etc).
I use TMUX to essentially create what this person has made. It's much more versatile than a GUI for me because I can kill any "widget" and reopen it with altered command line parameters. It's an incredibly useful and productive way to work. And if I realize that I want data that isn't present, I can just split a TMUX pane (or start a new TMUX window) and display it there.
There was a point where it was that simple to run GUI widgets on a desktop, too. The likes of xman and xclock were just that, programs that one could just run and stop.
Someone mentioned it a few months back and it greatly simplified my life. You specify your layouts (and tmux will give you the information to copy a current layout). You can then tell it what programs to run in each window of the layout.
So I have a window broken into 5 panes (as an example). The top left runs emacs (via emacsclient) and opens my ledger.org file. The other 4 show various reports I want to see: Current cleared balance, current uncleared balance, current uncleared transactions, future transactions (out to a month), and a running balance sheet across the past several months.
In another two windows I just have a shell and an emacsclient instance (because I live in emacs). Then as I come up with other things I want to see (weather information, summaries of my todos, email inbox (tally at least) I can add new window and pane configurations to my tmuxinator configuration. When I restart it, everything is back as I had it (if I put them in the config).
I haven't done as much coding at home as I'd like lately (and it's all Windows at the office). But I have a couple other tmuxinator configs that will layout several windows and panes for development. Like launch an editor, and have spaces laid out like I want for debuggers and test monitoring scripts. As appropriate to the language and task.
For the constantly refreshed display, it's mostly `watch -t <some commands>` (modifying the refresh rate if necessary. `-t` removes the title text from the top of watch so it only shows the command outputs. Which is something it took me way too many years to realize.
I have yet to see a modern GUI that didn't put pretty little animations a higher priority than being modular and configurable and having as much or as little data density as I desire.
Command lines, on the other hand, do it natively if not intuitively.
Their example demonstrates how cluttered the GUI is. I suppose you could change skins to something less gaudy but I bet that winds up looking like a terminal application.
It is , to the best of my knowledge, though I am not a big fan of arch. Excellent wiki however. If I were going to run openbox I would install Debian to server like setup and then manually replicate the general idea of crunchbang.
The mouse. It sucks. The latency too (over long thin pipes). I prefer to live in a textual universe anyways. I can't not use a GUI browser for a lot of things, sadly, and occasionally I end up using an IDE, but as much as possible I use tmux/screen + $EDITOR + cscope + scripts + ... as my UI/IDE. It's just better. It works great over mosh, over SSH, over long thin pipes, over short wide pipes -- it just works. Latency is low, and mouse use nil -- win-win.
EDIT: Also, it's a lot easier to organize and find my way around nested tmuxes than it is to organize tons of windows. Yes: I nest tmuxes.
Hah, my first thought when I saw this - looks awesome, but I want to have less standalone programs in my workflow, not more. More than half of those things I already do within Emacs, all it needs is a little bit of elisp to set it up as a dashboard...
If you are not wanting a full windowing OS (just a windowing display) then https://en.wikipedia.org/wiki/Tmux may do the job for you in unix-a-like environments, with or without https://en.wikipedia.org/wiki/Byobu_(software). In fact I sometimes have several log monitoring windows open in one tmux screen, essentially a dashboard like this and you describe. Done this way all that is running is console applications: almost any existing console application can work well and there is no need for extra development to interface a new windowing API.
You could use an existing CUI/TUI library to write such a condole-based windowing system, if tmux/similar don't quite do what you are looking for. For example https://github.com/chjj/blessed if node.js is your bag. Similar libraries exist for other languages too (go, .net, ...) - search for "Terminal UI <language>" or "Console UI <language>" and options should pop up.
There was a super helpful Internet jargon list maintained by one of the 3-letter federal agencies, obtained through an FOIA request I believe... I used to refer to it whenever I needed to decipher confusing twitter conversations.
As a non-native English speaker, I need it all the time to follow conversations on Internet. I've also made a a personal acronyms database to read GCC's internals documentation and another to translate errno codes to their constant name and vice-versa: https://github.com/lgeorget/acronymdb?files=1
I'm trying out switching over to Firefox and this is 100% the biggest thing I miss about Chrome. I keep double-clicking words and waiting a few seconds just for nothing to pop up.
No. Some of the information, yes, but otherwise no. Org-mode doesn't display like this unless you go into the agenda and then it's only kind of like this.
You could probably use org to help you generate a lot of this though. You can have code blocks which run arbitrary code and generate a report that another utility like this (or another part of emacs) could monitor for display.
Yeah. How dare someone use a different choice of tool to you, and write modules to support it before writing ones to support your preference?! ¡¿¡¿How inconsiderate can they get?!?!
You could of course create a module yourself, and submit a patch.
* I'd love to be able to write my own modules for it
* When a module's config is bad it just doesn't show -- no errors are produced (that I can find) so I don't know what in my config is bad.
Go uses less CPU and is less crashy, both of which are nice in a dashboard.
It also seems like more generic modules may handle the use cases you'd want a DSL for.
For instance, there's already a text module; if a similar module can listen to a FIFO or even listen on a socket, you can just throw whatever you need into it from any language that can write to a filehandle.
If it can handle ANSI escapes, most commands that can write to a terminal would work with it. So `{clear; ls --color=always} > /whatever/fifo` or `> /dev/tcp/whatever/1234` could stick to my dashboard.
I'm also a Go noob. I tried writing a basic web server in Go yesterday to handle Twilio SMS callbacks. Trying to inspect the requests I was receiving was such a pain, I gave up and wrote the server with Sinatra. Am I missing something that's making this more difficult than it should be?
You were probably missing something but we all had to start someplace. :)
I'm not a Go expert by any stretch of the imagination and I can tell you that almost everything you would want to know about a given request is exposed through the request object passed to your handler if you are using the standard Go http stuff.
I'd say you were missing https://github.com/k0kubun/pp but the other tricky thing is that you can read a http.Request.Body only once unlike in Ruby. I usually use ioutil.ReadAll for that.
That's incorrect. Both languages require you to rewind the reader before you can read it a second time. You're probably just used to higher level frameworks like Sinatra or Rails that take care of it for you.
`httputil.DumpRequest`[1] may have been helpful in this situation. If you're on a mainstream platform, the Delve debugger is fairly reasonable these days too.
you don't need to learn it. :-D you already know it, you just need to write it. There are a few things to understand defer, goroutines,channels, interfaces, structs etc.
We also have to give credit to the author. Good programmers have programs that are easy to read and understand.
However like all languages that are easy to read, it can be deceptive. Once you dive into any big/complex project. Context and design decisions matter more than anything else.
While It's rarely hard to read a particular piece of code, the combination of duck typing, only structs as receivers, and interfaces can make it as hard to understand as any dynamic language.
There are quite a few traps for the unwary, like that a unitialized pointer to a concrete type will not test as null/nil if it was passed as any of its interface types, that channels ( for concurrenct ) isn't easy except in a few special cases, an that a closed listening socket isn't necessarily closed immediately, and all sorts of shenanigans. You could expect all those from a relatively new language, but not one that is ostensibly very simple.
If you, however, refrain from using any concurrency, interfaces, slices, and maps ( maps and slices are really reference types made to look superficially like they are passed by value ), and accept that the first element in an iteration over a string should give a different result than indexing the first element in that string.
Well, then it's as easy as it looks, for anything where you don't need to actually handle errors, or where you can always handle them where they occur. Also please do remember that log.Fatal() is actually going to kill your process, because calling os.Exit() is obviously the task of the loggin framework!
But yes, Go could have been that easy to read, but there are quite a few really odd decisions that make a lot of the apparent simplicity be rather superficial unless you happen to use a specific subset of the language.
I'm not sure I would find all of this terribly useful, but it does remind me of a little addition I made to my status script - the time in UTC as well as local time. If you use a system where you are easily able to add arbitrary text to your status bar, I highly recommend this addition. If you do not use such a system, I highly recommend a change ;)
I am decidedly not a Mac person, but hammerspoon is one of my favorite pieces of software in any category.
For people who don't know, it is a service you run on a Mac that has all of Cocoa bound to Lua. You can script aaaaaaanything on your Mac in Lua. Don't like the way Mac does window management? Treat yoself! Want to control anything at all on your Mac with just keystrokes instead of endless pointy clicky? Treat yoself!
It's a (bad) Visual Basic program that also runs my house and logs the GPS in my car. And while it's meant to have voice recognition, it doesn't, because I haven't found a good solution yet that meets my needs. It has a significant number of half-implemented features, because I only invest time in it when inspired to and only so far as it makes my life easier. There is no machine learning of any kind and the command structure is quite static.
For instance, I found I was often asking my house a couple times throughout the day for the thermostat status when I was at work (I have a fairly temperature sensitive pet). This week I went ahead and just told it to go ahead and wrote a little 'status report' email, and then call for it a couple times a day in Windows Task Scheduler.
The documentation seems insufficient. I can’t figure out how to switch between panes, e.g., to modify the todo list. Once it’s selected, I expect to be able to use it, but without knowing how, it is unusable.
119 comments
[ 3.6 ms ] story [ 184 ms ] threadI would welcome suggestions of similar software, or modules that would be useful if implemented for this, just for something to read or think about.
I am a unique butterfly and do not like needing a web browser to interface with the company. /s
Anything interactive with a readable API: mail inboxes and IM services.
Calendar entries and other notifications published via online calendars.
Other online resources: RSS feeds, TV/film listings - modules to simply display static data and/or filter & highlight specific items of interest.
Anything normally monitored by tools such as cacti/collectd/similar: disk IO, connections, CPU use, memory, application status, ...
Remote versions of the above (either the core module supporting remote calls or a generic server that allows modules to be run and their results read remotely.
Though the key to writing software to scratch an itch is to make sure it supports the things that would be useful and/or interesting to you.
She was so cool - AND saved the day with UNIX magic! :-)
FSN [1] on a SGI running IRIX.
Didn't they use that one in Hackers as well?
[1] http://www.siliconbunny.com/fsn-the-irix-3d-file-system-tool...
[0] http://urwid.org
Someone mentioned it a few months back and it greatly simplified my life. You specify your layouts (and tmux will give you the information to copy a current layout). You can then tell it what programs to run in each window of the layout.
So I have a window broken into 5 panes (as an example). The top left runs emacs (via emacsclient) and opens my ledger.org file. The other 4 show various reports I want to see: Current cleared balance, current uncleared balance, current uncleared transactions, future transactions (out to a month), and a running balance sheet across the past several months.
In another two windows I just have a shell and an emacsclient instance (because I live in emacs). Then as I come up with other things I want to see (weather information, summaries of my todos, email inbox (tally at least) I can add new window and pane configurations to my tmuxinator configuration. When I restart it, everything is back as I had it (if I put them in the config).
I haven't done as much coding at home as I'd like lately (and it's all Windows at the office). But I have a couple other tmuxinator configs that will layout several windows and panes for development. Like launch an editor, and have spaces laid out like I want for debuggers and test monitoring scripts. As appropriate to the language and task.
https://github.com/tmuxinator/tmuxinator
For the constantly refreshed display, it's mostly `watch -t <some commands>` (modifying the refresh rate if necessary. `-t` removes the title text from the top of watch so it only shows the command outputs. Which is something it took me way too many years to realize.
Command lines, on the other hand, do it natively if not intuitively.
I could argue that OSX / Ubuntu are modular and configurable and easily allow you to control data density too.
Ultimately it's obviously whatever tool makes you most productive. My comment was more of a flippant observation of the nature of human endeavour.
Ubuntu is the red-headed stepchild of Linux which wants to be Windows. I use it at work. I hate it. I'd rather use Fedora.
Eh. It wants to be Mac:
- broken alt-tab? Check
- menu bar on top? Check
- dock? Check
- window controls moved to the left? Check
> I use it at work. I hate it.
So do I. But now after they moved to Gnome I can fix the worst usabilty issues.
It still crashes hard once a day despite me trying everything I can think of wrt swap, reserved memory etc. Might just be my RAM sticks though.
> I'd rather use Fedora.
> So do I.
Forgot to remove the part about hating it. I don't hate Ubuntu at all, I just question some implementation details.
https://en.wikipedia.org/wiki/Openbox
Archbang , which uses openbox, is a good example of a distribution to try in a VM if anyone wants to see an example in action.
EDIT: Also, it's a lot easier to organize and find my way around nested tmuxes than it is to organize tons of windows. Yes: I nest tmuxes.
We could call it "emacs".
http://www.brain-dump.org/projects/dvtm/
If you are not wanting a full windowing OS (just a windowing display) then https://en.wikipedia.org/wiki/Tmux may do the job for you in unix-a-like environments, with or without https://en.wikipedia.org/wiki/Byobu_(software). In fact I sometimes have several log monitoring windows open in one tmux screen, essentially a dashboard like this and you describe. Done this way all that is running is console applications: almost any existing console application can work well and there is no need for extra development to interface a new windowing API.
You could use an existing CUI/TUI library to write such a condole-based windowing system, if tmux/similar don't quite do what you are looking for. For example https://github.com/chjj/blessed if node.js is your bag. Similar libraries exist for other languages too (go, .net, ...) - search for "Terminal UI <language>" or "Console UI <language>" and options should pop up.
http://netbsd.gw.com/cgi-bin/man-cgi/man?wtf+6+NetBSD-curren...
http://www.catb.org/jargon/html/index.html
https://motherboard.vice.com/en_us/article/nze74k/the-fbi-bu...
https://github.com/matthewspencer/twitter-shorthand has transcription of the first 22 pages.
I found that installing the google dictionary extension[1] for chrome solved that problem for me entirely.
you just doubleclick on the word and a popup opens with its definition.
This extension is the primary reason I'd loath to ever to switch browsers.
[1] https://chrome.google.com/webstore/detail/google-dictionary-...
Also, if you're using Windows, you can use WordWeb (which is a full-fledged app).
You could probably use org to help you generate a lot of this though. You can have code blocks which run arbitrary code and generate a report that another utility like this (or another part of emacs) could monitor for display.
Hack up, people!
You could of course create a module yourself, and submit a patch.
Good idea about the config. I'll create a feature issue for it.
It also seems like more generic modules may handle the use cases you'd want a DSL for.
For instance, there's already a text module; if a similar module can listen to a FIFO or even listen on a socket, you can just throw whatever you need into it from any language that can write to a filehandle.
If it can handle ANSI escapes, most commands that can write to a terminal would work with it. So `{clear; ls --color=always} > /whatever/fifo` or `> /dev/tcp/whatever/1234` could stick to my dashboard.
I'm not a Go expert by any stretch of the imagination and I can tell you that almost everything you would want to know about a given request is exposed through the request object passed to your handler if you are using the standard Go http stuff.
[1]: https://golang.org/pkg/net/http/httputil/#DumpRequest
We also have to give credit to the author. Good programmers have programs that are easy to read and understand.
However like all languages that are easy to read, it can be deceptive. Once you dive into any big/complex project. Context and design decisions matter more than anything else.
There are quite a few traps for the unwary, like that a unitialized pointer to a concrete type will not test as null/nil if it was passed as any of its interface types, that channels ( for concurrenct ) isn't easy except in a few special cases, an that a closed listening socket isn't necessarily closed immediately, and all sorts of shenanigans. You could expect all those from a relatively new language, but not one that is ostensibly very simple.
If you, however, refrain from using any concurrency, interfaces, slices, and maps ( maps and slices are really reference types made to look superficially like they are passed by value ), and accept that the first element in an iteration over a string should give a different result than indexing the first element in that string.
Well, then it's as easy as it looks, for anything where you don't need to actually handle errors, or where you can always handle them where they occur. Also please do remember that log.Fatal() is actually going to kill your process, because calling os.Exit() is obviously the task of the loggin framework!
But yes, Go could have been that easy to read, but there are quite a few really odd decisions that make a lot of the apparent simplicity be rather superficial unless you happen to use a specific subset of the language.
[0] - https://github.com/spf13/cobra
For people who don't know, it is a service you run on a Mac that has all of Cocoa bound to Lua. You can script aaaaaaanything on your Mac in Lua. Don't like the way Mac does window management? Treat yoself! Want to control anything at all on your Mac with just keystrokes instead of endless pointy clicky? Treat yoself!
https://github.com/mikeecb/dotfiles/blob/master/.tmux.conf#L...
For instance, I found I was often asking my house a couple times throughout the day for the thermostat status when I was at work (I have a fairly temperature sensitive pet). This week I went ahead and just told it to go ahead and wrote a little 'status report' email, and then call for it a couple times a day in Windows Task Scheduler.
https://github.com/ocdtrekkie/HAController
The main idea. You read $XDG_* variables, and use them if defined, and use spec defaults if not. It declutters $HOME from dot directories.
Note that not all panes are selectable and quite possibly not all selectable panes have help (they should but...)