how to render notifications

[Stunkymonkey]

at the moment it is not decided yet how we are going to render the notifications. Sure we could use cairo like dunst did.

For the future I would consider, that maybe we want to add action buttons. These should be intractable via mouse and keyboard.

The disadvantage would be that the mouse interaction is quite limited in cairo and we would have to do lot of work ourself or use gtk (which is quite bloated).

possible dependencies we can use:

• tool-kits:
  • QT
  • GTK
  • GTK inspired by Elm
• rust-centric approaches:
  • Azul uses the Mozilla web-render back-end and uses more then 50mb ram
  • orbtk used in Redox-OS, but is quite sluggish
  • druid build on top of GTK, so ... no
  • conrod my current favorite, but not stable yet

if you want to get a quick look at conrod:

git clone https://github.com/PistonDevelopers/conrod.git && cd conrod && cargo run --release --example all_winit_glium

@tsipinakis & @bebehei any comments?

[Celti]

Have you considered iced, which uses wgpu and winit for its native backend?

[Stunkymonkey]

I have not considered it yet. Looks good.
But currently I am unable to get it to run on my laptop, since it only has an onboard intel gpu.

[Stunkymonkey]

a "problem" of iced:

We only support modern graphics backends for now: Vulkan, Metal, and DirectX 12/11.

so if you have Directx 10 you will not be able to run it

[Stunkymonkey]

I am considering using cairo in the beginning and when all the other modules are more stable reconsider this question.

[ZakharEl]

If I may add. Mad respect for what you guys are doing. I'm a fan of dunst-ctl. For durst I think you shouldn't provide any keybinding mechanism. Just provide good cli inteface/commands and people can implement their own keybind daemons whatever to keybind the cli commands approprately. Unix philosophy.

[Stunkymonkey]

@ZakharEl thats our plan 👍

[Stunkymonkey]

what about: glutin?

[Stunkymonkey]

what we have to consider on wayland we have to use layer-shell which is currently not supported in all of the proposed ones.

[fwsmit]

It's probably true that GTK is bloated, but on the other hand, most people already have it on their system. So it wouldn't matter much for the install. I don't know about the memory usage or how fast it is, but it's worth considering at least.
I think it's best to start with gtk (4?) and see if we want to replace it later (that's easier than starting with cairo).

[Stunkymonkey]

my current favorite is: https://github.com/Smithay/client-toolkit (often called sct)
because it supports all wayland protocols we need and is has basic text and image displaying options.

but is is quite a lot of work.

• layer_shell we are able to have a window in the corner (there is a demo in the sct)
• foreign_toplevel we could get if the active window is currently in fullscreen and delay notifications

things, i am not sure: idle-management org_kde_kwin_idle maybe we could use swayidle for this

[fwsmit]

my current favorite is: https://github.com/Smithay/client-toolkit (often called sct)
because it supports all wayland protocols we need and is has basic text and image displaying options.

That looks pretty good, although there are a few things

• It's wayland-only
• The documentation isn't very extensive
• I don't know if it would do all the rendering we would need, for example rounded corners

foreign_toplevel we could get if the active window is currently in fullscreen and delay notifications

I hadn't heard of that protocol. That could be useful to dunst as well, since it currently cannot detect fullscreen.

things, i am not sure: idle-management org_kde_kwin_idle maybe we could use swayidle for this

org_kde_kwin_idle is the way to go. It's very simple to use and also implemented by wlroots.

[Stunkymonkey]

we could have a look at https://github.com/ifreund/waylock on how to use the protocols. but currently my free time is quiet limited.