The recent notify issue discussion prompts me to ask:
Is there a notify HOWTO anywhere for me to learn about how to implement notify?
I have a few long-running, in the background bash scripts where notify would be a nice touch to implement.
As was mentioned, passing "notify" to a search engine -- even with other search terms -- is of little use.
Inquiring minds...
Thank you! Jonesy
On Wednesday 01 March 2023 04:35:11 pm Marvin Jones via tde-users wrote:
The recent notify issue discussion prompts me to ask:
Is there a notify HOWTO anywhere for me to learn about how to implement notify?
I have a few long-running, in the background bash scripts where notify would be a nice touch to implement.
Hi Jonesy,
There's probably a few dozen ways to do a notification. You saw Darrell’s in the prior thread. This is how I’ve done it from cron for a long time. I won’t say it’s pretty, it’s just the first thing I got working ;)
# # # In attachment # # #
HTH, Michael
PS: I believe zenity worked a long time ago and I just replaced it with yad after it broke?
Michael via tde-users wrote:
On Wednesday 01 March 2023 04:35:11 pm Marvin Jones via tde-users wrote:
The recent notify issue discussion prompts me to ask:
Is there a notify HOWTO anywhere for me to learn about how to implement notify?
I have a few long-running, in the background bash scripts where notify would be a nice touch to implement.
Hi Jonesy,
There's probably a few dozen ways to do a notification. You saw Darrell’s in the prior thread. This is how I’ve done it from cron for a long time. I won’t say it’s pretty, it’s just the first thing I got working ;)
dcop knotify reports following for Notify object
$ dcop knotify Notify QCStringList interfaces() QCStringList functions() void notify(TQString event,TQString fromApp,TQString text,TQString sound,TQString file,int present,int level) void notify(TQString event,TQString fromApp,TQString text,TQString sound,TQString file,int present,int level,int winId) void notify(TQString event,TQString fromApp,TQString text,TQString sound,TQString file,int present,int level,int winId,int eventId) void reconfigure() void setVolume(int volume) void sessionReady()
Try this (it calls the function notify with 7 args)
$ dcop knotify Notify notify "Test" "" "Test" "" "" 2 1
it will produce a notification message "Test" in a dialog, that does not close (the desktop session is required of course)
On Wednesday 01 March 2023 04:35:11 pm Marvin Jones via tde-users wrote:
The recent notify issue discussion prompts me to ask:
Is there a notify HOWTO anywhere for me to learn about how to implement notify?
I have a few long-running, in the background bash scripts where notify would be a nice touch to implement.
[I have a Black Belt in Procrastination, ans it's only getting worse.]
Thanks to all who replied on my query about a `notify` facility.
Actually, I have been using zenity and kdialog in my scripts to create pop-ups for some time now. I just did not know that was considered a `notify`. What I would like to explore is a "notify" feature as I experience with chromium/chrome. I use Groupware (in chromium) at my ISP to monitor my imap account, before I further shunt spam aside an download the "good stuff" to my VPS.
As email comes in, Groupware (in the browser) is able to notify, in the lower right corner of _all_ my 6 screens, about the arrival of new mail. [See attached image.] After about 20 seconds they close.
This notify facility is something that I had _NO_ involvement with in getting set up. This has got to be something native in the OS -- and not a TDE "thing". Yet it's seems to be "standard" enough that TDE can effect the display of those new mail messages.
After some long (very long) (there's that "procrastination thing") puzzlement on what I was seeing, I decide to inquire about it.
Thanks for the feedback. Jonesy
Marvin Jones via tde-users wrote:
This notify facility is something that I had _NO_ involvement with in getting set up. This has got to be something native in the OS -- and not a TDE "thing". Yet it's seems to be "standard" enough that TDE can effect the display of those new mail messages.
After some long (very long) (there's that "procrastination thing") puzzlement on what I was seeing, I decide to inquire about it.
To understand this, you have to read about DBus notifications https://specifications.freedesktop.org/notification-spec/notification-spec-l...
This is basically the successor of the dcop notify functionality.
The idea is that you let application listen to specific events on the bus and act on them. TDE has virtually nothing to do with them. It is actually the applications you are using that are handling and popping up those messages.
Marvin Jones via tde-users wrote:
This notify facility is something that I had _NO_ involvement with in getting set up. This has got to be something native in the OS -- and not a TDE "thing". Yet it's seems to be "standard" enough that TDE can effect the display of those new mail messages.
I forgot to mention that there is a dbus notifications daemon in TDE (and this is how I learned all about this). This daemon can be used to display notifications, but I have not seen any usage of it (except in such cases like yours, where you send message from command line or so). I found out that each application handles the messages itself (it is addressed on dbus). It could be I am wrong and if someone knows better, please, let us know.
On 3/14/23 5:11 AM, deloptes via tde-users wrote:
This notify facility is something that I had _NO_ involvement with in getting set up. This has got to be something native in the OS -- and not a TDE "thing". Yet it's seems to be "standard" enough that TDE can effect the display of those new mail messages.
I forgot to mention that there is a dbus notifications daemon in TDE (and this is how I learned all about this). This daemon can be used to display notifications, but I have not seen any usage of it (except in such cases like yours, where you send message from command line or so). I found out that each application handles the messages itself (it is addressed on dbus). It could be I am wrong and if someone knows better, please, let us know.
I tried using the kdbusnotifcation package. My original post was about notify-send expiration times that are not being honored. So dbus notifications do work in TDE but not in full conformance.
Anybody using free/libre software is aware of the break neck speed at which software evolves and matures. A dozen years is a "lifetime" in that respect. Many of the changes have much to do with modern standards. Much software in TDE is from an era when there were few standards. TDE remains entrenched in those old ways. The rest of the world has moved on to support those standards. For example, despite claims on the TDE web site, TDE is not XDG compliant.
Not to despair because dbus notification is broken in KDE too (https://bugs.kde.org/show_bug.cgi?id=381693). In KDE the notification design remains rooted in a presumption that KDE is the only DE installed. With a shared heritage TDE design suffers from this same foundation.
TDE is similar and does not coexist well with other DEs. The GTK theming engines are examples. That TDE remains relegated to living in /opt purgatory will always cause issues that the other DEs do not have, especially with environment variables. Many TDE users are unlikely to notice these issues because TDE is the only DE installed and the only one they use. Many TDE users likely have grown accustomed to various warts and blemishes.
My grand curse seems to be having worked as a technical writer for many years and having a trained eye and mind to see both the "trees and forest." I tend to break software more easily than most folks and tend to discover usability issues faster than many people. I also have been using computers for more than 40 years and have a different usage perspective than most of the modern smartphone generation of computer users.
I do not have any slick answers or solutions.
DA
Darrell Anderson via tde-users wrote:
I tried using the kdbusnotifcation package. My original post was about notify-send expiration times that are not being honored. So dbus notifications do work in TDE but not in full conformance.
I am interested to know as notify-send uses dbus, concluding from your statement above, you have tried to use kdbusnotifcation which is actually using notification-daemon-tde. Is this correct?
If so, I've been looking into DBus in TDE in the past few years and we did many improvements, some of which can be seen in 14.1. I am even testing a fully DBus notifications complient client for the past year or so, but as mentioned before, I could not identify any use case. When I was monitoring DBus I found out that Skype/Firefox and other applications do listen and handle notifications themselves. If you want to try this https://mirror.git.trinitydesktop.org/gitea/TDE/kdbusnotification/src/branch...
I am sure if you try this, you will be satisfied. If you need a debian package for testing, let me know.
On top there is not enough man power and priority to work more intensively, but Michele mentioned he is willing to backport some part of the Qt4 DBus code. IIRC it was few weeks ago. This is very good idea. At the moment it is much more work to create TDE DBus capable application, even with the improvements and bug fixing we did to dbus-1-tqt. You can see the PoC here https://mirror.git.trinitydesktop.org/gitea/deloptes/dbus-1-tqt-example This is the closest we could get. In Qt4 and later there is a way to access all the bells and wistles by just providing the xml introspection file. But as TDE is using dcop, all this DBus stuff is not being used that much in TDE. In the cases it is used ... it is not that good, I must agree. This is why I spent some time in the past 4 years learning more about DBus and doing some work. It is not without selfish interest ... you see I simply want to sync my phone contacts and calendar with the desktop as I was able to do it in 2004 with the Palm III. You will ask perhaps what it has to do with DBus ... well this is the bluetooth part that brought me to DBus and a kdebluez application that SuSE released just before KDE moved to Qt4. Since bluez5 is using dbus, I started looking for a way, how I can have all working as it should. Remember I am not focused on new applications but on working use cases. I hope I will be lucky to enjoy it working for couple more years, before some new "modern standard" tries to break things again. It happens about every 10y.
Anybody using free/libre software is aware of the break neck speed at which software evolves and matures. A dozen years is a "lifetime" in that respect. Many of the changes have much to do with modern standards. Much software in TDE is from an era when there were few standards. TDE remains entrenched in those old ways. The rest of the world has moved on to support those standards. For example, despite claims on the TDE web site, TDE is not XDG compliant.
Well, if those "modern standards" were that good and everything was playing along, I guess we won't be using TDE. I myself am not a person that sticks to old things, because I am afraid of changing world. Unfortunately the changing world and the new standards brought a lot of new stuff that never works. So it is a consious trade off.
And again I saw how during the years much more people joined the community and are helping improve TDE.
I think your words are heard and this or that will be solved in the future. The problem is the man power as it is volunteer work. It is even amazing how people are motivated to do so many work aside normal life.
Not to despair because dbus notification is broken in KDE too (https://bugs.kde.org/show_bug.cgi?id=381693). In KDE the notification design remains rooted in a presumption that KDE is the only DE installed. With a shared heritage TDE design suffers from this same foundation.
TDE is similar and does not coexist well with other DEs. The GTK theming engines are examples. That TDE remains relegated to living in /opt purgatory will always cause issues that the other DEs do not have, especially with environment variables. Many TDE users are unlikely to notice these issues because TDE is the only DE installed and the only one they use. Many TDE users likely have grown accustomed to various warts and blemishes.
Perhaps you should write bug reports and also I am not sure if it is TDE or a general DE issue. I am unaware of a reason, why I would even try putting any other desktop on the daily driver. For testing purposes I use VM or USB images. My last experience with Gnome was horrible, KDE looked nice, but now and then things stop working. All other desktops are rubbish for daily use.
I now searched for linux desktops and got 18. See there is TDE too:
K Desktop Environment 3 is the third series of releases of the K Desktop Environment. There are six major releases in this series. After the release of KDE 4, version 3.5 was forked into the Trinity Desktop Environment. Wikipedia
My grand curse seems to be having worked as a technical writer for many years and having a trained eye and mind to see both the "trees and forest." I tend to break software more easily than most folks and tend to discover usability issues faster than many people. I also have been using computers for more than 40 years and have a different usage perspective than most of the modern smartphone generation of computer users.
You are the perfect tester! (jokingly)
I do not have any slick answers or solutions.
sharing ideas is good enough
BR
On 3/14/23 4:29 PM, deloptes via tde-users wrote:
If so, I've been looking into DBus in TDE in the past few years and we did many improvements, some of which can be seen in 14.1.
When 14.1 is released I will test.
Perhaps you should write bug reports and also I am not sure if it is TDE or a general DE issue.
My list of bugs is quite long. Would take me several days to file all of them. Many of the bugs are from the old bugzilla, some of which have been open for a dozen years.
You are the perfect tester! (jokingly)
Not really -- I tend to drive engineers and developers up the wall. :)
On 3/1/23 4:35 PM, Marvin Jones via tde-users wrote:
Is there a notify HOWTO anywhere for me to learn about how to implement notify?
I have a few long-running, in the background bash scripts where notify would be a nice touch to implement.
As was mentioned, passing "notify" to a search engine -- even with other search terms -- is of little use.
Hi Jonesy,
All I have used through the past many years is the notify-send command that is part of the libnotify package.
All I do is write shell scripts or one-liners for cron. Because cron never has a full environment, the DISPLAY environment variable needs to be defined for notify-send to function outside the environment.
To get an idea how this functions, ensure the libnotify package is installed. Send the following command:
notify-send --expire-time=5000 "Test" "This is a message test."
The message popup will remain open for 5 seconds.
The kdbusnotification package is broken, but any notification daemon from other desktop environments will suffice.
In your use case, at the end of the long running script add something like this:
if [ "$DISPLAY" = "" ]; then DISPLAY=:0 fi
DISPLAY=$DISPLAY notify-send --expire-time=$TIMEOUT "$SUBJECT" "$MSG"
I hope that helps.
DA
-
Darrell Anderson -
deloptes -
Marvin Jones -
Michael