Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dunst maintenance status #1117

Closed
fwsmit opened this issue Oct 18, 2022 · 16 comments
Closed

Dunst maintenance status #1117

fwsmit opened this issue Oct 18, 2022 · 16 comments

Comments

@fwsmit
Copy link
Member

fwsmit commented Oct 18, 2022

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.

@bebehei
Copy link
Member

bebehei commented Oct 27, 2023

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.

@fwsmit
Copy link
Member Author

fwsmit commented Nov 10, 2023

@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

@bynect
Copy link
Member

bynect commented Nov 10, 2023

@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

@bebehei
Copy link
Member

bebehei commented Nov 10, 2023

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.

@bynect
Copy link
Member

bynect commented Nov 11, 2023

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.

@fwsmit
Copy link
Member Author

fwsmit commented Nov 11, 2023

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

@bynect
Copy link
Member

bynect commented Dec 18, 2023

any news?

@fwsmit
Copy link
Member Author

fwsmit commented Dec 19, 2023

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

@bynect
Copy link
Member

bynect commented Feb 21, 2024

@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?

@fwsmit
Copy link
Member Author

fwsmit commented Feb 21, 2024

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

@bynect
Copy link
Member

bynect commented Feb 21, 2024

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

@fwsmit
Copy link
Member Author

fwsmit commented Mar 3, 2024

Please welcome @bynect and @zappolowski as new Dunst maintainers! I'm excited for the future of dunst

@fwsmit
Copy link
Member Author

fwsmit commented Mar 3, 2024

With these new mainainters this issue can be closed.

@fwsmit fwsmit closed this as completed Mar 3, 2024
@fwsmit fwsmit unpinned this issue Mar 3, 2024
@fwsmit
Copy link
Member Author

fwsmit commented Mar 3, 2024

Could you add yourselves as maintainers to the README?

@ctilley83
Copy link

Are the new maintainers going to introduce a way to reload a dunstrc file to make designing a theme less painful?

@bynect
Copy link
Member

bynect commented May 22, 2024

Are the new maintainers going to introduce a way to reload a dunstrc file to make designing a theme less painful?

See #1350

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants