[SOLVED] Popping up new window without focus... how to do it?

rnturn · 03-15-2017, 12:16 PM

I have a reminder system that I wrote a while back that plays an audio file and pops up a window--using xmessage(1)--based on other shell scripts, crontab entries, etc. While it works rather well, it has one rather annoying side effect: the popped up window takes input focus away from whatever the user is currently doing. Anyone getting one of these notices that's doing any kind of text entry (coding, writing test, etc.) loses some work when the notices pops up until they manually reset input focus to the editor or browser.

Is there a way to have xmessage open a window but not grab input focus? I've done some searching in the manpages and found nothing that appears to control that. While I might be able to modify the way that the window manager deals with new windows--KDE is my preferred but I'm hoping for a solution that is agnostic with respect to WM--I'm afraid that such a change would affect all windows; something I definitely want to avoid.

Any ideas?

TIA...

--
Rick

hydrurga · 03-15-2017, 02:50 PM

Could you try using gxmessage instead? It has the following option:

Quote:

-nofocus
Prevents the gxmessage window from receiving focus when it
opens. This option is not compatible with xmessage.

ondoho · 03-15-2017, 03:33 PM

maybe you should use "notify-send" instead???

rnturn · 03-15-2017, 04:01 PM

Quote:

Originally Posted by hydrurga

Could you try using gxmessage instead?

Maybe except I cannot find it on the system or using any repository searches in YaST. I assume this is a GTK version of xmessage and that would work. If I can find an RPM for it. (Or, if I'm feeling adventurous and want to try and build it from sources.)

rnturn · 03-15-2017, 04:15 PM

Quote:

Originally Posted by ondoho

maybe you should use "notify-send" instead???

That's sort of nifty but in addition to using it for "Weekly conference call in 5 minutes"-type messages, I also use xmessage within scripts and like that it's interactive and let's me set the exit status so I can branch accord to whatever button was clicked on; notify-send doesn't appear to allow that. One other thing I like about xmessage is the ability to run it and specify a big obnoxious font size. I haven't figured out how one does that with notify-send yet. Or if it's even possible.

hydrurga · 03-15-2017, 04:29 PM

Quote:

Originally Posted by rnturn

Maybe except I cannot find it on the system or using any repository searches in YaST. I assume this is a GTK version of xmessage and that would work. If I can find an RPM for it. (Or, if I'm feeling adventurous and want to try and build it from sources.)

Any of these do you?

https://www.rpmfind.net/linux/rpm2ht...uery=gxmessage

ondoho · 03-16-2017, 02:11 AM

Quote:

Originally Posted by rnturn

That's sort of nifty but in addition to using it for "Weekly conference call in 5 minutes"-type messages, I also use xmessage within scripts and like that it's interactive and let's me set the exit status so I can branch accord to whatever button was clicked on; notify-send doesn't appear to allow that.

well it's either that, or no focus.
i fail to understand how you can both
- not have focus
- demand user input
???

Quote:

One other thing I like about xmessage is the ability to run it and specify a big obnoxious font size. I haven't figured out how one does that with notify-send yet. Or if it's even possible.

it is possible, depending on the actual notification daemon.
i use dunst as my notification daemon, and it is definitely possible with that.
other popular choices are: xfce4-notifyd, deepin-notifications, lxqt-notificationd, mate-notification-daemon, notify-osd etc.

camp0 · 03-16-2017, 03:39 AM

Here is another option in python

Code:

from gi.repository import Notify
Notify.init("App Name")
Notify.Notification.new("Hi").show()

GazL · 03-16-2017, 04:59 AM

xmessage itself doesn't take focus: in fact you'll find most normal Xlib applications are passive with regard to focus because focus stealing is considered bad behaviour. You can confirm this yourself if you start X with something like xinit /usr/bin/xterm from a tty instead of starting X the usual way and then running xmessage without a window manager present.

A program may set the 'Input field' of WM_HINTS to let the window manager know whether or not it needs or expects input focus (things like xload/xclock set this to 'false') but I'm afraid xmessage doesn't provide an option for setting this and it's entirely down to the window manager to decide whether to give focus to a window or not when it is mapped and as such that is where you'll have to look to see if you can configure it not to do this to xmessage's window.

rnturn · 03-16-2017, 09:22 AM

Quote:

Originally Posted by hydrurga

Any of these do you?

https://www.rpmfind.net/linux/rpm2ht...uery=gxmessage

Ah. My googling may have found that but it must have been farther down in the findings. The higher rated links weren't all that promising. I'll give that a shot. Thx...

rnturn · 03-16-2017, 09:31 AM

Quote:

Originally Posted by GazL

xmessage itself doesn't take focus: in fact you'll find most normal Xlib applications are passive with regard to focus because focus stealing is considered bad behaviour. You can confirm this yourself if you start X with something like xinit /usr/bin/xterm from a tty instead of starting X the usual way and then running xmessage without a window manager present.

Good point. I have started up X manually like that for a lo-o-ong time. I do recall that behaviour.

Quote:

A program may set the 'Input field' of WM_HINTS to let the window manager know whether or not it needs or expects input focus (things like xload/xclock set this to 'false') but I'm afraid xmessage doesn't provide an option for setting this and it's entirely down to the window manager to decide whether to give focus to a window or not when it is mapped and as such that is where you'll have to look to see if you can configure it not to do this to xmessage's window.

Interesting. (I'm guessing that you must have some some low-level X11 programming in the past.) So manipulating WM_HINTS must be the big feature that drove the development of gxmessage?

Another responder reminded me of an RPM finder site--that I haven't visited for ages--that looks like it has an RPM for gxmessage. Guess I've gotten too comfortable with the typical SuSE repositories; they usually have everything I need.

Thanks for the info...

rnturn · 03-16-2017, 11:19 AM

Quote:

Originally Posted by ondoho

well it's either that, or no focus.
i fail to understand how you can both
- not have focus
- demand user input
???

Windows can open but not take over the keyboard. What I'm looking for is for the window to pop up and wait for the user to select it.

rnturn · 03-16-2017, 11:31 AM

"hydrurga"'s suggestion of gxmessage did the trick. (Thanks.)

I found no RPMs--or SRPMs--that were built for OpenSUSE 13.2 but did find an old 2.6.0 SRPM for SUSE 9. That built against without error (w/ couple of warnings) but seems to run OK. Well, except that the window size did not auto adjust to the length of the message. Eventually I tracked down an newer SRPM (v3.4.3). That works even better. I do find it a little funky that it doesn't accept X11 font naming and one script had to change the font name from "-*-fixed-*-*-*-*-*-400-*-*-*-*-*-*" to something like "Adobe Courier 40" but that's not really a problem though it makes it not quite a drop-in replacement for xmessage.

Marking this one solved.

Thanks to all who offered suggestions.

Later, guys...

GazL · 03-16-2017, 12:21 PM

Quote:

Originally Posted by rnturn

I'm guessing that you must have some some low-level X11 programming in the past

Nah, I just like to read the manuals and dabble with things. I've got the basics of Xlib down, little more than that.