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.

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!

Re: Haapa - A simple status program in C

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.

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.

msthev wrote:

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.

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).

Re: Haapa - A simple status program in C

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

"All errors are ᴘᴇʙᴋᴀᴄ errors—It's just a matter of narrowing down which keyboard and chair." -Trilby\ldots

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.

Re: Haapa - A simple status program in C

msthev wrote:

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:

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.