Feature request - ncurses interface about pueue HOT 18 CLOSED

Hi, I just want to say that building TUIs seems like a good first issue for Rustacean wannabes. I will finish my college exams by the end of March. If by then, this was not already being worked on, I pledge to learn enough Rust to implement it by summer!

from pueue.

Hey, I know that it's not a ncurses interface, but, if you need a gui and you are using emacs, you might use a package of mine. It is pretty good.

from pueue.

I'm going to close this issue for the time being, as this has been open since ~3 1/2 years.

We already got the emacs interface by @xFA25E and if somebody wants to built a new stand-alone ncurses interface, i think it's best to start a new issue, as quite bit of stuff happened since this issue was opened :)

Best wishes and happy new year to everyone still subscribed to this issue ;D

from pueue.

Well, Investigating the queue, looking at logs and checking the current output could become pretty cool with this, but on the other hand this would require quite some work.

I'm pretty sure that I won't implement this features, especially since I'm planning to rewrite pueue in Rust as soon as the async language feature is stable.

Anyway, I would be happy to help you with the implementation! If you have any questions, feel free to ask!

from pueue.

Nice!

I exported the shared code between the daemon and the client into the stand-alone pueue-lib library. It might be a little rough around the edges regarding error handling, but i tried to document it as well as possible.

It's probably best to create a stand-alone pueue-tui client, which uses this library instead of adding that code to the pueue binary.
The tui code would be completely separated from the remaining pueue client code anyways.

from pueue.

Feel free to start hacking on this project any time!

from pueue.

Oh great! Sorry for the noise that should do it 👍

from pueue.

Since the rewrite is here, this could be probably realised with https://github.com/fdehau/tui-rs

I would love this functionality!

from pueue.

Hey that's cool, didn't know that repo existed. I've never actually written anything in rust and I got no time lately so I'm not sure if I'm the guy to do it either but I will be watching pueue closely for updates!

from pueue.

It's a nice idea, probably the best use case for the ncurses ui is to check the logs in real-time if by means your script is constantly printing information that you need to check.

from pueue.

Indeed. It's mostly something that looks nice at this point.
Though, it could be useful for ergonomic status-changes (stash, enqueue) and command/path edits.

A live-view of the status could also make a pretty cool dashboard.

from pueue.

In the meantime, I wrote a shell script that uses jq and skim to provide interactivity and fuzzy-finding facilities. It's ugly and dumb, but I figured it's fine just as a stop-gap. 🤷‍♂️

from pueue.

@nothingnesses I really like this idea. It seems even lighter than a ncurses depency and still as sufficient.

from pueue.

@mvrozanti It's dependent on jq, skim and tr (GNU coreutils), so I'm not sure that it is lighter. Presumably, it also won't work on non-POSIX shells, so it's probably useless to Windows users. But I'm glad you found it sufficient.

from pueue.

Since skim is also a Rust library, perhaps it could be integrated into pueue natively in the future? It also seems to have a dynamic preview feature which I imagine might be useful for implementing the real-time logs feature that @quebin31 mentioned, but I haven't looked too deep into it yet.

On a related note, there's also tab-rs which is another process management tool (it's a multiplexer) written in Rust but which has an interactive fuzzy-finder built-in (although it lacks pueue's job-queueing facilities and more informative interface) and was what inspired me to write the skim script above. It seems like a combination of pueue and tab-rs' features would make for the ideal process manager and I'm wondering if somehow a collaboration from those involved with both projects would be feasible to make such a thing a reality. Afaik, the developer of tab-rs seems open to implementing an interface similar to pueue's that shows the processes' working directories and command histories, so perhaps a collaboration towards a single tool would be more efficient and maybe prevent duplicate/redundant work?

from pueue.

It would be great if one could a pass a flag to pueue so it returns the output as JSON. This would allow to easily build TUIs for other clients like Emacs.

from pueue.

It would be great if one could a pass a flag to pueue so it returns the output as JSON. This would allow to easily build TUIs for other clients like Emacs.

You mean with like pueue status -j which is already used in the script I linked above? Or did you have something different in mind?

from pueue.

Here's a quick idea on how to proceed without necessarily creating a new TUI as the first step: recommend using watch somewhere in --help. For example, watch pueue status is going to give you a quick update on the status of the queue.

pueue status could also have a couple of features that would nicely pair with watch:

1. an equivalent of --raw-control-chars from less: allow the project to spit out ANSI escape sequences even if stdout is a pipe, so that it can be coupled with watch --color,
2. don't print ANSI sequences if stdout is a pipe and --raw-control-chars was not specified - right now it's a mix: it looks like there was intent not to print them, but the first line contains them,
3. add a way to compact the output of pueue status, right now lots of vertical space is wasted on separators,
4. add a way to display pueue status as if pueue clean was called - i.e. only running things would be displayed

There are probably many more such possible improvements, what I propose is to look at pueue status from the perspective of watch pueue status and new ideas for features are quickly going to pop up.

from pueue.