Allow compilation without X11

[bynect]

With these changes you can compile dunst with only wayland support.

Important note: At the moment I don't have a working wayland setup so I can't test if everything is ok. I guess so since the changes are minimal, but if someone with wayland could test this it would be great.

Update: Narrat reviewed the changes. Somewhere in the near future this will be merged hopefully

Closes #1008

[Narrat]

Compilation worked, and on the library side it looks good:

Both enabled:

Dynamic section at offset 0x31240 contains 38 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libXinerama.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libXext.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libXrandr.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libXss.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgdk_pixbuf-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-client.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-cursor.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Only wayland:

Dynamic section at offset 0x2cd00 contains 38 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libnotify.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libgdk_pixbuf-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-client.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-cursor.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Simple test also worked.
Waiting what happens if it's running for a longer time :D

[Narrat]

Maybe a bit strict, but shouldn't the comment be that global hotkeys aren't possible?
Hotkeys for active windows in general exist, but those don't work well with how dunst operates

[bynect]

you are totally right. I am not a great expert of wayland myself, so I was not sure what to write. Initially I thought that dunst didn't implement them, but then I saw that by design wayland didn't allow them (for dunst)

[bynect]

Waiting what happens if it's running for a longer time :D

It shouldn't really matter since I didn't really change the driver code and my only concern was if I messed some ifdefs 🙄

Anyway I'm glad that it works 👍🏻

[bynect]

I'll go ahead and merge this 👍🏻

[apprehensions]

This missed the test suite, which is required to build on Meson - since the test program shares the same dependencies as Dunst.

If it is needed, i can hide the test program behind a flag, which adds an extra step to running the test program.

[bynect]

This missed the test suite, which is required to build on Meson - since the test program shares the same dependencies as Dunst.

If it is needed, i can hide the test program behind a flag, which adds an extra step to running the test program.

This is an error on my part, I missed that part of the tests since it uses a "dummy output". I will push a fix shortly. So just account for having wayland, x11 or both. Also note that I put an #error in the output.h file so you don't have to check if they are both disabled and compilation will fail anyway

[apprehensions]

Also note that I put an #error in the output.h file so you don't have to check if they are both disabled and compilation will fail anyway

Nice, but it is very ugly:

meson.build:48:1: ERROR: Problem encountered: either wayland or x11 support is required

vs.

Additionally, configuring the project should handle this.

It is like preparing your food, but then realizing you forgot a key ingredient after cooking it, vs checking if you have the ingredient before cooking.

[bynect]

Also note that I put an #error in the output.h file so you don't have to check if they are both disabled and compilation will fail anyway

Nice, but it is very ugly:

meson.build:48:1: ERROR: Problem encountered: either wayland or x11 support is required

vs.

Additionally, configuring the project should handle this.

It is like preparing your food, but then realizing you forgot a key ingredient after cooking it, vs checking if you have the ingredient before cooking.

mmh. Maybe you are right. I am a little stuck with the makefile mentality 🤣

I will leave the #error just in case if someone tries to override the build systems, however I agree that if possible it should be handled "nicely". So if you can check please do so. I will make a check in the make config also.

[apprehensions]

I will make a check in the make config also.

That is a problem. Hearing this, i now feel dunst is trying to solve a problem when solutions exist, such as autoconf, cmake, meson, and so many others. If you want configuration without the need of build flags with a makefile, then use autoconf, or a required config.mk

At this point, i would just remove the Makefile, considering this got merged.

Don't get me wrong, i like Makefiles, but please: use the right tool for the job. Make is good for simple projects, but in the context of Dunst, where there is many source files, build features, version control, tests, documentation, making use of Makefile is not fit for this purpose.

[bynect]

I will make a check in the make config also.

That is a problem. Hearing this, i now feel dunst is trying to solve a problem when solutions exist, such as autoconf, cmake, meson, and so many others. If you want configuration without the need of build flags with a makefile, then use autoconf, or a required config.mk

At this point, i would just remove the Makefile, considering this got merged.

Don't get me wrong, i like Makefiles, but please: use the right tool for the job. Make is good for simple projects, but in the context of Dunst, where there is many source files, build features, version control, tests, documentation, making use of Makefile is not fit for this purpose.

the fact is, make has been used from the start, so removing it point blank is not possible. It can be removed, but we must give users a bit of time to switch. Also we need to document this changes. But I understand your point