1 Mar
2023
1 Mar
'23
10:35 p.m.
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
--
Marvin L Jones | Marvin | W3DHJ | linux
Pueblo, Colorado | @ | Jonesy | FreeBSD __
38.238N 104.547W | jonz.net | DM78rf | SK
2 Mar
2 Mar
12:18 a.m.
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?
3 Mar
3 Mar
3:37 p.m.
Michael via tde-users wrote:
On Wednesday 01 March 2023 04:35:11 pm Marvin Jones
via tde-users wrote:
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)
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 ;)
13 Mar
13 Mar
10:54 p.m.
> 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 L Jones | Marvin | W3DHJ | linux
Pueblo, Colorado | @ | Jonesy | FreeBSD __
38.238N 104.547W | jonz.net | DM78rf | SK
14 Mar
14 Mar
6:47 a.m.
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-…
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.
10:11 a.m.
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.
6:31 p.m.
On 3/14/23 5:11 AM, deloptes 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.
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
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.
9:29 p.m.
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/branc…
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
15 Mar
15 Mar
2 a.m.
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. :)
2 Mar
2 Mar
4:44 a.m.
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
647
days inactive
661
days old
10 comments
4 participants
participants (4)
-
Darrell Anderson -
deloptes -
Marvin Jones -
Michael