Re: [dev] Re: Cleanup of (hg.)suckless.org
On Mon, Jun 20, 2011 at 07:55:51PM +0100, garbeam wrote: > On 20 June 2011 07:48, Petr Sabata wrote: > > On Sat, Jun 18, 2011 at 10:33:02PM +0100, garbeam wrote: > >> On 3 June 2011 17:35, garbeam wrote: > >> > RELOCATE > >> > - last (google code) ?? > >> > - libixp (google code) ?? > >> > - r9p (google code) ?? > >> > - vp (google code) ?? > >> > - wmii (google code) ?? > >> > - wmiirc-rumai (google code) ?? > >> > - skvm (dunno, don't get it) ?? > >> > >> I would like to hear about the status. Are things started to relocate > >> those repos? > > > > And why do you want to move them, actually? > > I don't consider those repositories a good fit with the suckless > philosophy anymore and I intend to sharpen the scope of suckless.org. Thanks. I was quite surprised about wmii since I thought, no matter how repulsive I find it, it was consired a suckless.org flagship or something. -- # Petr Sabata pgpYGzJukn8iI.pgp Description: PGP signature
Re: [dev] How to monitor status
On Mon, Jun 20, 2011 at 06:15:01PM +0100, Connor Lane Smith wrote:
> On 20 June 2011 18:05, Hiltjo Posthuma wrote:
> > getline / getdelim (re)allocates buffers though. But yes a custom
> > function with fgets would be more compatible.
I ack here.
I regularly do use getline where fgets would not suffice...
>
> My point was that this is unnecessary: is your screen able to display
> more than, say, 8192 characters (a common value for BUFSIZ) on a
> single line? And even if so, why are you piping an essay into your
> status bar anyway?
1. the statusbar is set line by line. an essay that is put on the statusbar
will give only the last line.
2.
xsetroot must be called for each change in status message. My program
does not need spawning xsetroot endless, since whatever appears on
stdin will be put (line by line) on the statusbar.
This started with the date/time. Therefore, I need a program that does
like:
int main(int argc, char *argv[])
{
time_t t;
while (1) {
sleep(1);
time(&t);
fputs(stdout, ctime(&t));
fflush(stdout);
}
return 0;
}
When counting resources, you'll find this combination of 2 programs
consume less cpu-power drawing time in the statusbar than any
shell script. And at some point, consuming resources for regularly
setting the statusbar was the subject of this thread :-).
I don't think the history of timestamps equals an essay.
Kurt
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 7:15 PM, Connor Lane Smith wrote: > > My point was that this is unnecessary: is your screen able to display > more than, say, 8192 characters (a common value for BUFSIZ) on a > single line? And even if so, why are you piping an essay into your > status bar anyway? > Hah, then I fully agree with you (I kinda missed the context here, sorry) :)
Re: [dev] Re: Cleanup of (hg.)suckless.org
On 20 June 2011 07:48, Petr Sabata wrote: > On Sat, Jun 18, 2011 at 10:33:02PM +0100, garbeam wrote: >> On 3 June 2011 17:35, garbeam wrote: >> > RELOCATE >> > - last (google code) ?? >> > - libixp (google code) ?? >> > - r9p (google code) ?? >> > - vp (google code) ?? >> > - wmii (google code) ?? >> > - wmiirc-rumai (google code) ?? >> > - skvm (dunno, don't get it) ?? >> >> I would like to hear about the status. Are things started to relocate >> those repos? > > And why do you want to move them, actually? I don't consider those repositories a good fit with the suckless philosophy anymore and I intend to sharpen the scope of suckless.org. Cheers, --garbeam
Re: [dev] How to monitor battery status
A while back I put together a crappy C monitor, which I still use to the day.
Find the .c attached, compile with -lX11 as normal, peruse at will.
Cheers,
Rafa.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define BATTERY "BAT1"
#define BATT_INFO_PATH "/proc/acpi/battery/"BATTERY"/info"
#define BATT_STATE_PATH "/proc/acpi/battery/"BATTERY"/state"
#define BATT_FULL_REGEX "^last full capacity:[ ]+([0-9]*) .*$"
#define BATT_CUR_REGEX "^remaining capacity:[ ]+([0-9]*) .*$"
#define DATE_FORMAT "%H:%M (%Z) - %a %d.%m.%Y"
#define BUFFER_SIZE 4096
#define STATUS_SIZE 256
static char *buf;
static regex_t *batt_full_re, *batt_cur_re;
static Display *dpy;
static Window root;
static XTextProperty name;
void update_status(char *c) {
name.value=(unsigned char*)c;
name.nitems=strlen(c);
XSetWMName(dpy, root, &name);
XSync(dpy, False);
}
void cleanup(void) {
regfree(batt_full_re);
regfree(batt_cur_re);
free(buf);
}
void die(int unused) {
update_status("dwmrc died!");
exit(EXIT_FAILURE);
}
int read_batt(const char *batt_path, const regex_t *batt_re) {
FILE *f;
int batt_total = -1;
regmatch_t result_re[2];
f = fopen(batt_path, "r");
fread(buf, 1, BUFFER_SIZE, f);
regexec(batt_re, buf, 2, result_re, 0);
if(result_re[1].rm_so != -1 && result_re[1].rm_eo != -1) {
buf[result_re[1].rm_eo]='\0';
batt_total = atoi(buf+result_re[1].rm_so);
}
fclose(f);
return batt_total;
}
int main(int argc, char **argv) {
time_t cur_t;
struct tm *cur_lt;
char *status;
int batt_full, batt_cur;
int n;
if( !(dpy = XOpenDisplay(NULL)) ||
!(buf = calloc(1, sizeof(char)*BUFFER_SIZE)) ||
!(status = calloc(1, sizeof(char)*STATUS_SIZE)) ||
!(batt_full_re = calloc(1, sizeof(regex_t))) ||
!(batt_cur_re = calloc(1, sizeof(regex_t))) ) die(0);
regcomp(batt_full_re, BATT_FULL_REGEX, REG_EXTENDED|REG_NEWLINE);
regcomp(batt_cur_re, BATT_CUR_REGEX, REG_EXTENDED|REG_NEWLINE);
root = RootWindow(dpy, DefaultScreen(dpy));
name.encoding=XA_STRING;
name.format=8;
signal(SIGINT, die);
signal(SIGILL, die);
signal(SIGTERM, die);
while(1) {
batt_full=read_batt(BATT_INFO_PATH, batt_full_re);
batt_cur =read_batt(BATT_STATE_PATH, batt_cur_re);
if(batt_full > 0 && batt_cur >= 0) n=snprintf(status, STATUS_SIZE, "%3d%% -- ", (100*batt_cur/batt_full));
else n=snprintf(status, STATUS_SIZE, " NAN -- ");
cur_t = time(NULL);
cur_lt = localtime(&cur_t);
strftime(&status[n], STATUS_SIZE-n, DATE_FORMAT, cur_lt);
update_status(status);
sleep(10);
}
return EXIT_SUCCESS;
}
Re: [dev] How to monitor battery status
Good evening, ilf wrote: On 06-20 10:43, Stefan Mark wrote: But i think think this is a better solution: http://dwm.suckless.org/dwmstatus/ Unfortunately, this promise is not kept: This page will give you a barebone dwmstatus project and show examples on how to extend it to your needs. actually, dwmstatus was intended to be such a unification or an example, how it could be done. The example source, that is hosted there includes all the needs I had for my statusbar, so I lost interest in developing the wiki site a bit further. Dwmstatus is currently using a rather expensive implementation, that is using malloc() for all parts of the status string and then prints them together. I found this to be the most modular way for such a code. Of course a static buffer could be used. The wiki page should rather read »This is an example for a status bar C application. It shows a barebone, how to construct it. For stopping the doubling of work, to find out how to gather various system information in the statusbar, please add your code right on this wiki page. See [wiki] for how to edit this wiki.« So you are free to change the wiki page or add further simple examples to collect system information in C. Sincerely, Christoph Lohmann
Re: [dev] volume level in dwm taskbar
On Mon, Jun 20, 2011 at 12:07:48PM +0300, Le Tian wrote: > On Mon, Jun 20, 2011 at 12:05 PM, Nick wrote: > > > On Mon, Jun 20, 2011 at 12:00:38PM +0300, Le Tian wrote: > > > As long as "aumix -q" refuses to work after the latest update, what you > > guys > > > use to probe volume level? "amixer" could be an alternative but it > > outputs > > > crap, that is difficult to awk. > > > > It isn't great, but I use 'amixer sget PCM' and awk from > > that. Or I use a little C utility I wrote which links to the > > (rather ugly) alsa library functions. > > > > Nick > > > > you mean "amixer sget Master", yes, that is way better, thanks! > -- > Tian I've implemented something along the lines of what Nick has described, but for wmii: you can take a look at my github to see how I did it: https://github.com/fadein/wmii_statusbar Of interest for you will be the file alsavolume.c I much prefer this way over running a pipeline with awk et. al. every couple of seconds if only to avoid PID bloat! -- Erik Falor Registered Linux User #445632 http://counter.li.org pgpNwSUweNX1g.pgp Description: PGP signature
Re: [dev] more on sbase
If were going to be linked to linux we can write a chroot like utility that uses capabilities instead f chroot() to use it without the needs of root. Else we can just suid that bin On 20/06/2011, at 19:39, Connor Lane Smith wrote: > Hey, > > On 20 June 2011 14:08, pancake wrote: >> I missed chroot(1) > > chroot(1) isn't POSIX. We may add other, non-POSIX, utilities for the > purposes of a Linux distro (in a subdirectory), but for the moment I'd > like to concentrate on the portable tools. > >> To create an archive library you need to run ranlib, AR is not enought... >> well it's enought on linux and some BSDs.. but it's definitively not enought >> for Solaris and OSX. > > Fixed in tip. > > Thanks, > cls >
Re: [dev] more on sbase
Hey, On 20 June 2011 14:08, pancake wrote: > I missed chroot(1) chroot(1) isn't POSIX. We may add other, non-POSIX, utilities for the purposes of a Linux distro (in a subdirectory), but for the moment I'd like to concentrate on the portable tools. > To create an archive library you need to run ranlib, AR is not enought... > well it's enought on linux and some BSDs.. but it's definitively not enought > for Solaris and OSX. Fixed in tip. Thanks, cls
Re: [dev] How to monitor battery status
On 20 June 2011 18:05, Hiltjo Posthuma wrote: > getline / getdelim (re)allocates buffers though. But yes a custom > function with fgets would be more compatible. My point was that this is unnecessary: is your screen able to display more than, say, 8192 characters (a common value for BUFSIZ) on a single line? And even if so, why are you piping an essay into your status bar anyway? cls
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 6:06 PM, Connor Lane Smith wrote: > > Please don't encourage things like this. getline() is available in > POSIX 2008; though I suspect the far more portable fgets() would > suffice. > getline / getdelim (re)allocates buffers though. But yes a custom function with fgets would be more compatible.
Re: [dev] How to monitor battery status
Hey, On 20 June 2011 12:25, Kurt Van Dijck wrote: > #ifndef _GNU_SOURCE > #define _GNU_SOURCE > #endif Please don't encourage things like this. getline() is available in POSIX 2008; though I suspect the far more portable fgets() would suffice. Thanks, cls
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 09:24:25AM -0400, Andrew Hills wrote: > On Mon, Jun 20, 2011 at 8:40 AM, Kurt Van Dijck wrote: > > I missed (and still do not see) > > how to make xsetroot(1) read from stdin, line by line. > > xsetroot -name "`my_commands_that_write_to_stdout`" > > > That's why (I thought) that scripts spawn xsetroot(1) each time. > > They wouldn't need to run your C program each time? it would do $ while true; do my_commands_that_write_to_stdout; done | stdin2xroot as a replacement, and when my_commands_that_write_to_stdout would be a single program that emits a line every now & then, you would not spawn processes at all. That indeed is the only advantage of my program :-) > > --Andrew Hills >
Re: [dev] How to monitor battery status
Thx to all for hints. I put acpi -b |tr -d ','|awk '{print $4}' onto my old
script and everythig works fine.
Maby i'll be usefull for somebody
git://github.com/dziq/configs.git
2011/6/20 Kurt Van Dijck
> On Mon, Jun 20, 2011 at 01:59:57PM +0200, ilf wrote:
> > On 06-20 13:25, Kurt Van Dijck wrote:
> > >This program allows me to put 'whatever I can create on stdout' to the
> statusbar
> >
> > Euh yeah, that's what we use xsetroot(1) for.
>
> I missed (and still do not see)
> how to make xsetroot(1) read from stdin, line by line.
> That's why (I thought) that scripts spawn xsetroot(1) each time.
> >
>
>
--
Bartosz Nitkiewicz
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 8:40 AM, Kurt Van Dijck wrote: > I missed (and still do not see) > how to make xsetroot(1) read from stdin, line by line. xsetroot -name "`my_commands_that_write_to_stdout`" > That's why (I thought) that scripts spawn xsetroot(1) each time. They wouldn't need to run your C program each time? --Andrew Hills
Re: [dev] more on sbase
I for one would be very happy about an alternative chroot
implementation, since that is missing in my base2plan9 and
base2heirloom AUR experiments (right now patching up with Busybox).
https://wiki.archlinux.org/index.php/Base2heirloom
https://wiki.archlinux.org/index.php/Base2plan9
2011/6/20 pancake :
> I missed chroot(1) .. but after looking at the manpage I noticed that:
>
> * all flags are long (which looks like there's no standard for those
> options)
> * Which flags should we handle (-u user -g group ?)
> * We should chdir(path); chroot("."); instead of calling chroot(path);
> - this is because the linux implementation is vulnerable.. this is not
> happening in BSD.
>
> writing this chroot command is trivial.. but i just want to know about this.
> feel free to submit the chroot.c
>
> To create an archive library you need to run ranlib, AR is not enought...
> well it's enought on linux and some BSDs.. but it's definitively not enought
> for Solaris and OSX. Can you please push a fix for this? (just call "ranlib
> libutil.a" after ar -r -c...)
>
> thanks
>
>
[dev] more on sbase
I missed chroot(1) .. but after looking at the manpage I noticed that:
* all flags are long (which looks like there's no standard for those
options)
* Which flags should we handle (-u user -g group ?)
* We should chdir(path); chroot("."); instead of calling chroot(path);
- this is because the linux implementation is vulnerable.. this is
not happening in BSD.
writing this chroot command is trivial.. but i just want to know about
this. feel free to submit the chroot.c
To create an archive library you need to run ranlib, AR is not
enought... well it's enought on linux and some BSDs.. but it's
definitively not enought for Solaris and OSX. Can you please push a fix
for this? (just call "ranlib libutil.a" after ar -r -c...)
thanks
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 01:59:57PM +0200, ilf wrote: > On 06-20 13:25, Kurt Van Dijck wrote: > >This program allows me to put 'whatever I can create on stdout' to the > >statusbar > > Euh yeah, that's what we use xsetroot(1) for. I missed (and still do not see) how to make xsetroot(1) read from stdin, line by line. That's why (I thought) that scripts spawn xsetroot(1) each time. >
Re: [dev] How to monitor battery status
On 06-20 13:25, Kurt Van Dijck wrote: This program allows me to put 'whatever I can create on stdout' to the statusbar Euh yeah, that's what we use xsetroot(1) for. The problem is the scripting before that setp, aquiring the "whatever I can create on stdout". -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
[dev] utf-8 and custom pcf font conflict
While trying to make a custom pcf font with icons for dwm taskbar I ultimately didn't manage to make it work under utf-8. Is there a workaround for this problem? -- Tian
Re: [dev] Microsoft considers harmful...
John Carmack: "I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security." http://twitter.com/#!/ID_AA_Carmack/status/81732190949486592 HTML5 is great, it is the final nail in the coffin of XML, and that can only be a good thing, of course it will take decades to bury the god damned thing, but it is the beginning of the end. The web can't be saved, lets at least try to save the future by killing XML as soon as possible. And may ken bless JSON, which has been like a miracle, ironically born of some of the worst web technologies around. uriel On Fri, Jun 17, 2011 at 12:00 PM, hiro <23h...@googlemail.com> wrote: > > http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx > > They learned their lesson and I want a button for disabling HTML5 in my > browser. >
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 12:17:58PM +0200, Stefan Mark wrote:
> On 20.06.2011 11:59, ilf wrote:
> > On 06-19 22:55, Erik Hahn wrote:
> >> http://dwm.suckless.org/scripts/simple_monitors
> >
> > I have done this the /proc/acpi/battery/BAT0/state | shell way for years
> > and found it to be way more resource intense then calling acpi -b.
> >
> > Let's face it, the Shell/Perl/Python/whatever scripting is relatively
> > easy, but very inefficient.
> >
This program allows me to put 'whatever I can create on stdout' to the statusbar
#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#include
#include
#include
int main (int argc, char *argv[]) {
int ret;
Display *dpy;
Window root;
const char *display;
char *line = 0;
size_t size = 0;
/* open display */
display = getenv("DISPLAY") ?: ":0";
dpy = XOpenDisplay(display);
if (!dpy) {
fprintf(stderr, "Unable to open display '%s'\n", display);
exit(1);
}
root = RootWindow(dpy, DefaultScreen(dpy));
while (1) {
ret = getline(&line, &size, stdin);
if (ret < 0)
break;
XStoreName(dpy, root, line);
XSync(dpy, False);
}
return 0;
}
Re: [dev] How to monitor battery status
On 20.06.2011 12:47, Kurt H Maier wrote: > On Mon, Jun 20, 2011 at 5:59 AM, ilf wrote: >> I have done this the /proc/acpi/battery/BAT0/state | shell way for years and >> found it to be way more resource intense then calling acpi -b. >> >> Let's face it, the Shell/Perl/Python/whatever scripting is relatively easy, >> but very inefficient. > > I update my status bar every 50 seconds. I sacrifice, for this, > approximately thirty seconds of battery life on a battery that lasts > on the order of seven hours to a charge. I'm not particularly > concerned by this 'inefficiency,' to be honest. > On one of my system im really concerned about the ram usage. But mostly its because i dont like to waste resources. It just nags me having a perl script running that uses twice the memory as the window manager just to display some status information. And it adds up. 2 for the status, 6 for a python based notifier, maybe a wallpaper changer or a udev daemon...
Re: [dev] Re: Cleanup of (hg.)suckless.org
On Mon, Jun 20, 2011 at 8:48 AM, Petr Sabata wrote: > > And why do you want to move them, actually? Because they're garbage? On Mon, Jun 20, 2011 at 5:01 AM, Uriel wrote: > > Usual garbeam fetish for busywork. He is an excellent bureaucrat. Well, he *is* german. -- # Kurt H Maier
Re: [dev] How to monitor battery status
On Mon, Jun 20, 2011 at 5:59 AM, ilf wrote: > I have done this the /proc/acpi/battery/BAT0/state | shell way for years and > found it to be way more resource intense then calling acpi -b. > > Let's face it, the Shell/Perl/Python/whatever scripting is relatively easy, > but very inefficient. I update my status bar every 50 seconds. I sacrifice, for this, approximately thirty seconds of battery life on a battery that lasts on the order of seven hours to a charge. I'm not particularly concerned by this 'inefficiency,' to be honest. -- # Kurt H Maier
Re: [dev] How to monitor battery status
On Sun, Jun 19, 2011 at 10:51:46PM +0200, Bartosz Nitkiewicz wrote: > I'm looking for a best way to monitor battery status in dwm. Any hints? xbattbar, http://iplab.naist.jp/member/suguru/xbattbar.html But no idea whether it is suckless (i.e. haven't looked beyond the surface, which I like). - Jukka.
Re: [dev] How to monitor battery status
On 20.06.2011 11:59, ilf wrote: > On 06-19 22:55, Erik Hahn wrote: >> http://dwm.suckless.org/scripts/simple_monitors > > I have done this the /proc/acpi/battery/BAT0/state | shell way for years > and found it to be way more resource intense then calling acpi -b. > > Let's face it, the Shell/Perl/Python/whatever scripting is relatively > easy, but very inefficient. > Indeed > That's why I really like this approach: > > On 06-20 10:43, Stefan Mark wrote: >> But i think think this is a better solution: >> http://dwm.suckless.org/dwmstatus/ > > Unfortunately, this promise is not kept: > >> This page will give you a barebone dwmstatus project and show examples >> on how to extend it to your needs. > > It'd be cool to have a configurable C program to do what we're currently > all scripting ourselves. > Just two Days ago i found a nice and relatively complete one in this Mailinglist. Since then, im tinkering around with it, with the intention to make it more or less a replacement for my old perl project. It has some monitors and libnotify support. If there is interest, i could make a svn.
Re: [dev] How to monitor battery status
On 06-19 22:55, Erik Hahn wrote: http://dwm.suckless.org/scripts/simple_monitors I have done this the /proc/acpi/battery/BAT0/state | shell way for years and found it to be way more resource intense then calling acpi -b. Let's face it, the Shell/Perl/Python/whatever scripting is relatively easy, but very inefficient. That's why I really like this approach: On 06-20 10:43, Stefan Mark wrote: But i think think this is a better solution: http://dwm.suckless.org/dwmstatus/ Unfortunately, this promise is not kept: This page will give you a barebone dwmstatus project and show examples on how to extend it to your needs. It'd be cool to have a configurable C program to do what we're currently all scripting ourselves. FWIW, my relevant part from .xinitrc: http://pastebin.com/ShQYQri1 -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] How to monitor battery status
On Mon, 20 Jun 2011 11:27:10 +0200 pancake wrote: >On 06/20/11 10:24, Hadrian Węgrzynowski wrote: >> It's maybe not the best way, but I written small utility that uses >> Linux /proc and /sys to take stats. Original source outputs cpu >> usage, cpu freq, cpu temp, mem usage, battery status and gpu temp >> for my thinkpad. >> https://gitorious.org/stater >> To configure it you must change source ;) You can remove wmfs >> formatters. >> I am not proficient in C and Makefile could be better and don't know >> is it suckless enough. >> >this is thinkpad specific. > This is not true. As I said: >> To configure it you must change source ;) You can remove wmfs >> formatters. But of course it needs few more changes than simply changing paths. I use modified version of this on old Athlon XP 2600+ machine and my Pentium Dual Core desktop. You can rip off all but battery status checks and set proper paths. Probably battery status will not need any changes on newer kernels with ACPI_BATTERY, ACPI_SYSFS_POWER and SYSFS (/sys/class/power_supply/BAT0/).
Re: [dev] How to monitor battery status
On 06/20/11 10:24, Hadrian Węgrzynowski wrote: On Sun, 19 Jun 2011 22:51:46 +0200 Bartosz Nitkiewicz wrote: Hello, I'm looking for a best way to monitor battery status in dwm. Any hints? It's maybe not the best way, but I written small utility that uses Linux /proc and /sys to take stats. Original source outputs cpu usage, cpu freq, cpu temp, mem usage, battery status and gpu temp for my thinkpad. https://gitorious.org/stater To configure it you must change source ;) You can remove wmfs formatters. I am not proficient in C and Makefile could be better and don't know is it suckless enough. this is thinkpad specific.
Re: [dev] volume level in dwm taskbar
On Mon, Jun 20, 2011 at 12:05 PM, Nick wrote: > On Mon, Jun 20, 2011 at 12:00:38PM +0300, Le Tian wrote: > > As long as "aumix -q" refuses to work after the latest update, what you > guys > > use to probe volume level? "amixer" could be an alternative but it > outputs > > crap, that is difficult to awk. > > It isn't great, but I use 'amixer sget PCM' and awk from > that. Or I use a little C utility I wrote which links to the > (rather ugly) alsa library functions. > > Nick > > you mean "amixer sget Master", yes, that is way better, thanks! -- Tian
Re: [dev] volume level in dwm taskbar
On Mon, Jun 20, 2011 at 12:00:38PM +0300, Le Tian wrote: > As long as "aumix -q" refuses to work after the latest update, what you guys > use to probe volume level? "amixer" could be an alternative but it outputs > crap, that is difficult to awk. It isn't great, but I use 'amixer sget PCM' and awk from that. Or I use a little C utility I wrote which links to the (rather ugly) alsa library functions. Nick
Re: [dev] Re: Cleanup of (hg.)suckless.org
On Mon, Jun 20, 2011 at 8:48 AM, Petr Sabata wrote: > On Sat, Jun 18, 2011 at 10:33:02PM +0100, garbeam wrote: > > I would like to hear about the status. Are things started to relocate > > those repos? > > And why do you want to move them, actually? Usual garbeam fetish for busywork. He is an excellent bureaucrat. uriel
[dev] volume level in dwm taskbar
As long as "aumix -q" refuses to work after the latest update, what you guys use to probe volume level? "amixer" could be an alternative but it outputs crap, that is difficult to awk. -- Tian
Re: [dev] How to monitor battery status
On 19.06.2011 22:51, Bartosz Nitkiewicz wrote: > Hello, > I'm looking for a best way to monitor battery status in dwm. Any hints? > I use a extensible perl script (https://svn.0mark.unserver.de/dwmd/branches/experimental/). Not perfect, but easy to maintain and extend. The script features Monitors for temp (acpi and lm-sensors), cpu clock, battery, wireless signal strength, mpd and date. It also provied wallpaper changer and autostart. Lacks documentation. But i think think this is a better solution: http://dwm.suckless.org/dwmstatus/
Re: [dev] How to monitor battery status
On Sun, 19 Jun 2011 22:51:46 +0200 Bartosz Nitkiewicz wrote: >Hello, >I'm looking for a best way to monitor battery status in dwm. Any hints? > It's maybe not the best way, but I written small utility that uses Linux /proc and /sys to take stats. Original source outputs cpu usage, cpu freq, cpu temp, mem usage, battery status and gpu temp for my thinkpad. https://gitorious.org/stater To configure it you must change source ;) You can remove wmfs formatters. I am not proficient in C and Makefile could be better and don't know is it suckless enough.
