Closed fwsmit closed 8 months ago
To all, reading this here and thinking about maintaining a C program: Take the chance and do it!
I'm not doing any maintenance efforts anymore, but I'm still one of the top 4 contributors and I've learned coding C in this project.
@tsipinakis taught me the skills how to identify the problems C has and how to navigate around them. I still remember my first PR introducing a memory leak. It got covered up in his outstanding reviews. (Yes of course, memory leaks happen. That's the reason, why we introduced Valgrind in the CI/CD pipeline, etc.)
So, if someone wants to learn C, it's my duty to help YOU. In spite of this, if you want to become a dunst maintainer, but aren't able to code in C yet, I will offer you this: I will review your PRs, and nitpick the details to improve the code.
@zappolowski @bynect @matejdro this is your chance tot take @bebehei up for his promise and learn some real C coding! If you want to learn how to write and maintain a C program, let us know and we can more actively help you in that
@zappolowski @bynect @matejdro this is your chance tot take @bebehei up for his promise and learn some real C coding! If you want to learn how to write and maintain a C program, let us know and we can more actively help you in that
Although I know how to code in C 😂 I am up for the challenge of maintaining dunst. Let me know how to start and I'll do my best
Make yourself familiar with the build process.
Build dunst and make your self-built executable the replacement for your running dunst daemon.
Have a look at the current PR about meson build system.
Make yourself familiar with the build process.
Build dunst and make your self-built executable the replacement for your running dunst daemon.
Have a look at the current PR about meson build system.
I already have made several modifications to dunst (some are in my prs) and I am running a self built daemon. For the meson build process I am not too familiar with it as I mostly use makefiles.
@zappolowski @bynect @matejdro this is your chance tot take @bebehei up for his promise and learn some real C coding! If you want to learn how to write and maintain a C program, let us know and we can more actively help you in that
Although I know how to code in C 😂 I am up for the challenge of maintaining dunst. Let me know how to start and I'll do my best
Cool! You can take a look at HACKING.md for some useful information. I'll review your PR's when I have the time.
any news?
Sorry, didn't have the time to look at your patches yet. Maybe @bebehei has some time? Otherwise I'll try to look at it over the holidays
@fwsmit I didn't know where to ask, so I wrote here.
what is the current status of notification history? From what I know history is not stored in anyway and when dunst closes its gone. Was there any plan to support a serialization (json or whatever) of history for later use? Is it against some protocols to do so? I remember vaguely an issue talking about that but I can't find it anymore. Any idea on this?
It would be best to make a discussion for these type of questions. But to answer your question, history is not stored on disk. It can be retrieved during runtime via DBus and dunstctl, maybe thats the issue you remember. I wouldn't be against storing the history on disk. I'm not sure what the best way to do that would be. Maybe a database is overkill. I believe glib has some DBus serialization tools, which could be used to serialize the history to a file. It would need to be done every time the history changes, preferably in an efficient way. The notification spec says nothing about history as far as I know
It would be best to make a discussion for these type of questions. But to answer your question, history is not stored on disk. It can be retrieved during runtime via DBus and dunstctl, maybe thats the issue you remember. I wouldn't be against storing the history on disk. I'm not sure what the best way to do that would be. Maybe a database is overkill. I believe glib has some DBus serialization tools, which could be used to serialize the history to a file. It would need to be done every time the history changes, preferably in an efficient way. The notification spec says nothing about history as far as I know
I was thinking simply about json or something like that. I think I read an issue where a json vs human readable format was being discussed
Please welcome @bynect and @zappolowski as new Dunst maintainers! I'm excited for the future of dunst
With these new mainainters this issue can be closed.
Could you add yourselves as maintainers to the README?
Are the new maintainers going to introduce a way to reload a dunstrc file to make designing a theme less painful?
Are the new maintainers going to introduce a way to reload a dunstrc file to make designing a theme less painful?
See #1350
Lower maintenance
As you might or might not have noticed, the dunst project is currently in a lower maintenance mode. After more than a year of active contributions, I'm shifting my attention to other projects. Currently none of the maintainers are really active in the project anymore.
Consequences
What does this mean for dunst? Well, this means that you will probably not get a reply on issues you create in this repository. Bugs will also not be fixed by the maintainers. This does not mean that dunst is all of a sudden broken.
Looking for new people
We are looking for new people that are enthousiastic about dunst and would like to contribute to it. I will try to help you get started contributing. If you make a PR or tag me in an issue I will try to reply.
We have some resources for you to get started. The main resources are the README for information about building and installation. We also have a HACKING.md for some tips and tricks about how to more easily test and code on the project. You can also find the command to generate doxygen documentation to get an overview about the different classes and the project structure. Again, if you have any questions, please tag me and I will try to explain.