-
Notifications
You must be signed in to change notification settings - Fork 3
FAQ
- Separation of concerns (blocks produce information, succade pipes it, lemonbar displays it)
- Resource usage (succade and lemonbar should have a pretty small memory footprint)
- Minimalism (if you don't need the additional features of other projects)
No and yes. A single instance of succade can only run one instance of lemonbar, but nothing keeps you from running multiple instances of succade, all with a different configuration file.
I haven't tested it myself, but I don't see why it wouldn't. Feedback appreciated.
succade doesn't care what you're running. Displaying things is the bar's job. If you find a lemonbar fork for Wayland (or a different bar that works on Wayland and uses the same interface as lemonbar), then it will work with succade.
If that other bar uses the same interface as lemonbar (in other words, supports the same format specifier and command line arguments), then yes. Otherwise no.
You can't. succade treats every block (script, program) as one atomic unit that will be styled the same throughout. An underline will always underline all of the block's output, not only part.
This is an issue for some scenarios. For example, if you want a workspace indicator that shows all of your workspaces, but underlines only the active one. A possible workaround would be to either have your workspace block print a different icon for the active workspace than for inactive workspaces (full vs. empty circle, maybe) and not rely on succade's styling options. Another solution is to split your workspace indicator into three separate blocks: the first showing the inactive workspaces before the active one, the second block showing only the active workspace; the third showing the inactive workspaces after the active one -- this way, you can apply different styles to all three of them but make them look like one.
Sorry. succade got a bit too complex and I decided to split handling of child processes into a separate library, libkita. This helps with separation of concerns, code re-usability and code complexity. However, it comes at the cost of making the installation more tedious. If you feel strongly about this, let me know. There is the option to make libkita into a header-only library, which I am considering for this reason.