Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Have kdialog preceeded by (or succeeded after an "&" if the context allows it, and if it's preferable for some reason) a loop that has wmctrl "grepping"/activating" the unique name of the kdialog window, followed by xdotool resizing it, and breaking the loop.
Code:
( while true ; do
sleep 0.2 # reduces CPU load if the loop never breaks for some reason
wmctrl -a "relevant and ideally unique title for kdialog window" &&
Probably can be easily adapted to notifications handled by any other notification daemon, requiring one to see what they're called with xprop or something:
Code:
notify-send "bogus" "$(ls /usr/bin)" & xprop
Then click on the notification. "lxqt-notificationd" is the "_NET_WM_NAME(UTF8_STRING)" but also a lot of other things, I'm not sure which one is...
If you ever see yourself wanting to manipulate gxmessage dialogs/windows with wmctrl for some reason, you may notice the name of the window set by gxmessage itself is kind of ignored, depending on the parameters you'd use on wmctrl. It will instead still behave as if the window title was "Gxmessage," or yet "gxmessage.Gxmessage," depending on wmctrl parameters. Which is troublesome if you have more than one.
I thought it would be needed to grep the title from a...
I find annoying that, for whatever reason, it seems that some windows get "almost maximized" (I have the impression that some browsers do that by "design", even though I'm not sure), and then I end up clicking in a desktop pixel instead of the scroll bar or something. In my case that action is assigned to show the desktop/minimize all windows.
So here's what I just came up with so far, for a 1280x1024 resolution:
When XWindows was ported to 64 bit architectures, the decision was made (probably for legacy compatibility) not to add a 64 bit data format to routines that return overloaded pointers, specifically XGetWindowProperties. Pointers, which are 64 bits, are returned in 64 bit elements that are claimed to be 32 bits. There is no way to cope with this in user code, except to check which architecture you are running on. The compiler define "__x86_64" is set on Intel 64 bit compilers. wmctrl (not...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
