Open Stunkymonkey opened 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.
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
I am considering using cairo
in the beginning and when all the other modules are more stable reconsider this question.
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.
@ZakharEl thats our plan :+1:
what about: glutin?
what we have to consider on wayland we have to use layer-shell which is currently not supported in all of the proposed ones.
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).
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 notificationsthings, i am not sure: idle-management org_kde_kwin_idle
maybe we could use swayidle
for this
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 useswayidle
for this
org_kde_kwin_idle
is the way to go. It's very simple to use and also implemented by wlroots.
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.
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 usegtk
(which is quite bloated).possible dependencies we can use:
if you want to get a quick look at
conrod
:@tsipinakis & @bebehei any comments?