Re: [Evolution-hackers] Problems with calendar notification under unity (eds >= 3.30)
On Fri, 2019-01-04 at 14:07 +0500, Khurshid Alam wrote: > We can always query org.freedesktop.Notifications for that. Here is > basic patch that is working. Hi, it can be done, but it also means some kind of expectation in the code. What if the system the glib is running on uses different method for its GNotification-s? That's why it's more correct to (add and) use glib API. Imagine the same on MacOS or Windows, I doubt Windows implementation uses org.freedesktop.Notifications (if GNotification works there at all, because the developer documentation gives no guarantees). I'm not against the change, it can be added at least temporarily, until glib adds the needed API. > https://paste.ubuntu.com/p/Td4nGvWq2v/ Could you open a bug report against eds and add the patch there, please? I briefly read it, I didn't compile it, and it has some issues: a) an error message says "system bus", but you open session bus b) "to look up" in the error message sounds weird, neither I'm sure why you add g_get_user_name() into that error message. c) I'd prefer to use g_strcmp0() and g_clear_error() with changed 'error->message' to 'error ? error->message : "Unknown error"', just in case d) the code introduces a compiler warning (variables defined in the middle of the code block) e) the 'str' can leak f) the 'bus' can leak g) ideally call this only once and remember the result; it's highly unlikely that the notification server will change its capabilities in runtime, at least from my point of view, and D-Bus calls can cause delays. Having opened a related glib bug is also required, thus they can be linked together. Well, liked in a sense of gitlab, not the real linking with all the notifications and such as bugzilla used to do. > By default it doesn't add action if server doesn't support it, but it > can be made to do it. The default is fine. > This probably can't go in upstream since indicator-messages is not in > debian, but ayatana-indicator-messages is. Right, I'd like to avoid desktop environment specific code as much as possible. Also because that can require desktop specific libraries, which can limit the places where the code can be developed (as you enabled the MM in the DISTCONFIGURE parameters). Not talking that such code makes it harder to test properly (more code paths to verify by the testers and/or builtin tests). I'm thinking whether it would be helpful to make EAlarmNotify an extensible. In that case you could write an extension for it (instead of patching upstream code), that could live in your repositories. I'm not sure whether it might make things easier or worse for you, though. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Problems with calendar notification under unity (eds >= 3.30)
Hi, On Wed, Jan 2, 2019 at 5:32 PM, Milan Crha via evolution-hackers wrote: There's used GNotification and after a brief look I do not see any glib API which would allow to verify whether the notifications can have actions or not. That might be a call to them, to add such API, then evolution-data-server (eds) can use it. The eds doesn't use libnotify directly intentionally (it has less dependencies, especially when the same/similar API is provided by glib). We can always query org.freedesktop.Notifications for that. Here is basic patch that is working. https://paste.ubuntu.com/p/Td4nGvWq2v/ By default it doesn't add action if server doesn't support it, but it can be made to do it. I'm afraid it's not a question for me. You can disable evolution-alarm- notify autostart in its .desktop file for Unity and have things working as before, regardless whether users have installed also Evolution or not. At least for the time being, until that GNOME Shell's #155 is done. I rather use evolution-alarm-notify in unity. The implementation in indicator-datetime was for phone only. It has no concept of snoozing alarms on desktop. Alarm-notify was part of evolution before and evolution isn't default app in unity, hence the unity dev allowed to show notification in desktop too which never worked properly before. And phone is dead now, the code doesn't work anymore and we are thinking of removing entire phone-relate code from indicator-datetime to reduce workload. But now that alarm-notify is in eds, there is not harm using it and it works way better with new dialog. What would you exactly change on the eds side? I have made a small patch. https://paste.ubuntu.com/p/xYdbJfHCyb/ Atm, it just checks if current_desktop == 'unity', and doesn't check if indicator-messages is running or the app we are registering with is valid (can be done with g_desktop_app_info_new), but it works. I use gnome-calendar since it's the default app. Here is a screen-cast with both patch applied : https://youtu.be/oppUC-PWB7k This probably can't go in upstream since indicator-messages is not in debian, but ayatana-indicator-messages is. Everything is same just the library name changes and we are in transition to ayatana indicators. I am not sure how it can be made to work with both library, but network-manager-applet already did that. I will take a look later. I think the GNotification works on D-Bus, thus look there. Whether you'd be able to distinguish between notifications sent by evolution- alarm-notify and other notifications I do not know. Alarm notify itself doesn't send any special D-Bus signals. Again, all your work and time spent on this is only due to GNOME Shell's #155 not being fixed yet (well, as long as Unity derives from GNOME Shell). I just realized that I can use EReminderWatcher::triggered signal and it will work. Thanks. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Problems with calendar notification under unity (eds >= 3.30)
On Wed, 2018-12-19 at 13:21 +0500, Khurshid Alam wrote: > Hi Milan, Hi, I hope you know you address a mailing list with many subscribed users. It's fine by me (better than private email), but not everyone here is named 'Milan'. :) > In unity we also set notify-with-tray to false, so both dialog is > appearing at the same time. For the time being I set notify-with-tray > to true. Once GNOME Shell's #155 is closed/fixed, you won't use that. It had been expected (by me) to be in 3.30, but it didn't happen. > Will it be possible to check notification server capabilities before > adding an action ? There's used GNotification and after a brief look I do not see any glib API which would allow to verify whether the notifications can have actions or not. That might be a call to them, to add such API, then evolution-data-server (eds) can use it. The eds doesn't use libnotify directly intentionally (it has less dependencies, especially when the same/similar API is provided by glib). > But now since it is in eds I think it's better that we drop > notification related code fr om indicator-datettime. There is no > point replicating entire EReminderWatcher code into into it. I'm afraid it's not a question for me. You can disable evolution-alarm- notify autostart in its .desktop file for Unity and have things working as before, regardless whether users have installed also Evolution or not. At least for the time being, until that GNOME Shell's #155 is done. > For 2) I have a prototype code, it can be patched in eds or we can do > it from indicator-datetime or patch downstream. What would you exactly change on the eds side? > 3) Is there bus signal we can watch when a notification-tray appears > ? I am watching "notify" signal from ca.desrt.dconf.Writer and > checking 'reminder-past' in 'org.gnome.evolution-data- > server.calendar', but that's not very productive. I think the GNotification works on D-Bus, thus look there. Whether you'd be able to distinguish between notifications sent by evolution- alarm-notify and other notifications I do not know. Alarm notify itself doesn't send any special D-Bus signals. Again, all your work and time spent on this is only due to GNOME Shell's #155 not being fixed yet (well, as long as Unity derives from GNOME Shell). I think, if you've everything already implemented in Unity, then the easiest would be to just disable evolution-alarm-notify in Unity and avoid all the trouble pretty easily. Hope it helps. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Problems with calendar notification under unity (eds >= 3.30)
Hi Milan, 1) I was reading https://gitlab.gnome.org/GNOME/gnome-shell/issues/155, and in e-alarm-notify.c#L253 it is adding a notificatio action, i.e a "Reminder" button. The problem is under Unity, notification server (notify-osd) doesn't support notification action. And hence instead of notification-bubble it pops up a dialog which is obtrusive. See https://pasteboard.co/HSpZBsW.png. In unity we also set notify-with-tray to false, so both dialog is appearing at the same time. For the time being I set notify-with-tray to true. Will it be possible to check notification server capabilities before adding an action ? notify_get_server_caps (https://developer.gnome.org/libnotify/unstable/libnotify-notify.html#notify-get-server-caps) simply return a list of strings. And we can compare if it contains "action". If not then the server doesn't support notification action and we can simply show the notification without adding an action. 2) That brings the question how in unity we should show notification. Well in unity we can show notification in messeging menu and clicking it will simply bring forward hidden dialog from notification tray. If there is one single alarm pending, it will simply show evnt name with time, for multiple alarms it show "N alarms pending". See https://pasteboard.co/HSq5AWk.png See client-example.py in libmesseging-menu-dev (https://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.16.10/files/head:/libmessaging-menu/), I will come up with a better example later. And we can check session the same way we can check for gnome. On Ubuntu, XDG_CURRENT_DESKTOP is "Unity7:Unity:Ubuntu" For long we were doing things from indicator-datetime (https://git.launchpad.net/ubuntu/+source/indicator-datetime/tree/src/engine-eds.cpp?h=applied/ubuntu/devel), since evolution-alarm-notify was a part of evolution and evolution was not installed by default. But now since it is in eds I think it's better that we drop notification related code from indicator-datettime. There is no point replicating entire EReminderWatcher code into into it. For 1) I can file a bug in gitlab. For 2) I have a prototype code, it can be patched in eds or we can do it from indicator-datetime or patch downstream. 3) Is there bus signal we can watch when a notification-tray appears ? I am watching "notify" signal from ca.desrt.dconf.Writer and checking 'reminder-past' in 'org.gnome.evolution-data-server.calendar', but that's not very productive. Let me know what you think. Thank You. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
