Arch Linux

Jukkeri

Member

From: Finland

Registered: 2013-09-01

Posts: 2

Website

Haapa - A simple status program in C

Hello,

me and my friend have been working on a simple system monitor to generate status bars for programs like i3bar and dwm. It's currently configured trough config.h, but we have plans to use a run time configuration. It has a bunch of features already, and more are coming.

GitHub and AUR

Jgke

Member

Registered: 2012-04-05

Posts: 12

Re: Haapa - A simple status program in C

Downloading:

yaourt -G haapa-git

or for those who don't use yaourt

wget https://aur.archlinux.org/packages/ha/haapa-git/haapa-git.tar.gz
tar -xzf haapa-git.tar.gz

Configuring:

cd haapa-git
makepkg
$EDITOR src/haapa/src/config.h
makepkg -efi

Read CONFIGURATION.md for all available configuration options.

Last edited by Jgke (2013-09-07 12:49:52)

sekret

Member

Registered: 2013-07-22

Posts: 291

Re: Haapa - A simple status program in C

Nice!!! Small suggestions for the PKGBUILD:

pkgver() {
 cd $_pkgname
 git describe --tags | sed -e 's|-|.|g'
}

(your pkgver isn't the best, because it doesn't show if my current version is newer or older than upstream)

prepare() {
  cd $_pkgname/src
  if [ -e $SRCDEST/config.h ];then msg "using custom config.h";cp $SRCDEST/config.h .;fi
}

With this, all the user has to do is copy the config.def.h to the same directory where the PKGBUILD file is - or, in case $SRCDEST is somewhere else, to the directory configured in makepkg.conf - and run makepkg. Yes I know, there are people who say, that it's horrible to do this, but for AUR packages this is VERY handy!
The "more correct" alternative would be to put config.h into the source line and add a 'SKIP' to the md5sums line for this entry. Then you'll have to copy or link the config.h to $srcdir/$_pkgname/src/config.h using the prepare function and it works as well.

I'll play with haapa a bit, maybe I'll even add some functionality (without knowing C ... good reason to start learning it ). Thanks for sharing!

msthev

Member

Registered: 2012-04-05

Posts: 177

Re: Haapa - A simple status program in C

A good pkgver:

pkgver() {
	cd "$srcdir/$pkgname"
	echo "0.$(git rev-list --count HEAD).$(git describe --always)"
}

Some questions:

• Will there be an option to pad numeric values so that the bar stays the same size when a value changes e.g. from 0 to 1000?

• Regarding i3 output: will it be possible to include several Haapa segments in a single i3 full_text segment? Currently each segment gets its own full_text, so it's impossible to get field value and description without them being separated by a pipe sign.

• Also, i3 output could be compacted a little bit (removing unneeded whitespaces):

  diff --git a/src/format.c b/src/format.c
  index af2cbc1..4d4f868 100644
  --- a/src/format.c
  +++ b/src/format.c
  @@ -33,10 +33,10 @@ Format *format_plain() {
   void format_i3_segment(char *buffer, char *str, char *color) {
   	char colorbuffer[64];
   
  -	strcat(buffer, ",{\"full_text\": \"");
  +	strcat(buffer, ",{\"full_text\":\"");
   	strcat(buffer, str);
   	colorbuffer[0] = 0;
  -	sprintf(colorbuffer, "\", \"color\": \"%s\"}\n", color);
  +	sprintf(colorbuffer, "\",\"color\":\"%s\"}", color);
   	strcat(buffer, colorbuffer);
   }
   
  @@ -44,7 +44,7 @@ Format *format_i3() {
   	Format *f;
   	f = format_init();
   	f->init = "{\"version\":1}\n[[{\"full_text\":\"Haapa says hello!\"}],";
  -	f->start = "[{\"full_text\":\" \"}\n";
  +	f->start = "[{\"full_text\":\"\"}";
   	f->end = "],";
   	f->segment = format_i3_segment;
   	return f;

Besides that, it looks really promising. I hope I'll be able to finally ditch Conky.

Last edited by msthev (2013-09-07 14:12:31)

Jgke

Member

Registered: 2012-04-05

Posts: 12

Re: Haapa - A simple status program in C

*stuff about config.h*

Yeah,  the current system we use is still somewhat WIP, we just looked how dwm did it and then left it there. We're looking at better ways to do it, thanks for suggestions

I'll play with haapa a bit, maybe I'll even add some functionality (without knowing C ... good reason to start learning it ). Thanks for sharing!

Thanks, good luck with that!

A good pkgver:

pkgver() {
	cd "$srcdir/$pkgname"
	echo "0.$(git rev-list --count HEAD).$(git describe --always)"
}

Thanks.

Will there be an option to pad numeric values so that the bar stays the same size when a value changes e.g. from 0 to 1000?

Yes.

Regarding i3 output: will it be possible to include several Haapa segments in a single i3 full_text segment? Currently each segment gets its own full_text, so it's impossible to get field value and description without them being separated by a pipe sign.

Yeah, we're both currently using a workaround for that in i3's config, having the separator the same color as the background. We are supposed to fix it at some point though.

Also, i3 output could be compacted a little bit (removing unneeded whitespaces)

Thanks, applied at my branch.

Besides that, it looks really promising. I hope I'll be able to finally ditch Conky.

Thanks.

msthev

Member

Registered: 2012-04-05

Posts: 177

Re: Haapa - A simple status program in C

Regarding my patch, it had whitespace issues (I copied the output from the terminal and it changed tabs into spaces). I edited my post to have the correct diff (so that `patch` and `git apply` work without problems).

Last edited by msthev (2013-09-07 14:17:46)

sekret

Member

Registered: 2013-07-22

Posts: 291

Re: Haapa - A simple status program in C

A good pkgver:

pkgver() {
	cd "$srcdir/$pkgname"
	echo "0.$(git rev-list --count HEAD).$(git describe --always)"
}

Do you really think so? This 0.*** makes it look like a real version number, which it clearly is not! But I'll leave it up to the devs, it's their choice.

HalosGhost

Forum Moderator

From: Twin Cities, MN

Registered: 2012-06-22

Posts: 2,097

Website

Re: Haapa - A simple status program in C

A good pkgver:

pkgver() {
	cd "$srcdir/$pkgname"
	echo "0.$(git rev-list --count HEAD).$(git describe --always)"
}

Do you really think so? This 0.*** makes it look like a real version number, which it clearly is not! But I'll leave it up to the devs, it's their choice.

There is no real standard for the pkgver yet, it's really just to set up one that is most recognizable and meaningful. This particular style has become common because it allows for the maintainer to define a major release at the beginning along with the commit numbers following. So, when the first stable release is made, the "0" will become a "1" and the rest of the function will remain unchanged.

Again, this is all personal preference for the maintainer of the package, but I find this style quite nice.

All the best,

-HG

---

Code of Conduct

Trilby

Inspector Parrot

Registered: 2011-11-29

Posts: 30,330

Website

Re: Haapa - A simple status program in C

As above suggest, the zero is completely optional.  I use a variation of this in my git PKGBUILDS - actually that exact function in interrobang-git.  In others I have an assigned major version number in place of the zero, such as "1.$(git rev-list ..."

I like this as the git rev-list count will always just be increasing - so it works: 0.101 is "newer" than 0.100 and even with a major version bump, 1.305 is "newer" than 1.304.  But this also allows for a bit more meaningful number representing a major version.  I've used a zero version number for tools that I haven't felt could be suitably called "complete" enough to have a full major version release yet.  I increment the major version number to 1 when I feel it is a complete package (man pages and all) and to 2 or more if/when there are drastic changes, often from a substantial rewrite of the code or a change in the basic design.  So *any* increase in version.subversion number will indicate that there is new code available, while an incrememnt of the major version number can indicate that there is a whole new creature ready to be installed - which may excite some users, or can be a suitable warning to others that old patches or configs will likely need to be rewritten from scratch.

But in short, this is all very subjective and there is no solid standard, except that however the version number is generated, it should provide an ordered count such that newer code always has a "greater" number than the older code.

Last edited by Trilby (2013-09-07 14:54:18)

---

"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman

Jukkeri

Member

From: Finland

Registered: 2013-09-01

Posts: 2

Website

Re: Haapa - A simple status program in C

Regarding i3 output: will it be possible to include several Haapa segments in a single i3 full_text segment? Currently each segment gets its own full_text, so it's impossible to get field value and description without them being separated by a pipe sign.

Hello,

I just added a "format_i3_manual", where you can define your own segments like this:

static const Segment segments[] = {
    {string,    text,            i3_manual_s, "",        is_format,   "i3_manual"},
    {string,    text,            "|",         "",        always,      ""},
    {string,    time_date,       "%T",        "",        always,      ""},
    {string,    text,            i3_manual_e, "#FF00FF", is_format,   "i3_manual"}
};

The is_format is optional, but nice if you want to distribute your configuration file. It's a somewhat hackish solution, but should work for now.

You can also use the macros i3_manual_start() and i3_manual_end(color) like this:

static const Segment segments[] = {
    i3_manual_start(),
    {string,    text,            "|",         "", always,      ""},
    {string,    time_date,       "%T",        "", always,      ""},
    i3_manual_end("#FF00FF")
};

As for the version numbering, I applied this one:

echo "0.$(git rev-list --count HEAD).$(git describe --always)"

Thanks for all of the feedback!

Last edited by Jukkeri (2013-09-07 15:14:04)

msthev

Member

Registered: 2012-04-05

Posts: 177

Re: Haapa - A simple status program in C

@sekret You are right, since this is a "-git" package, there is no need to have a "non-git" version compatibility. I use some -git PKGBUILDs without including "-git" in the name — it's then good to have "0." in the version, because if/when a stable version of the package is released, I don't need to set $epoch in the PKGBUILD. Here, this "0." is redundant, unless you do something like what HalosGhost and Trilby described.

@Jukkeri Thanks, testing right now.

Last edited by msthev (2013-09-07 15:01:33)