Open ammgws opened 4 years ago
gurditsbedi
commented
4 years ago From my point of view, apt and do-not-disturb seem promising.
apt : AFAIK, apt and pacman belong to most used distros.
do-not-disturb: Some times focus is needed.
ammgws
commented
4 years ago apt seems reasonable given it should have a large user base.
Although both do-not-disturb and apt could be implemented using the Custom block. As mentioned in the first post, I wonder if we should have a collection of custom block configs that we ship as part of i3status-rs for those trivial blocks. Saves the user time from thinking of the block and the commands, and saves us from having to implement them in Rust. @atheriel What do you think (whenever you see this)?
flying7eleven
commented
4 years ago I would vote for a "all-in-one" solution. Personally, I hate the hassle that I have to maintain several external scripts which are "just" called by i3status-rs. Also setting up a new computer would require more effort than just copying a single configuration file (sure, I could also copy all files). Additionally, I agree to the point of @ammgws that someone who starts setting up the bar would have to think about how to realize all the blocks instead of just adding them to the config. This could cause confusion.
From the list in the initial issue, I would be very interested in some of the blocks and could imagine to contribute (for) some of them.
ammgws
commented
4 years ago Do you have any scripts that aren't covered by anything from the list in the first post and are general enough to be useful for others? If so please list those up as well.
atheriel
commented
4 years ago I think a collection of simple/common uses of the Custom block (shell one-liners, basically) would be a great addition to the documentation. We could potentially re-jig blocks.md so that the Custom block gets its own section at the end with a large number of examples.
AkechiShiro
commented
3 years ago Hey @ammgws, could you update your first comment to add that the redshift block was added (partially) in #802, just so beginners coming here don't think nothing has been done for this, since the hueshift block is kinda of lesser complete redshift block (Though I do agree that the redshift block is more complete).
norpol
commented
3 years ago I hope it's ok to add a suggestions in this thread.
Firefox and Chrome have a "Sharing Indicator", this results with no additional configuration with a sharing indicator becoming a tiling-window.
I believe it would be nice to have configuration that omits the sharing-indicator window itself in sway + an additional status item in i3dstatus that will be visible once the sharing indicator id shows up in the swaytree.
An alternative to using the sharing-indicator of Firefox we could add a "audio recording" indicator to sound.rs.
Adding some similar functionality for the webcam is not trivial until we have pipewire though, unless fuser /dev/video* is used.
OK, webcam sharing indicator works fairly simple, here an example (and I hope not to resource consuming):
(example requires bash, fuser, and pactl installed)
#!/usr/bin/env bash
set -ueo pipefail
if fuser /dev/video* >/dev/null; then
icon="music_play"
state="Critical"
text="Rec"
else
icon=""
state="Idle"
text=""
fi
cat - <<EOF
{
"icon": "${icon}",
"state": "${state}",
"text": "${text}"
}
EOF[[block]]
block = "custom"
command = '~/bin/webcam_status'
json = true
interval = 1and the same for audio
#!/usr/bin/env bash
set -ueo pipefail
if [ -n "$(pactl list source-outputs short)" ]; then
icon="microphone_full"
state="Critical"
text="Rec"
else
icon=""
state="Idle"
text=""
fi
cat - <<EOF
{
"icon": "${icon}",
"state": "${state}",
"text": "${text}"
}
EOF[[block]]
block = "custom"
command = '~/bin/audio_status'
json = true
interval = 1In addition I'm using
for_window [title=".*Sharing Indicator" app_id="firefox"] {
floating enable
border none
title none
move position -1000 -1000
}to hide the Firefox Sharing Indicator since there is no proper way of minimizing/hiding windows in swaywm. Though an better alternative to this is adding this to your userChrome.css (via)
#webrtcIndicator {
display: none;
}
MaxVerevkin
commented
3 years ago xkcd, getjson, screenshot, shutdown_menu and system should also be easily covered by custom.
frame - sounds interesting.
rainbow - sounds fun, I can imagine it being implemented with a more advanced alternating mechanism. Perhaps use HSV color space and for every block increase the hue value?
ammgws
commented
3 years ago I have been thinking about creating a udiskie block since all the info can be grabbed via D-Bus, and it would be pretty handy since tray icons aren't currently working on sway. May get around to it one day if no one else does, just need to suss out the bus properties/behaviour.
ObiWahn
commented
2 years ago Hi, I would like to have a trayicon holder block or at least something that lets me use nextcloud.
GladOSkar
commented
2 years ago @ObiWahn tray icons are not managed by i3status-rust, but by your DE's bar. We have no control over them.
You can of course use a custom block to run the nextcloud binary when clicked, which, if nextcloud is already running in the background, will open up its GUI:
[[block]]
block = "custom"
command = "echo \uf0c2 Nextcloud"
on_click = "nextcloud"(The unicode codepoint is an Icon from NF, you might have to change/remove it)
MaxVerevkin
commented
2 years ago Block idea: a menu - user provides a list of strings and commands associated with those strings. Scrolling on the block will cycle through those strings. Clicking on the block will run the command.
[[block]]
block = "menu"
text = "\uf011 "
[[block.items]]
display = "-> Power Off <-"
cmd = "poweroff"
[[block.items]]
display = "-> Sleep <-"
cmd = "systemctl suspend"A prototype:
ammgws
commented
2 years ago Looks good!
mildred
commented
1 year ago I'd love to see a block with IO usage, of course I can run an external command but spawning external commands takes up resources.
jkauerl
commented
4 months ago Hello, im new to Open Source Development and Rust and wanted to know a good first PR to tackle. Any recommendation?
tbaumann
commented
2 weeks ago It would be nice if the custom component would support the waybar JSON format. There are a bunch of stuff that could be used from there and from custom modules.
tbaumann
commented
2 weeks ago Custom can be used for clickable buttons. But it does always require a command option even if you don't use it.
GreyXor[[block]]
block = "custom"
command = "/run/current-system/sw/bin/false"
format = " "
[[block.click]]
button = "left"
cmd = "/nix/store/92rdwiipzag7bix2fzdirxqm41x5dwfn-wlogout-1.2.2/bin/wlogout"Suggestion: Make command optional or add a button block.
MaxVerevkin
commented
2 weeks ago You can just set
command = "echo <button label>"
interval = "once"I'm not sure it is worth making command optional. Though if a potential implementation is simple enough, I will accept it.
Took a quick look at some other status line generators and listed up their blocks to see what ones might be good to implement ourselves. Of interest to me are blocks that use DBus/i3 IPC/etc since we can write those natively to get asynchronously updating blocks and no calls to external programs.
Note that there are a lot of simple blocks here that could be handled by the
customblock, especially those that just call external programs, so I don't see the advantage of adding those into the Rust codebase since there's no performance gains etc to be made. However we could look into the idea of having contributed configs for the custom block either in the repo or wiki or somewhere. Another idea could be allowing for modules/blocks from other status line generators to be able to be imported/used directly in i3status-rust.aptwe have pacman already, so I guess we could have this tooDone in #943dnfdunsthostnamehttp_statuskernelmocpmusicblock (assuming mocp has MPRIS interface)pingexamples/README.md)redshiftsystemxkcdexamples/README.md)do_not_disturbgetjsonhueshiftkdeconnectorscreenshotexamples/README.md)unameexamples/README.md)whoamidunstgpu-loadnvidia-gpublockgoshutdown_menuOthers
762: