Tdesktop: Use native notifications in Linux

[edubxb]

Use the desktop native notification system in Linux to a better user experience.

[tanwald]

For most distributions this could be achieved by implementing the org.freedesktop.Notifications interface (https://developer.gnome.org/notification-spec/).

[hai-nguyen-van]

Or just use libnotify library which is the official notification library for most distributions (incl. Ubuntu). You can for instancen have a look at GNotifier (authored by @mkiol) which transfers Firefox/XUL notifications to generic system notifications.

[ezdev128]

I'm fully agree wih @EmptyStackExn about libnotify.
Also, it's good to have a choice between Telegram's notifications and OS's system (notify)

[bardo]

This would be great for UI consistency and it would also allow for free notification customization.

[lindhe]

That would be great! The notifications that are now always obscures the input field for me.

[png2378]

That would be very cool!

[beamju]

:+1:

Also needs support for gnome 3.16 notifications that can work like that:

[AsavarTzeth]

I too would love to see a libnotify implementation of Telegram notifications. If I am not misstaken, it should have easy to use bindings for QT.

[davcri]

:+1:

Clementine (a multiplatform/Qt music player) leaves choice to the user. Source code can be found here https://github.com/clementine-player/Clementine

[ghost]

Notification like Clementine is a clever idea :+1:

[davcri]

I just discovered a nice project for notifications and Qt: https://github.com/Snorenotify/Snorenotify. I don't know if it can be really useful for this purpose, but it's good to take a look.

[WhyNotHugo]

@davcri Looks like they support the XDG desktop notifications, so it'd work great, plus, notifications for other non-X OSs come for free.

[SanKro]

Problem is that telegram dont link to external souces. its one binary blob with all dependencies inside. thats not always possible with licenses other projects (like snorenotify)

[Senpos]

Would be nice to see.

[imcatwhocode]

It will be very nice feature.

[l4rzy]

The native notification looks good on Windows 10. it will be great on Linux, too :+1:
Take a look at libnotify
https://developer.gnome.org/libnotify/unstable/NotifyNotification.html

[auchri]

@davcri I'm not sure, but does Snorenotify use the same license (LGPL-3) as Qt?

If yes, why we cannot use it? @SanKro

[davcri]

Yes it seems to use LGPL3: https://github.com/Snorenotify/Snorenotify/blob/master/COPYING.LGPL-3

[auchri]

So it should be no problem to implement it in telegram desktop?

[davcri]

I'm not very experienced with these things, but I don't find any problem in using it.

[WhyNotHugo]

Indeed using it would not cause any licensing issues. LGPL allows you to link to it freely. Any changes made _to the library_ must be shared under the LGPL alike (though you usually don't need to modify it).

Also, since tdesktop is GPL, this library should not bring any controversy or dislikes amongst authors either.

[nortexoid]

The Qt build of QupZilla also allows the use of native or its own notifications.

[sergioad]

:+1: I want to see native notiffications for Linux too and maybe an option to use a non native titlebar (like Chrome or Vivaldi) with the same colour of the app's toolbar, I want a more consistent and good looking app, Windows has EVEN the amazing GNOME liike client side decorations and we do not have them having GNOME one of the first desktops wich fully adopted the CSDs; maybe we can not use a CSD looking app because of Fluxbox Openbox and KDE but maybe the posibility to use a Chrome like non native titlebar could be really good

@auchri could you see what to do with the notiffications and the titlebar? also if you make TDesktop compatible with KfileChooser and Gnome file chooser and use them on KDE and GNOME respectively instead of the generic Qt file chooser and fuse the hide / show Telegram Desktop menu entries on the tray icon's rght click menu I will thank to you a lot

And me too, I do not use a lot TDesktop because of the lack of native notiffications, I use mostly Cutegram but it does not works at all for me on Ubuntu so I use TDesktop on Ubuntu derivates

[bestbug456]

Hope you will implement soon this feature!

[EvelynSubarrow]

++
It blocks both my clock and my view of weechat's input. For now I've disabled notifications, but this isn't my preference.

[psamim]

+1. Telegram's notification is displayed on the chat messages! So I cannot chat if a notification appears. We need full control and a native notification system.

[WhyNotHugo]

Indeed, the lower corners are the most annoying possible. Any time I need to use a terminal, or a chat window, that's where my cursor is, and telegram keeps popping up notifications on top of it.

What's worse, unlike my native notifications, there's not hotkey to close them, so I need to stop working, grab my mouse, and point-and-click. It's absurdly annoying.

[sergioad]

@telegramdesktop please add them :smile:

[makruiten]

I too would like this. It would provide us with a much better way to see missed notifications without opening the app and they would appear on the lockscreen as well. Hope you'll implement this soon.

[nortexoid]

One way to get native notifications is to use the web app, and install the Firefox extension/add-on called "Gnotifier" which lets Firefox use your system's native notification system. Not ideal since you can't access telegram from your system tray, but better than non-native notifications if you ask me.

[nortexoid]

Over a year old, lots of discussion, presumably not difficult to implement, and yet not a single comment by telegramdesktop. Don't get your hopes up!

[fbt]

Would also be nice to have telegram set the WM urgency flag btw.

[nortexoid]

Perhaps this is relevant for developers: https://github.com/KDE/snorenotify

[Igetin]

+1.

Legitimately wondering what is the reason @telegramdesktop even uses GitHub if absolutely no comments on their part are given to this issue in a whole year.

[telegramdesktop]

@Igetin Because it is a good way of holding an open source project :) issues are hold open mostly for critical bug reports. Talking about that particular issue — "I didn't get to it yet".

[WhyNotHugo]

@Igetin FWIW, nobody has come up with a patch/push-request for this either. This issue here means it's open for anyone interested to fix it, but it seems that nobody interested _and_ knowledgeable enough has come around, regrettably.

[AlessandroLongo]

@sergioad maybe you are interested in this
Plasma tricks: custom title bars for apps and some consistency

[sergioad]

@AlessandroLongo cool, thanks for the tip :smile:

[telegramdesktop]

@mrshadowtux I'll try to use this thing some day:

https://developer.gnome.org/libnotify/0.7/NotifyNotification.html

if it uses what you want, then this will be done. If not — I'm not sure.

[SanKro]

@telegramdesktop wouldnt it be better to use https://techbase.kde.org/Projects/Snorenotify

cause of:

Backends
_Windows Toast Notification_
_OSX Notification Center_
_Free Desktop Notifications_ (this one is what libnotify does)
Growl
Snarl
Integrated Notification Backend
System Tray

on top of that its Qt already. so you would have native notifications on all plattforms.. not linux only

[auchri]

@SanKro see my comment here: https://github.com/telegramdesktop/tdesktop/issues/1610#issuecomment-183979008 :smile:

@telegramdesktop Why don't use something like https://github.com/KDE/snorenotify? The licence of Snorenotify is also compatible with the licence of tdesktop.

[PandorasFox]

@telegramdesktop that is indeed what I was thinking of - libnotify's binary is notify-send and sends the notification to the user's notification daemon and allows for native notifications.

@auchri that's not native notifications; it doesn't support Linux's notification daemons. For example here - libnotify is an implementation of the desktop notification standard; snorenotify doesn't list that as one of their backends and won't be native.

nevermind, I missed the freedesktop notifs. I needed coffee.

[SanKro]

@Arcaena you're wrong. snorenotify uses dbus to communicate. thats the freedesktop standard.
Telegram+snorenotify integrated > dbus > usersdesktop

on your side it would be like this
telegram > bash > notify-send > dbus > userdesktop

libnotify has also the disadvantage that you need to have it (wich is only a GTK desktop thing, cause no Qt desktop has it preinstalled.. there is no need for).

snorenotify can be integrated into the telegram binary and used on windows and osx too without dependencies outside...

so from the users point of view its much better to use snorenotify
from devs pov its even more secure because it communicates directly with dbus, not with an external pipe + external dependency...

@telegramdesktop

[PandorasFox]

actually yeah, I looked at the snorenotify docs before I had my coffee and completely missed it listed in their supported backends, so it should work fine. My bad.

[auchri]

And @telegramdesktop would not have to write the notification code for every platform

[WhyNotHugo]

Regrettably, I'm far from being proficient with C++, but for someone who is, using snorenotify shouldn't be too complex:

https://github.com/KDE/snorenotify#qmake
http://hannah.von-reth.de/snorenotify/doc/0.7.0/classSnore_1_1Notification.html

From what I can tell, Telegram/SourceFiles/window.cpp is where Notifications are call, but I may be mistaken.

[1358]

using Snorenotify is incredibly easy:
https://github.com/jendas1/Snorenotify/blob/master/examples/Simplest%20notification/main.cpp

[telegramdesktop]

@auchri it doesn't look that good.

For example it does not support reply from notification on OS X, no subtitles and thumb images in OS X notifications (all this is already in tdesktop) and in Win10 notifications (which I hope to add in the near future) + it requires shipping of additional binaries on Windows (which is not an option with current way of the autoupdating and everything works) + I don't see options to remove already shown notification (at least in OS X).

I didn't yet look if it does play well with Qt static linking (there are some problems with plugins in that approach as I know). But it looks like supporting libnotify on the systems where it is (dynamically loaded) is better for tdesktop.

[mrshadowtux]

Loading it dynamically would be perfectly fine, no need to link it static

[WhyNotHugo]

For example it does not support reply from notification on OS X, no subtitles and thumb images in OS X notifications (all this is already in tdesktop) and in Win10 notifications (which I hope to add in the near future) + it requires shipping of additional binaries on Windows (which is not an option with current way of the autoupdating and everything works) + I don't see options to remove already shown notification (at least in OS X).

That's a pretty bad situation we've landed in. Looks like you're make full use of the OS X notifications, while using broken notifications for *nix/Xorg.

Maybe this can be used everywhere _except_ OS X, and keep using current code there?

Regarding conflicts with auto-updating: we don't really need that on most *nix distributions, since they already come with a package manager that does the job for us, so again, maybe OS X could be exceptional?

[telegramdesktop]

@hobarrera I'm talking about Snorenotify as a cross platform solution for all tdesktop needs. As I can see, it won't work as a Windows Toast Notifications implementation as well for the same reasons. Perhaps it could be used as a linux-only notifications solution, but will it be much better, than just libnotify support? Because it looks much easier for me to support libnotify. I can't just disable linux inapp autoupdate saying "everyone who uses tdesktop on linux should use some third party package wraps around the software we're building", as I can see huge amount of linux users just takes the app from desktop.telegram.org and uses like all other OS users do.

So at least now all the additional libraries used in tdesktop should provide one of two possibilities: 1) a way to static link them to the current single tdesktop binary without adding any additional dependencies, or 2) dynamic load them from the current single tdesktop binary without shipping them, but just using on those systems that have this library installed (like unity icon counter api is used currently).

[WhyNotHugo]

Given what you describe, I must agree: using libnotify (xdg notification spec) would be the best overall solution.

Slightly OT: I'm impressed that so many linux users download from desktop.telegram.org. Maybe downstream distributions aren't packaging telegram, so users are forced to perform a manual install?

[telegramdesktop]

I didn't dive enough in Linux world yet to manage different packages in different package managers for different distributions, I don't know how much of them there are at all and which I should support and what work exactly should I do myself (tdesktop is first and only piece of software I've done for Linux), so I just suggested the guys who know much more about Linux do what they think is best with the code or the binaries that I build - I even don't know who or how creates the packages or makes them available for the package managers.

[1358]

I'd like to install and updatetelegram the system package manager, as telegram's builtin updater does not work with restricted permissions.

[telegramdesktop]

Yes, the builtin updater requires the permissions to rewrite the binary with a new version.

[WhyNotHugo]

We're diverging a bit off-topic, but I guess this is relatively important:

You don't really need to package for distributions yourself (it's endless work that's not really the best use of your time, plus, I don't think you enjoy it).
Generally, some developer, or trusted users, or something alike that from each distribution will package the app and make it available to other user via that distribution's repositories, so all you really need to do is provide the tools for packagers to do it.
Currently, build instructions are missing (point-and-click instructions are not useful because they can't be scripted, so nobody downstream can use that).

The fact that the builtin updater requires permissions to rewrite the binary is also quite weird. Only power users will have something like ~/.bin and add that to their $PATH. Anybody else would probably run it from /usr/bin (or something similar), so they can't rewrite the binary. Allowing for that isn't really something that you'd see in *nix (since it's a trivial path to privilege escalation). Generally, package manager do all that sort of work, and having a second app duplicating work is generally frowned upon.

[telegramdesktop]

@hobarrera Well, currently you just download the app, extract it whereever you like (on Desktop, for example) and use it from there — and it works with builtin updater in all supported OSes (Windows, Mac OS X and Linux).

[1358]

linux updating and packaging should be continued in #1616

[SanKro]

@telegramdesktop

than just libnotify support? Because it looks much easier for me to support libnotify.
when you cant use snore for all plattforms, thats a good point.
However. please dont implement notification via "notify send", but using then libnotify itself
https://wiki.archlinux.org/index.php/Desktop_notifications#Usage_in_programming

maybe we can also ask the snoreguys for support yet unsupported things @TheOneRing in future relases.

[jakevossen5]

+1

It is really annoying to have everything be all the same, then getting a telegram notification from the bottom right instead of where the rest of my notifications come from.

[polymorphm]

I uninstalled this application IMMEDIATELY once seen _custom_ (not native) notifications :-)

please, do not scare away other other-people like me

[Brawaru]

It's April Fool's joke? It is what you want?

@polymorphm :scream: OMG!!! Sorry, sorry! We did not want this!!!

@ john-preston did you see this?! You urgently need to implement native notifications!!! Your software scare people like @polymorphm.

**@ auchri, please attach label !!!!!!!!!!!!!!!!! (oops, CSS)

How could you allow this?! We lost @polymorphm. Hard times coming...

Ooh, nope. It will not be so.

[polymorphm]

It's April Fool's joke? It is what you want?

[... ... ...]

:-) , yes :+1: .. well approximately :-)

Ooh, nope. It will not be so.

In this case -- very sorry, for my spam

// P.S.: it was just true feedback .. I know that is nobody care .. but I wrote it.. sorry

[maximbaz]

@telegramdesktop please make it optional, I understand that I represent the minority here, but I actually like the current notifications more :smile:

People like me, who are happy with the current notifications, won't usually stumble upon this thread to vote, unless you take the current UI away from them :smile:

Something like what @davcri proposed here would be nice, or at least a simple flag in configuration file if you don't want to spoil the Settings UI - but don't remove the current functionality completely... pretty please? :smile:

[WhyNotHugo]

@telegramdesktop please make it optional, I understand that I represent the minority here, but I actually like the current notifications more :smile:

Why not configure your OS's notifications to look like Telegram's if you prefer how they behave/look?

[maximbaz]

@hobarrera: primarily due to the absence of knowledge on how to do that and time to investigate, multiplied by the number of people who are just like me enjoying something that is already implemented for us.

However, if you can suggest a notification daemon to try, that would work after a relatively low effort of configuring it and look similar to Telegram's, I'm willing to try it out - then we can suggest it for other people as well. Today I use dunst, which is not very much configurable to my knowledge.

[fbt]

You can configure a lot with dunst (size, position, colours, fonts...), but it doesn't support showing images. If that's a dealbreaker, then a few other notification daemons are mentioned here: https://wiki.archlinux.org/index.php/Desktop_notifications

[ConstruKction]

@maximbaz
The problem with Telegram not utilizing native notifications system is that one cannot even perform a task as simple as changing the position of the notification, or have them integrate with GNOME look & feel. The former is very annoying, especially when your taskbar, and all the other notifications are at the top.

[maximbaz]

Just to make sure, I'm not arguing that we should drop this idea, I read this thread and I see the benefits.

What I'm asking is simply not to remove the currently existing functionality at once, for the reason that not everyone has time to start digging into how to configure their notification managers immediately once the app updates and the beautiful notifications are gone.

Simple way - provide an option for a user to choose, through UI or via a config file. If necessary, make it clear that the native notification system is the future, and the custom one will not be improved anymore (but still available). Even better, make it simple for people to handle the transition, that could be a wiki page with font, colors, dimensions, or even examples of configs for popular notification managers.

Now, personally I think I would switch to native notifications at some point anyway, especially if I know that it provides some abilities, that cannot be achieved via the obsolete notifications. I just don't want to be _forced_ to do it immediately once the app updates on my laptop, as I might not have time to do that.

[WhyNotHugo]

Actually, the worst problem of all, is that they cannot be closed trivially. I close my [normal] notifications with alt+space. If I don't have my mouse nearby, I can't close the telegram notifications. It's also an accessibility issue, actually.

To make things worse, they're positioned in the worst possible location: where the input field for telegram/terminals/etc is located.

[nortexoid]

I would prefer that they remove non-native notifications in favor of native ones, in favor of cleaning up the code base (making it easier to maintain) and not duplicating functionality.

[PandorasFox]

No reason to remove choice.

I'd rather avoid a repeat of the adaptive widescreen issue: there's no reason to mess up what people currently want if that's what they want.

[fbt]

I would prefer that they remove non-native notifications in favor of native ones, in favor of cleaning up the code base (making it easier to maintain) and not duplicating functionality.

Agreed. Native notifications can usually be customized, are consistent in the scope of a given environment and probably even require less code to implement.

[cauebs]

I just installed Windows 10 and noticed that Telegram Desktop supports native Windows notifications and you can disable it to use the normal notifications. Whats stopping us from having it on Linux as well?

[dj95]

I tried to implement notifications with libnotify, but there seem to be incompatibilities between tdesktop in glibmm 2. 4 in combination with libnotifymm 1.0.

[jhasse]

It didnt compile?

[dj95]

No, it didn't.

[yurividal]

Deffinetely libnotify is the way to go. All native apps in modern linux distros use libnotify for a consistent UI

[Tids]

@yurividal but doesnt libnotify require gtk+ at some level? so we have a dependency not only Qt, but also gtk+?

why not using some the notification part of kde framework5 -> http://api.kde.org/frameworks-api/frameworks5-apidocs/knotifications/html/classKNotification.html
(remember that it wont pull in "the whole KDE", since there is no KDE anymore:
https://en.wikipedia.org/wiki/KDE_Frameworks_5

and of course it would be a bad idea to make use of the libnotify-send binary, since there are desktops who dont ship libnotify like a pure lxqt, Plasma, lumina (and maybe also some WM (?))

[WhyNotHugo]

but doesnt libnotify require gtk+ at some level?

libnotify uses a standard dbus-only spec. There's no dependency on anything except dbus.

why not using some the notification part of kde framework5

How would this work outside KDE?

[Tids]

@hobarrera again... there is no "KDE" as in KDESC anymore. The Desktop, made _by_ KDE, is Plasma. Plasma has a dependency on Qt and Framework5. Framework5 has no dependencies on Plasma. Framework5 are just some extensions for Qt.

libnotify uses a standard dbus-only spec. There's no dependency on anything except dbus.

https://wiki.archlinux.org/index.php/Desktop_notifications#Usage_in_programming -> c++

Dependency: libnotifymm
https://aur.archlinux.org/packages/libnotifymm/

Dependencies
gtkmm3
libnotify (libnotify-gtk2, libnotify-id, libnotify-id-git)

https://www.archlinux.org/packages/extra/x86_64/libnotify/ [...]
or you use the systemwide notify-send but in this case desktops without notify-send wont see any notification

How would this work outside KDE?

it will work as long as you ship the dependency (this knotify is tier2, so it depends on tier1 things and Qt of course). you can already try it. if you're on manjaro or arch, just install quassel-client (its a nice Qt IRC Client). i'm using it on my manjaro XFCE (without plasma or any other kde app). notifications are visible and use the look and feel of my normal notifications.

[sharifzadesina]

2 years later!
any fix for this?

[auchri]

any fix: no
any PR: no

[sharifzadesina]

@auchri are you waiting for PR? really why? is it hard to implement in 2 year? or linux is not important for you?

[fbt]

telegramdesktop account has answered in the thread in February. It's obvious that the issue is at least not completely forgotten two years ago.

[auchri]

@evgenymarkov And how is the file picker related to the notifications?

[cauebs]

Ok, if we're not getting native notifications, can we at least have some more settings for notifications?
How about duration and position, for example?

[jhasse]

some more settings for notifications?
How about duration and position, for example?

Please don't reinvent the wheel. Native notifications are the way to go.

[png2378]

GTK file chooser is first step to better linux integration, please don't stop and go to next step - libnotify support :stuck_out_tongue_winking_eye:

[SanKro]

@png2378 As long as there is no "dbus-dialog" that is supported by all linux desktops, and chooses always the native dialog of an desktop, it just would be stupid to support gtk-file dialogs, because they simply dont look good on Qt-desktops. So for telegram, because its an Qt app, its just good to use whats available and dont create another dependency.

libnotify would be good, but not as "libnotify-send"-integration... cause not every desktop who can display notifications and uses the standard notification model, also uses libnotify.

[null-von-sushi]

Still waiting for this to be implemented. At this point I am seriously considering uninstalling telegram and using the pidgin/libpurple plugin instead.

[WhyNotHugo]

Still waiting for this to be implemented. At this point I am seriously considering uninstalling telegram and using the pidgin/libpurple plugin instead.

FWIW, I moved to Franz, which is pretty much telegram-in-a-webview (and a few other IM protocols). It uses native notifications, though it's quite CPU hungry, regrettably.

[AndydeCleyre]

@hobarrera yeah sadly I think tdesktop devs prioritize a "unified" experience over a "native" one, but it's still the best desktop client out there.

FWIW, Rambox is like Franz but open source.

And I'm pretty sure the number 1 reason an apparently significant number of Linux users are resorting to the unpackaged, self-updating web-page-download rather than a proper package is #1815 -- but again, sadly, I don't think the devs are much interested in prioritizing that.

[WhyNotHugo]

FWIW, Rambox is like Franz but open source.

Sorry to continue the off-topicness, but Franz is also FLOSS.

And I'm pretty sure the number 1 reason an apparently significant number of Linux users are resorting to the unpackaged, self-updating web-page-download rather than a proper package is #1815 -- but again, sadly, I don't think the devs are much interested in prioritizing that.

Yes, it's a shame. The devs could really get a lot of work of their hands if they made this package-able _and_ would get a lot more userbase.

I think the issue is in part that other OSs don't offer things like package management or similar basic features, so they still need to focus on those for those OSs.

[AndydeCleyre]

@hobarrera

Franz is also FLOSS

I don't believe you.

[davcri]

I don't think that Franz is free software or open-source. Also, I foundi this: https://www.reddit.com/r/Telegram/comments/48lv8n/franz_messenger_for_telegram_whatsapp_and_other/

Hangouts doesn't provide an API for third party apps to access messages, so third party devs cheat by "scraping." This is where you write some backend code that pretends to be a web browser browsing to the Hangouts website. The code parses the messages out of the web content ("scraping" the messages) and relays it to you.
This is bad for two reasons:
It's incredibly insecure. You're giving your password to the third party dev in plaintext, because they require it to sign into your account. This effectively gives the dev full, unrestricted access to your Google account.
It's against Google's AUP on both sides. It's against Google's AUP to give your password to anyone and it's against their AUP to screen scrape and pretend to be a Google client.

[auchri]

Back to topic please.

[john-preston]

@hobarrera #1815 just can't be reliably done, because without using the private APIs of Qt you'll need to write the whole new text processing for tdesktop — it is close enough to write a completely new app perhaps a little bit based on what is done here, in this project.

[WhyNotHugo]

Still, packager friendlyness can be done without #1815. A good step in that direction would be to make your current build scripts public (eg: the ones you already have for creating the official binaries). They would, at least, serve as a reference to packagers.

I have partially addressed this via #1647 though, but I feel that this may have inadvertently grown out-of-date.

[Algram]

I would like to try and implement native notifications on Linux via libnotify if I find someone else to help me with it.

[SanKro]

@hobarrera meybe the AUR pkgbuild can also help to create a pkg for other distros https://aur.archlinux.org/packages/telegram-desktop

[john-preston]

@hobarrera The script just invokes qmake and make, other preparations are for debug symbol dumping etc.

[lindhe]

@Algram I have never worked with libnotify before, but I'd love to help if I can. You have a fork and branch for it?

[Algram]

@lindhe Me neither, but it does look doable. I've forked and added you as collaborator.

[john-preston]

@all I'm playing with libnotify right now in Ubuntu (where I build the app) and I don't understand how you can ask for it at all %) This is a nightmare:

1. you can't close a notification in any way, just wait for it to disappear.
2. you can't handle any event like click or whatever so that the conversation will get opened where the new message arrived.
3. you can't programmatically close a shown notification (notify_notification_close() simply doesn't work).

(3) just makes it absolutely unusable - if you somehow get to a floody chat and receive 1000-2000 messages, there will be 1000-2000 notifications sent by libnotify, that will arrive each in 10-12 seconds one after another -- and the app has no way to cancel them once you open the conversation and mark it as read (or disable notifications in it) or even close the app at all. You'll just keep receiving them for the rest of the day. So they're just like something you should never use in your app.

What do I miss? Or should I enable them only in some specific DE / Graphical shell, which surely must not include Unity? Disabled by default of course.

[Tids]

@john-preston

1. thats a Ubuntu/Unity notification implementation thing. They want notifications like this. on normal desktops you can close them while using libnotify (please try out a KDE Plasma since they are mostly always involved in freedesktop standards.
2. Also a Ubuntu/Unity. Normal desktop behavior is different
3. thats a thing i dont know

[portaloffreedom]

It's true that they have some downside. But as stated by @Tids some of them are Unity-only problems. About 3. is fine, I think is ok if the notification just disappears on his own (after a few seconds anyway). And if you click on it it will disappear anyway.

On the other hand, you need to also include the downside of the current notification system. For example ignoring completely the fact that some app may be fullscreen, and the notifications that never disappear is quite annoying. I attached a screenshot of the problem in #2380

In the end, the two different notifications have advantages and disadvantages, in my opinion there should be an option for the users to choose.

Another problem that the the current notification method has is that is probably not wayland-ready at all.

[john-preston]

I hope (3) is Unity problem as well, because libnotify does have the method to close the shown notifications - it simply doesn't work, at least in Unity.

Current notifications are plain-Qt, what of them is more "not wayland ready" than tdesktop itself..

[john-preston]

I think the timers of non-native notifications will be improved. But you always can hide them by right click.

[l4rzy]

the problem (3), is a notify server (daemon) problem, not libnotify itself. For example, dunst notification daemon works ok with (3)
I think instead of using libnotify inside the codebase, why not simply using notify-send with template, and make it optional, for example:
notify-send %sender %time
P.s: of course it's some kind of trick and cause binary call overhead, but it's a good way to achive this without complexity.

[john-preston]

@h4y44 Using libnotify is easy enough. The problem is what implementation of notifications the end user gets.

[AndydeCleyre]

The problem is what implementation of notifications the end user gets.

In the Linux desktop world, as long as you're using an open standard like libnotify, that's not _your_ problem as an app developer. That's on the user, their distro, and their desktop environment.

[timokau]

I agree that it should just be an option, since the current notifications have to be kept around for windows anyway.
Maybe make libnotify opt-in if the unity experience really is as bad as you describe.
For me (using dunst for notifications):

• Notifications appear exactly as long as I want, I can close them one at a time or all at once by clicking on them or with a keyboard shortcut
• I can customize how they look
• If telegram gives me 1000 notifications they would be shown all at once (not queued up like it seems to be on unity) and can be closed immediately
• I'm sure interacting with the notification is possible, but not nessessary for me

[bilelmoussaoui]

@john-preston The notification on Gnome desktop works quite well, i have worked with libnotify using GJS and you can override the latest notification sent using libnotify, you can also add action buttons (like open message or mark as read); you can also hide the notification!
What is really important for me as a user is the possibilty to enable/disable notification globaly on my system settings (don't distrub mode) and this work for all the applications (Telegram included in the future).

[Tids]

@Eisfreak7 Opt-out would be better since unity is only one desktop on one distro. it really would be a pita if this one will lead an improvement on every other desktop to be only a option to enable

[EvelynSubarrow]

The problem is what implementation of notifications the end user gets.

Telegram's current notifications guarantee users a less-than-optimal experience. With libnotify, it's only a possibility.

[TheLastProject]

@john-preston On OS X and Windows 10 you just show a native notification and let the OS control it, right? Just do the same for Linux: Use libnotify to create native notifications and let the system decide what to do.

Currently the notifications obscure the input field and show even when the screen is locked, which is the main reason I'm considering switching to Cutegram because they claim to do native notifications.

If you really feel bad about native notifications despite there really being no need to because people use a desktop environment because they like it this way, just add a setting: "Use native notifications". Please do enable native notifications by default though, the native notifications are always designed as they are for a reason.

[WhyNotHugo]

@john-preston

you can't close a notification in any way, just wait for it to disappear.

This depends on each implementation. I use dunst, where I can close them with alt+space. Each distro/desktop has something different.
Keep in mind that in my view, it's the opposite; I can't close telegram notifications without a mouse.

you can't handle any event like click or whatever so that the conversation will get opened where the new message arrived.

Again, depends on the server implementation, as said above. Some allow clicks, other allow global hotkeys as interactions, other allow nothing (a stupid choice IMHO, but if users want that, who am I to complain).

you can't programmatically close a shown notification (notify_notification_close() simply doesn't work).

This should work. Additionally, existing notifications can be modified to show different text (some few clients do this). Other may group notifications with a same title and append the new text into the existing one.

[john-preston]

@hobarrera I was talking about one implementation, Ubuntu has a lot of users, I can't make their life so awful. But I understand that the support should be added in some way.

[WhyNotHugo]

I was talking about one implementation, Ubuntu has a lot of users, I can't make their life so awful. But I understand that the support should be added in some way.

I understand your point, but I guess I wasn't as clear with mine. The truth is, Ubuntu users already deal with those issues with every single other app, and it would seem to be their preference - even if you and I may disagree. Meanwhile, non-ubuntu users (or users which have reconfigured Ubuntu), can reap the strengths of whatever notifications deamon they pick. 😄

[Tids]

On messaging spam you can just disable notifications for this chat? like i do for every group anyways?!

but @john-preston maybe group up messages? Let's say there is messaging spam, like more than one message in 1 secound. So group them up for 3 Secounds and only show "$n new messages". $XDG_SESSION_DESKTOP == unity (or whatever unity will show up as). Since you can not click on them anyways there is no need to show all messages as single notification.

for all other desktops you should show single messages and a "open telegram-chat" button.

[timokau]

If I understand the problem correctly its not the spam itself, but that for example ubuntu by default will show you every message at once with a x second delay in between. So if you get spammed, you will be able to enjoy it for the next hour even if you immediately disable notifications.
I wouldn't start adding additional complexity by grouping messages or specialising based on the implementation of libnotify (I'm not sure if that can be reliably detected anyway).

[john-preston]

@Eisfreak7 I won't show the next notification while one is shown in Unity. That way you'll wait only for one.

[tecywiz121]

@john-preston Please don't give up on libnotify because you don't enjoy the Ubuntu notification paradigm. I'm a long time Ubuntu user and I do like the non-interactive bubbles. If I didn't, I could change it.

There's this document that somewhat describes the rules NotifyOSD uses, including the spam prevention and merging rules. Don't know how accurate or old it is though.

[cauebs]

@tecywiz121 I really disagree on some of the design choices, especially:

Other than that hover effect, bubbles should not directly respond to input devices in any way.

Edit: People manifested their opinions about this here

[tecywiz121]

@cauebs It _is_ a very contentious decision. Regardless, my point was that I'd rather have the choice to use the style of notifications I enjoy rather than be forced to use a style I don't. If tdesktop uses the standard libnotify system, the end user has the power to do what they want, be it sticking with NotifyOSD or something else, like dunst.

[cauebs]

@tecywiz121 I'd love to have it working with dunst but, seeing how much trouble some people are having with the implementation, I just wish we could have some very simple settings for the qt notifications, such as duration and position.

[mrshadowtux]

Yes, exactly that is the point! libnotify gives the user the flexibility
to choose freely which type of notifications he wants, all in a unified
look.

Greetings from another dunst user

Am 04.10.2016 um 21:21 schrieb tecywiz121:

@cauebs https://github.com/cauebs It /is/ a very contentious
decision. Regardless, my point was that I'd rather have the choice to
use the style of notifications I enjoy rather than be forced to use a
style I don't. If tdesktop uses the standard libnotify system, the end
user has the power to do what they want, be it sticking with NotifyOSD
or something else, like dunst.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/91#issuecomment-251486170,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGIVcAeQLdqiufCqJgsh_zzp_fIKGvG1ks5qwqcfgaJpZM4CTQw-.

[Tids]

i wonder - is it possible to create buttons/actions on/for notifications made by libnotify? because with "notify-send" it seems to be not possible.

[AndydeCleyre]

@Tids yes, it is.

From the docs:

notify_notification_add_action ()

Adds an action to a notification. When the action is invoked, the specified callback function will be called, along with the value passed to user_data.

[john-preston]

@AndydeCleyre but it works very unpredictable (stopped calling the callback function when two and more notifications were combined to one by the notification server in one tested case, produced a message box fallback in notify osd -- I hope only there).

@all You can test a libnotify implementation in the latest 0.10.12 alpha version available from the bottom of https://desktop.telegram.org/#alpha-version page, you need to switch it on in Settings.

[mrshadowtux]

Hi,

@all https://github.com/all You can test a libnotify implementation
in the latest 0.10.12 alpha version available from the bottom of
https://desktop.telegram.org/#alpha-version page, you need to switch
it on in Settings.

Wow, that's awesome! Thank you very much!

[vmorenomarin]

Thanks for listen. Now we have native notifications on Linux :)

[AndydeCleyre]

@john-preston It's working beautifully with the reply button, chat avatar, title, sender, and content. Thank you very much! I'm testing on plasma 5.8, which is reasonable enough to let you close notifications whenever you want.

[psamim]

Thanks! I can confirm that finally notifications work and look native and nice. I use XFCE desktop environment.

I am on Archlinux and installed v0.10.13 by changing pkgver to 0.10.13.alpha and setting its sha256sum to SKIP in the PKGBUILD using https://aur.archlinux.org/packages/telegram-desktop-bin/.

If anyone wonders, https://github.com/telegramdesktop/tdesktop/commit/c9288f2d0ad2f5f3d017faf2f30642eb668f7aff enabled native notifications.

I think this issue can finally be closed. :)

[Algram]

I can't seem to find the option in the latest alpha. Can you help me out?

[PandorasFox]

Thank you for implementing this! There's a new bug in the QT notifications now, though, for dual-monitor users.

@Algram:

[john-preston]

@Algram If you don't see "Use native notifications" checkbox in Settings first section, can you provide your ~/.TelegramDesktop/log.txt to see if there is information about the problem with libnotify?

[Algram]

@john-preston This is all I got in the log_start0.txt

[2016.10.07 21:51:39] Launched version: 10013, alpha: [TRUE], beta: 0, debug mode: [FALSE], test dc: [FALSE]
[2016.10.07 21:51:39] Executable dir: , name: 
[2016.10.07 21:51:39] Initial working dir: /home/algram/
[2016.10.07 21:51:39] Working dir: /home/algram/.TelegramDesktop/
[2016.10.07 21:51:39] Arguments: "telegram-desktop"
[2016.10.07 21:51:39] Logs started
[2016.10.07 21:51:39] Connecting local socket to /tmp/079a6e60a3d46767f46af0a58c9b489d-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2016.10.07 21:51:39] Socket connected, this is not the first application instance, sending show command...
[2016.10.07 21:51:39] Show command written, waiting response...
[2016.10.07 21:51:39] Show command response received, pid = 9071, activating and quitting...

EDIT:
Seems like I found something

[2016.10.08 00:02:36] Launched version: 10013, alpha: [TRUE], beta: 0, debug mode: [FALSE], test dc: [FALSE]
[2016.10.08 00:02:36] Executable dir: , name: 
[2016.10.08 00:02:36] Initial working dir: /home/algram/
[2016.10.08 00:02:36] Working dir: /home/algram/.TelegramDesktop/
[2016.10.08 00:02:36] Arguments: "telegram-desktop"
[2016.10.08 00:02:36] Logs started
[2016.10.08 00:02:37] Connecting local socket to /tmp/079a6e60a3d46767f46af0a58c9b489d-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2016.10.08 00:02:37] This is the only instance of Telegram, starting server and app...
[2016.10.08 00:02:37] Moved logging from '/home/algram/.TelegramDesktop/log_start4.txt' to '/home/algram/.TelegramDesktop/log.txt'!
[2016.10.08 00:02:37] Old start log 'log_start0.txt' found, deleted: [TRUE]
[2016.10.08 00:02:37] Old start log 'log_start1.txt' found, deleted: [TRUE]
[2016.10.08 00:02:37] Old start log 'log_start2.txt' found, deleted: [TRUE]
[2016.10.08 00:02:37] Old start log 'log_start3.txt' found, deleted: [TRUE]
[2016.10.08 00:02:44] Could not load 'appindicator3' with version 1 :(
[2016.10.08 00:02:44] App Info: reading settings...
[2016.10.08 00:02:44] App Info: reading encrypted settings...
[2016.10.08 00:02:44] LibNotify Error: could not get capabilities!
[2016.10.08 00:02:44] LibNotify Error: could not get server name!
[2016.10.08 00:02:44] LibNotify Error: manager failed to init!
[2016.10.08 00:02:44] Not using Unity Launcher count.
[2016.10.08 00:08:15] Message Info: bad message notification received (error_code 16) for msg_id = 6338815820873045992, seq_no = 63

[john-preston]

@Algram Well, I'm loading libnotify, but it doesn't exec commands any good way :( no server name, no capabilities, I don't dare to start without anything.

[AndydeCleyre]

I do notice that if someone sends a message, and I go read it, then say 10 minutes later they send another, the new notification starts with previous message content from the sender and eventually includes the new stuff. That's not really problematic, but it would be easier to read if it started with only unread messages, rather than including messages that have already been read.

[john-preston]

@AndydeCleyre Well, I just send notifications to libnotify, I call notify_notification_close() once the messages are read. I don't know how it decides to merge them :( But since that update the code is pretty clean on the notifications side (at least comparing to what it was before), so perhaps some libnotify jedi will make a fixing pullrequest some day.

[Tids]

Aww thanks for this! Looks like it works really nice :D

Finally i can play rocket league without micro lag because of telegram notifications <3

btw on spam this happens with KDE Plasma 5.8:

a not to bad situation and still a big improvement compared to the telegram notifications

[john-preston]

Well, now Telegram notifications can too be only one on screen + real quick reply, not just opening the conversation :)

[maximbaz]

For the dunst fans: the profile picture won't show up because this feature is not a part of the dunst codebase. There is a github issue for this https://github.com/knopwob/dunst/issues/151, but the support for raw images is actually already implemented in this fork: https://github.com/buglloc/dunst. I've tried it out, everything seems to work just fine.

[lindhe]

@Algram Well I guess we lured them out. ;) Let's close our fork, pretend like it never happened...

[cauebs]

On dunst it is not merging notifications. Do you guys know another lightweight and customizable daemon like it? Or can it be fixed by replacing notifications with same id (and appending new messages to the body)?

[stek29]

Isn't it implemented in last versions?

[fbt]

Just wanted to say thanks for implementing this. So much nicer to use the desktop app now :)

[Niklan]

I don't know but in KDE Neon this feature works only after release, after next update it missing.

there is no 'Use native notifications' checkbox anymore.

UPD

Haha. I wanted to upload version info, but there is little message 'Restart to new version', a press it, and this checkbox is now again available.

UPD

And, after logout the setting is missing again.

[Tids]

@Niklan telegram will not detect libnotify support as long as Plasma is not loaded. So dont set telegram to autostart or autostart it with

sleep 10
telegram

when telegram is started before plasma, it will use its own notification system

@john-preston should we report a bug for this?

[john-preston]

@Tids And how can I detect the native notifications system if I can't load the library when the app starts?

[Tids]

@john-preston I dont know. Thats why i ask if it would be an idea to open a bugreport (on the kde bugtracker) for this. Or is it a general issue on "all desktops"?

[Niklan]

@Tids thank you, solved my problem.

[jmaris]

no quick replies on gnome yet though :(

[WhyNotHugo]

no quick replies on gnome yet though :(

What do you mean? Are you sure this is the right thread?

[solbjorn]

@hobarrera, yup. He means lack of support of such replay field right in the notification box:

Not sure if it's really such needed and useful though.

[jmaris]

@solbjorn considering the default notifications can do it; it would be a nice feature to have for native notifications

[WhyNotHugo]

As far as I know, the XDG notification spec doesn't support this sort of thing, so it's probably not possible.

If you want these custom integrations, just use the builtin notifications.

[ulgrimar]

I would also like to see telegram notifications directly in gnome 3.x

[keeferrourke]

on the latest Fedora 26, with telegram installed as a Flatpak (with the GNOME runtimes), libnotify support still isn't detected properly. When I first started Telegram, there were two available options which no longer exist (1) use native notifications (2) night mode (????).

Is there a fix for native notifications with telegram as a flatpak? For the life of me, I cannot get the setting to show again.

[bilelmoussaoui]

@keeferrourke you should report that to the flatpak packager.

[ayekat]

https://github.com/telegramdesktop/tdesktop/blob/55e56a6788870e6d67d9938eaabdf87f2ebddb17/Telegram/SourceFiles/platform/linux/linux_libs.cpp#L302-L305

Looking at that code snippet, it appears that libnotify usage requires GTK+. Is this intentional? The Arch Linux packager recently removed the libappindicator-gtk3 dependency, and added the TDESKTOP_DISABLE_GTK_INTEGRATION option to the list of GYP options for some unknown reason.

I was about to complain downstream, but then I concluded that using libnotify shouldn't really depend on GTK+ to start with, so I'm asking here instead.

[d0tfile]

@ayekat There is a comment in commit, maybe you missed it: "Reduce dependencies to turn this package into a pure Qt5 application". Maybe we should ask it on Arch Linux forum. I find native notifications useful, so subbing for any updates.

[ayekat]

@ayekat There is a comment in commit, maybe you missed it: "Reduce dependencies to turn this package into a pure Qt5 application".

Yes, except that I just compiled telegram-desktop without that option (but still removed the libappindicator-gtk3 dependency), and Telegram Desktop works fine that way. So this can't really be a reason (or I have a really odd case on my machine).

Maybe we should ask it on Arch Linux forum.

Yup, I will ask there. --edit Openend here.

But this still doesn't really explain why there is a need for something called "GTK integration" (I'm not familiar enough with the code to know what this actually means) for libnotify support (which I believe should be independent of GTK+).