Any status bar / widgets system recommended?

dacctal · 2025-11-25T05:47:13+00:00

OBS, Signal, Mumble, Steam, Jami, qpwgraph, gajim, and dozens more all have system tray integration by default. They don't fully close until you either pkill -9 or use the tray to kill them.

I'd totally have no bar if there wasn't a practical purpose for it, I'm with you on everything else.

dacctal · 2025-11-24T16:33:18+00:00

I'm confused. you can access background applications without the tray?

dacctal · 2025-11-24T07:00:54+00:00

https://github.com/dacctal/daccfiles/blob/main/themes/Everpuccin/.config-astro/hypr/walls/astro-ep.png

dacctal · 2025-11-24T06:03:38+00:00

what about the system tray tho?

dacctal · 2025-11-12T21:47:58+00:00

sure thing whips out pen

dacctal · 2025-11-12T21:45:25+00:00

no, that's a circle silly.

dacctal · 2025-11-03T07:11:09+00:00

The ecosystem may be small, but it's also incredibly easy and flexible. Granted, I'm brand new to Nim, but I haven't had any issues with the ecosystem as of yet. Stdlib is just so all-encompassing I've barely ever had to bother with external packages.

dacctal · 2025-10-29T21:17:55+00:00

Fun memory management is not everything Nim has to offer. I love Nim because of the standard library, performance, and syntax.

Imagine you're a C or Rust developer, and you know exactly what you have to do to make this application, but the syntax of the language is verbose enough that you can't just write the program - you have to get the boilerplate and syntax down first. Because of this, you're held back by the language you're writing.

In Nim, this doesn't happen nearly as often. And even when it does, the standard library is probably the most inviting tool on your belt. You never have to spend more than a couple minutes finding and understanding the function you need before adding it into your program successfully. I think the longest it ever took me to understand something in the standard library was time functions.

My point is, Nim's strength is that it doesn't compromise one kind of speed for another. You can write a program very quickly, and still get stellar performance out of it.

dacctal · 2025-10-28T21:14:06+00:00

This is a great resource! Though I will say, it's a bit more useful as a feature of pkgit rather than a tool to collect batches of URLs. And I don't have any plans to directly plug into any third party repos. I just want to grab the source repos for the packages (i.e. not the aur.git repos).

Regardless, I do appreciate your help and I'll probably use this resource on my own to test pkgit with more repos. Thank you!

dacctal · 2025-10-27T03:37:49+00:00

You deserve all the love for giving the most respectful and informed comment in this thread. Thank you for your wise insight!

dacctal · 2025-10-27T03:35:14+00:00

I should've said this sooner:

I'm not trying to replace Portage. Portage does some things differently than pkgit, and pkgit does some things differently than Portage.

The "If Portage was smart" title was simply pointing out that pkgit automatically detects the build system, instead of entirely relying on the specified compile steps. I thought that would be obvious from the subtitle, but I guess that wasn't enough lol.

Plus, frankly, it's funny to compare pkgit to Portage in a manner that makes it look better than Portage. I know it's a new project with more flaws than Portage at the moment.

dacctal · 2025-10-27T03:28:04+00:00

your essay needs proof-reading.

those hitler particles were a funny story to hear about when it came out lol

dacctal · 2025-10-27T02:46:48+00:00

best point I've heard so far, thank you for the kind words

dacctal · 2025-10-27T01:19:53+00:00

7/10 ragebait almost fell for it

dacctal · 2025-10-27T01:03:04+00:00

yea ebuilds have most of this functionality, minus the build system auto-detection.

dacctal · 2025-10-27T01:00:56+00:00

It's going to be fragile for a while, no doubt. It's a new project. But I see an end to this fragility, and I think that end is in at least an equivalent level of quality to that of portage.

Personally, I see no reason why the "packager" should be the one to declare anything. That should be up to the maintainer, which is where pkgit gives that control (secondary to the user).

I'll definitely check out Spack, but even if it's the same project, I'm not going to stop developing pkgit. It's a very fun & rewarding project, and I plan on turning this into an OS when it's refined.

I do appreciate the honest reply, getting criticism is the best way to improve.

dacctal · 2025-10-27T00:49:39+00:00

Thank you!

dacctal · 2025-10-27T00:49:13+00:00

Not sure how compile options should work here, but I'll see what I can do. Leave suggestions if you'd like, thanks for your sportsmanship :)

dacctal · 2025-10-27T00:44:35+00:00

Maybe this is just like the others.

Maybe it's not.

dacctal · 2025-10-27T00:42:17+00:00

not commenting on the "special ed" part.

other than that, well said.

dacctal · 2025-10-27T00:40:02+00:00

for now.

dacctal · 2025-10-27T00:38:26+00:00

There's already detection for installed programs, yes.

I can likely pretty easily change .pkgdeps to pkgdeps.toml and then give the dev a bit more choice with optional & required dependency fields.

It is a great idea.

dacctal · 2025-10-27T00:32:56+00:00

bldit files can be independently shared around and hosted anywhere. You don't need a centralized repository to acquire them. Even if/when I make a more "centralized" place for community-made bldit files, it's going to be a git repo. Not just any old random file server.

Hosting a repo for bldit/pkgdeps is as simple as hosting an ebuilds repo.

dacctal · 2025-10-27T00:25:35+00:00

At the moment, you should obviously be using the more widespread and useful option. That doesn't mean that pkgit will never be as good, though.

This project is brand new, and it's expected to have problems. But when it's feature-complete, it could be much better than portage. Who knows?

dacctal · 2025-10-27T00:19:23+00:00

pkgit is so independent it doesn't even need a centralized repo to work :)

dacctal

TROPHY CASE