Re: desktop notifications (Re: idea for capture anywhere in x)

[Ihor Radchenko]

Samuel Wales  writes:

> perhaps some fuction in org-capture-before-finalize-hook could raise
> emacs for a tiny period of time or something, in the case that it is
> invoked when emacs is not visible. if so, and idk if poss, i would
> have to try it to find out if it wfm.
>
> then i wouldn't hafe to keep trying notification tools ad try to get
> them to have sufficient fonts colors sizes etc. and work.  :)

I use the following code to raise helm frames:

*** Run/search menu via Emacs helm
 #launcher #runner
Inspired by [[id:Mattduckemacs_as_fuzzy_launc_and_alfred_replac6c6][[Mattduck] 
Emacs as a fuzzy launcher and Alfred-replacement]]
#+begin_src bash :tangle ~/.local/bin/emacs-helm-menu :shebang #!/bin/bash
if [[ "$(getactvwindclass)" == "emacs.Emacs" ]]; then
# Relies on my key bindings
xdotool key --clearmodifiers --delay 60 alt+l e h;
# release any pressed modifiers
xdotool keyup super alt ctrl shift
else
emacsclient -c --frame-parameters="((title . \"Helm frame\") (unsplittable 
. t))" -e "(let ((inhibit-message t) (helm-full-frame t) 
(helm-use-undecorated-frame-option nil)) (catch :quit 
(yant/helm-org-ql-agenda-files nil) (when (= 0 helm-exit-status) (let ((fr 
(selected-frame))) (make-frame) (delete-frame fr))) (unless (= 0 
helm-exit-status) (user-error \"%s\" \"Exit frame\"";
fi
#+end_src

You may be interesteed in the --frame-parameters argument to
emacsclient. Similar alist can be passed to `make-frame' from Elisp.
You can refer to 30.4.3 Window Frame Parameters section of Elisp manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: desktop notifications (Re: idea for capture anywhere in x)

[Samuel Wales]

i am lost in a sea of partial solutions and hints that myb rain cannot
process at this time, despite their straightforwardness.  i do like
the idea of having confidence that a capture worked thgouh very much.

perhaps some fuction in org-capture-before-finalize-hook could raise
emacs for a tiny period of time or something, in the case that it is
invoked when emacs is not visible. if so, and idk if poss, i would
have to try it to find out if it wfm.

then i wouldn't hafe to keep trying notification tools ad try to get
them to have sufficient fonts colors sizes etc. and work.  :)

On 10/29/22, Max Nikulin  wrote:
> On 29/10/2022 11:59, Ihor Radchenko wrote:
>>
>> Functions in org-capture-before-finalize-hook have access to the
>> contents of the capture buffer text. So, one can call `start-process' to
>> run notify-send shell command and put the actual captured text into the
>> notification (displayed briefly or for longer time according to the
>> switches passed to notify-send).
>
> I like this idea. Reading your message from Sat, 29 Oct 2022 02:59:51
> + I decided that for yourself you set up an Emacs frame as a pop-up
> to display capture result. However I believe it is better to use either
> org-clock or Emacs notify functions directly instead of notify-send tool.
>
> Samuel, I suggested notify-send tool as a means to debug notifications
> in isolation (without `org-capture'). Have you managed to configure
> notification-daemon, dunst or some other alternative to get acceptable
> appearance and proper timeout before notification disappears.
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

desktop notifications (Re: idea for capture anywhere in x)

[Max Nikulin]

On 29/10/2022 11:59, Ihor Radchenko wrote:


Functions in org-capture-before-finalize-hook have access to the
contents of the capture buffer text. So, one can call `start-process' to
run notify-send shell command and put the actual captured text into the
notification (displayed briefly or for longer time according to the
switches passed to notify-send).


I like this idea. Reading your message from Sat, 29 Oct 2022 02:59:51 
+ I decided that for yourself you set up an Emacs frame as a pop-up 
to display capture result. However I believe it is better to use either 
org-clock or Emacs notify functions directly instead of notify-send tool.


Samuel, I suggested notify-send tool as a means to debug notifications 
in isolation (without `org-capture'). Have you managed to configure 
notification-daemon, dunst or some other alternative to get acceptable 
appearance and proper timeout before notification disappears.

Re: desktop notifications (Re: idea for capture anywhere in x)

[Max Nikulin]

On 26/10/2022 15:07, Samuel Wales wrote:


can dunst go away after a short period?


I have never tried it. Unsure if it has enough configuration options.

Does it mean that you get notification displayed? Have you tried?

notify-send --expire-time 2000 ...


i launch dbus manually as fluxbox is not a dm
eval $(dbus-launch --sh-syntax --exit-with-session)


I believe, notification daemon should be running is addition to d-bus 
daemon. Notification daemon just register an additional interfaces on 
d-bus and responsible for notification windows.



unfamiliar with notifications.el. if recommended i can look into it.


I am unsure what is more convenient in your case to avoid shell 
commands, org-notify from org-clock.el or functions from notifications.el

Re: desktop notifications (Re: idea for capture anywhere in x)

[Samuel Wales]

i called notify-send from the cli in emacs shell mode running bash,
with emacs maximized as most of my apps are.

in fluxbox terminology at least, maximized means takes up the whole
screen.  fullscreen would mean occupies the top.

no text result and no gui result from notify-send.

can dunst go away after a short period?

i launch dbus manually as fluxbox is not a dm
eval $(dbus-launch --sh-syntax --exit-with-session)

for context, with org-capture firefox says captured briefly but that
is no guarantee back from emacs which is why we are seeking
confirmation; i used to think it meant that it was captured but when
broken it id not capture.

unfamiliar with notifications.el. if recommended i can look into it.
plauing a sound would irritate me.

On 10/26/22, Max Nikulin  wrote:
> On 26/10/2022 13:22, Samuel Wales wrote:
>> i have the daemon and the binary but notify-send "summary" "text"
>> seems to do nothing obvious.  called from shell mode.  my emacs is
>> maximized.  so is firefox.
>
> Does notify-send complain (with some delay) concerning timeout during
> attempt to connect to d-bus?
>
> I have found an Eric's message recommending dunst as a notification
> daemon for fluxbox.
>
> Firefox has a fallback implementation to display notifications in the
> case of d-bus failure, so it is not the best app to test their appearance.
>
> Fluxbox released versions (e.g. from Debian and Ubuntu packages) has a
> bug that may cause some applications, in particular Firefox, to be
> displayed above other windows. So it may hide a notification window.
> However if you have a terminal application in front of you, it should
> not be your case.
>
> I am unsure if functions from notifications.el are better than
> notify-send in respect to error reporting.
>
> Have you considered playing a tune as a notification?
>
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: desktop notifications (Re: idea for capture anywhere in x)

[Max Nikulin]

On 26/10/2022 13:22, Samuel Wales wrote:

i have the daemon and the binary but notify-send "summary" "text"
seems to do nothing obvious.  called from shell mode.  my emacs is
maximized.  so is firefox.


Does notify-send complain (with some delay) concerning timeout during 
attempt to connect to d-bus?


I have found an Eric's message recommending dunst as a notification 
daemon for fluxbox.


Firefox has a fallback implementation to display notifications in the 
case of d-bus failure, so it is not the best app to test their appearance.


Fluxbox released versions (e.g. from Debian and Ubuntu packages) has a 
bug that may cause some applications, in particular Firefox, to be 
displayed above other windows. So it may hide a notification window. 
However if you have a terminal application in front of you, it should 
not be your case.


I am unsure if functions from notifications.el are better than 
notify-send in respect to error reporting.


Have you considered playing a tune as a notification?

Re: desktop notifications (Re: idea for capture anywhere in x)

[Samuel Wales]

i have the daemon and the binary but notify-send "summary" "text"
seems to do nothing obvious.  called from shell mode.  my emacs is
maximized.  so is firefox.

On 10/25/22, Max Nikulin  wrote:
> On 26/10/2022 12:05, Samuel Wales wrote:
>>
>>> You may hook notifications-notify to org-capture-after-finalize-hook to
>>> see notification when the capture is successful.
>>
>> sounds like it
>> could be reassuring if it is not obtrusive.
>
> Try the following command to get impression
>
>  notify-send "summary" "text"
>
> Since you are using fluxbox, likely you need to add some daemon to
> autostart (unless the package has an /etc/xdg/autostart entry active for
> fluxbox)
>
>  apt-cache search notification-daemon
>
> As a KDE user I can not suggest particular one. Perhaps
> notification-daemon package is enough.
>
> It is better to protect "&<>" characters as HTML entities "" etc.
> since the spec allows some basic formatting and active links.
>
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

desktop notifications (Re: idea for capture anywhere in x)

[Max Nikulin]

On 26/10/2022 12:05, Samuel Wales wrote:



You may hook notifications-notify to org-capture-after-finalize-hook to
see notification when the capture is successful.


sounds like it
could be reassuring if it is not obtrusive.


Try the following command to get impression

notify-send "summary" "text"

Since you are using fluxbox, likely you need to add some daemon to 
autostart (unless the package has an /etc/xdg/autostart entry active for 
fluxbox)


apt-cache search notification-daemon

As a KDE user I can not suggest particular one. Perhaps 
notification-daemon package is enough.


It is better to protect "&<>" characters as HTML entities "" etc. 
since the spec allows some basic formatting and active links.