search

durst-notification / durst

dunst written in Rust
6 stars 4 forks source link

how to render notifications #11

Open Stunkymonkey opened 4 years ago

Stunkymonkey commented 4 years ago

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:

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 commented 4 years ago

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

Stunkymonkey commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ZakharEl commented 4 years ago

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 commented 4 years ago

@ZakharEl thats our plan :+1:

Stunkymonkey commented 4 years ago

what about: glutin?

Stunkymonkey commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

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

fwsmit commented 3 years ago

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

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 commented 3 years ago

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.