how to make conky consistenly pass clicks to the root window #320
Comments
|
can you please share you working 1.9 config. Many many years back I was using exactly the same solution as you have - command line ubuntu to install with openbox or fluxbox - I levitated to Arch Linux+XFCE4+Compiz. No GUI login etc - use the command line to login to the X. |
|
Thanks for responding, Plikhari. Here is the content of my ~/.conkyrc which is working under 1.9 in 14.04, 64 bit. There doesn't seem to be any way to paste in code here and preserve plain text. So I'll try attaching it. |
|
And btw, that's working on 3 different instances of 14.04 with 1.9 on the same machine - one with lightdm, and 2 on which I use startx. Arch is high on my list of distros I haven't tried yet but intend to soon, certainly in the top 4. They have the best forum I've seen. |
|
lol when you do come to Arch land - it will liberate you - women will look good even without makeup - and since you are installing Ubuntu like an Ubuntu GURU - you are a prime acolyte to levitate to Arch Linux huahahahaha Have tested on my rig as well as on test Mint 18 - on both normal with window hints works and in override without any hints. But you are using openbox and Arch Openbox Wiki suggests using own_window_type = normal. Sooooooo I have cleaned up the rc file for the new rc format - see what it says now when you try to use it on conky 1.10+ |
|
Thanks, Plikhari. That did eliminate the error message and more importantly, eliminated the possibility of the problem being related to that error message. It did not however, improve the resulting conky's behavior. Still no click-through and now windows covered it up. Output logged like this: I tried all the window type settings. None were better than "normal", most were worse, none turned on the click-through. I found this at the end of the new man page: BUGS I'm not sure how relevant that is. It may be I need to file a bug report to extend those observations to OB. But I don't allow anything to "manage" my Desktop. ~/Desktop is just another directory I look at in the normal details view in Spacefm, or sometimes Thunar. If I have no windows up, my monitor is blank. It does not show the files in the Desktop directory. I tried xwininfo -tree as the man suggested, but the window ids seem to match. I have been launching with -o all along, it's also explicit in the rc, and I have tried all the window types. I doubt if the problem is using the old filename and location since it clearly IS being read and acted upon. I keep hoping somebody is going to say "Oh, those careless 16.04 devs left out the blahblah. You need to compile conky with foo set to bar." If I can't make this work, I'm considering these alternatives: -try dzen2 instead of conky. But that's a shot in the dark. I have no idea if it will do what I want. For several hours I thought I had a decent work-around. I made a pair of half-assed (of course that's a word - why doesn't the repo have a red-neck dictionary?) scripts that got called whenever Openbox notices a right or left mouse button PRESS (not click) in the body of a window. Then they apply some rather kludgy tests to recognize a conky window. Those are pretty weak, in principle could give false positives, and will fail if I change my conkyrc or method of invocation much. The problem there is that I haven't found any good way to get from the "window id" given by "xdotool getmouselocation" and something obxprop or ps or some other civilized program will recognize. So instead of some fairly good indicater of conky-hood, like _OB_APP_CLASS or _OB_APP_NAME, I have to use incidental properties like geometry and assume that if several match, it's conky. The problem isn't just decimal vs. hex. I can do the conversion. Indeed I have to, to get xwininfo to take it as an argument. And xwininfo is the ONLY program I've found that will take that as an arg and give me any more info about the window than xdotool already did. So I test several things in that output that might show the window is NOT conky, at least in its present form, and assume it is if none of those test trigger an exit. Bottom line, it should exit silently if the window clicked in is not conky and go on to do stuff if it is. So then if it seems to be conky, I use xdotool again to simulate keystrokes I've bound in my openbox rc.xml to the left and right click menus. That's a mouse press to simulate a keystroke that simulates a mouse click. Complex and fragile, and would need adaption to work on another system, or if anything changes, but it worked. Rube Goldberg is great. There is no god but Rube Goldberg. Unless you're British, in which case it is another cartoonist whose name I can't recall. But then Murphy struck. Finagle knows why, but my workaround messed with xset, causing it to give false but plausible output. Which is really kind of bizarre. Strictly speaking, it looks to me like a bug in xset. The guy that wrote and maintains Xscreensaver, Jamie Zawinski, in distinguishing between what's reasonable to accept in aps that touch on security as opposed to those that don't, writes about bugs that can be described as "if I do these 3 crazy things at the same time on a Tuesday, my ap fails". In the absence of security implications if someone does those deliberately, the proper fix is: not to do those 3 crazy things, at least not on tuesdays. And since my workaround kind of falls in the "3 crazy things" category, and I really don't want xset to give me plausible false info, I scrapped that. So I'm back to square 0 with no click-thru-to-root. If nobody posts any more suggestions here and I don't have any great breakthrough in the next few days, I'll try to find the report for the bug mentioned in the new man page, add a comment re openbox and a link to this and then give up. Can ANYONE confirm they have click-through-to-the-root-window working with Conky 1.10.1 under Openbox? If so, what is the setup like? Conversely, can anyone confirm that it DOESN'T work for them with Conky 1.10.1 under Openbox?If there are several of us in the second category and none in the first, then in all likelihood, this is just another aspect of the known bug mentioned in the man page. But if it is just me, then maybe this is still worth trying to figure out. And if, for example, somebody has it working under Lubuntu 16.04, then there probably isn't much point in my trying to compile an older version - I just need to figure out what Lubuntu has that I don't. Thanks for reading, and TIA if you can offer insight. |
|
I'm having the same issue. Unless I set "own window = false", I'm unable to pass my clicks to desktops. And since I'm using compton (transparency in docky), my conky simply disapears when I set "own window = false". Edit: Just checked version 1.9 in Debian right now, and there's no problem passing clicks there. |
|
Thank you, Allenriath. I tried "own window = false" and my conky also disappeared, although I do not use compton or docky. Mine is a very minimalist system. X and Openbox. I have also attempted to build conky 1.9 from source and failed for lack of glib-2. If I pursue that further, I suppose the next thing to try is to compile glib-2. sigh I have compiled and installed a more RECENT conky than the one in the Xenial repo. I'm now running it - 1.10.6_pre. I can't see any difference in the way it works. The Xenial repos don't have an old version I can downgrade to. At some point I may try to get a deb from another 'buntu or Debian and try that. Or enable a foreign repo long enough to downgrade. I think what I may try next is to see if there is anything in this thread I'd really like to get this working. My workaround for now is to associate the right and left clicks on the openbox title bars with the menus. The worst part of that is probably that if I change focus by clicking on a title bar I get a menu. Hmmmm . . . Maybe I can change that in the rc so that those clicks are only associated with the menus for FOCUSED windows. I don't know it that is possible to do directly. Certainly I could send the clicks to a script that would do one thing if the window was focused and something else if it isn't but that is likely to work out like my script to send the clicks in the window body to a script that opened the menus if the window body belonged to conky and just passed on the clicks otherwise - slow, complex and fragile. And it wouldn't give me anything to click if I had the window title bar off screen as I sometimes do. Ah, there is another idea: I could map clicks to ANY window body to the menus and map cntrl clicks to pass on plain, cntrl-less clicks to the window body. That would avoid having identify the window which I think was the main reason my earlier script was slow. I think I'll try that first. I'll let y'all know. |
|
OK, this looks real promising: But, BUT, WARNING, DANGER, WILL ROBINSON! |
|
OK, finally I just hunted down the executable (it was in /usr/local/bin if I remember correctly) and rm'ed it. That seems to have worked. So far. Then I installed the 1.9 with the gui of gdebi. Rebooted. YES!!!!!!!! Conky 1.9 rides again! This seems to be OK. If I develop problems I suspect this of maybe contributing to, I'll post back, but otherwise, no news is good news. I mean unless maybe I died or got amnesia or something. So, just to be vacuum clear: Now I just need to go fiddle in Synaptic to make sure this doesn't get "upgraded" on me. |
|
Is there a known method to have WORKING right click on desktop with Conky 1.10.x or the only possible way to do that is to downgrade to WORKING Conky 1.9 version? |
|
Update: which I got from bodi.zazen's answer here: seems to work. That page also talks about pinning, which should allow you to forbid a specific version, but not block the first upgrade that went BEYOND that version. If it would allow me to block any 1.10* and try the first 1.11, I'd probably do that, but what I've read so far doesn't make it clear if I can block a wild-carded version number like that and I don't won't to be bothered with testing every minor change. So, that's my solution for now. @vermaden AFAIK, 1.10 is broken, period. Read the whole thread. Workarounds are discussed but they are fragile and slow. 1.9 works fine in Ubuntu 16.04, 64 bit, for me. If you devise a better way, please post it. |
|
Thanks for short meritum. If anyone would need to lock the package in FreeBSD, then its ... and that one to list locked packages: |
|
Running older conky 1.9 on FreeBSD: |
|
Does latest conky 1.10.6 release fixes this problem? |
|
It doesn't. |
|
I have click through working with the help of a patch I've been using since v1.10. Not sure if it is relevant to this issue but without it my click through doesn't work. Running Arch Linux, xfce, conky v1.10.6. I also compile with "-D BUILD_XSHAPE=ON" Here's the patch file I use. |
|
@dafky2000 "Not sure if it is relevant to this issue" - Sounds pretty darned relevant to me. Thanks for posting it. What window manager are you using? That seems to be the determining factor as to whether this bug shows up. If you wander back this way, maybe you could enlighten us poor Ubuntards a wee bit. If I bone up on patches and compile with this and the suggested option, what happens with respect to updates? Do I still need to keep it pinned, lest an update overwrite it? Or will an update somehow determine if the patch is still relevant and keep it? My older conky is doing everything I ever asked it to except run in a tty, and that's not too important. If I'd have to keep the patched version pinned ANYWAY, if there isn't a security issue with the older conky (and I'm not certain apt-check would tell me about a security issue with a pinned version) then it seems to me I might as well not fix what ain't broke. But there are several IFs there that I don't really know about. Does my reasoning seem sound? |
|
@Lew-Rockwell-Fan My window manager is xfwm4. I am no expert with Debian/Ubuntu but I'm going to say you would have to pin the package or re-apply every update. AFAIK your patch would be overwritten by apt update/upgrade. I have just been re-applying the patch whenever Conky updates in the Arch repositories which isn't terribly often and would be even less so on Debian/Ubuntu. #213 is the issue this patch came from Here are the relevant lines in my .conkyrc |
|
@dafky2000 Thanks for your response. I missed at the time. Found it when I looked up this thread to remind myself of some details because it looks like I'll have to do the same thing in Debian 9 (stable stretch). I hope the devs read this and incorporate your patch. |
|
For anyone downloading the deb with wget as suggested as suggested by Corey Goldberg in the link I posted earlier, I can add a slight refinement. His way you are downloading a deb, not even over https, without even a hash, let alone a signature. In 16.04 you can trick apt into getting this for you, doing it's gpg magic, thus: Install a gpg key you will need to get conky 1.9: Now you have a good conky and cryptographically verified deb for the next time you need it. If you don't want to do that, at least check the sha512: Or if you see some logical flaw in my thinking, by all means point it out. |
|
Has this fix been suggested via a pull request? |
|
@mswanson-me |
|
@Lew-Rockwell-Fan : A pull request is a suggested change to the code. It looks like @dafky2000 has a solution that works for him. If that works for you, too, then one of you can fork the repo, make the appropriate change, and make a pull request. |
|
@mswanson-me This issue can likely be closed now.. That patch came from #213 which has been merged. It is just up to repo maintainers to implement. I'll likely still need to manually apply the compile flag |
|
Ok cool. I'll mark this as pending closure. If you are able to, please let us know once you've tested the fix, just to be on the safe side. :) |
|
I've personally been using that patch for almost an entire year without any issues. |
|
It works perfectly! I still had to add the compile flag but I will harass the Arch repo maintainer, @vesath, to add it ;) |
So, does that mean if I download the latest source on github & compile it , it is supposed to work? That the patch is included? Pardon my ignorance, but this comment in the patch concerns me:
Does that mean click through would work ONLY for a Conky with a title bar? That's a pretty serious limitation. Or even worse, surely it doesn't mean that pointer input (I resist calling my trackball a mouse) would be blocked from ALL windows without a titlebar? That would be terrible. Even unpatched 1.10 would be bettter than that for me. |
|
My conky overlay does not have a title bar (is undecorated) and it works fine :) I think this means that only decorated windows can received mouse input through the overlay. |
|
If
that would exclude the root window, which for me is the whole point, to have a tunnel to the root window that works when a DECORATED window is over it. That actually sounds like the opposite of the classic behavior and the opposite of what I want. So, to clarify, the classic behavior that I depend on is: Several of the *box type window managers come with menus or other important stuff mouse-bound to clicks on the root window. So this behavior is potentially important to people using Openbox, Blackbox, Fluxbox, etc. Those mouse-bindings can be changed, but that entails changing a lot of other stuff. So, is that behavior restored in 1.10.8? |
|
Ok, so I misunderstood this issue then. My mistake. Maybe that also fixes this behavior? Test it out! Click through to the root-window (desktop) and xfce-panel with no other windows in the way work fine and I assume they are "undecorated"? |
|
Resolved via #213? Closing? |
|
1.10.8-1 still fails for me in Ubuntu 18.04, bionic, the current LTS release, in an environment otherwise the same as I described above (plain Openbox under X, amd_64, etc.). 1.9.0-4 still works fine. Maybe there is some new trick in the rc file to make it work, but you can't prove it by me. It ain't fixed as far as I can tell. It just passes the "mouse" actiion through to whatever window is underneath. I didn't check to see whether decoration affected this, but either way, this is NOT the classic behavior, which is to pass it through to THE ROOT WINDOW. This is not a trivial difference to anyone using any of the *box window managers and using the native menus. Maybe there is a hidden option to enable the classic behavior. Maybe Canonical is just behind in getting a working verion into their repo. Maybe the devs have no intentiion of fixing this - maybe for some it's a useful new feature. Maybe they don't understand the issue. Maybe Openbox is at fault. Damfino. But bottom line - it still doesn't work for me out of the official 18.04 repo box, and installing the 1.9.0-4 from the deb and stopping it from upgrading, still does. And seems the easiest workaround. No significant change that I can see. I just check this thread occasionally when I have some reason to suspect progress has been made. |
The click-thru-to-root-window behaviour seems to have changed in upgrading from Conky 1.9.0 under a stripped down Ubuntu 14.04 with Openbox as the only DE to Conky 1.10.1 in a similar stripped down Ubuntu 16.04. I want to regain the previous behaviour.
In the past I've been able to get conky to pass mouse clicks through to the root window. My ~/.conkyrc that works fine in previous Ubuntus fails to do this in the new LTS 16.04. I start it with "conky -o" in Openbox's autostart.sh, which is a script that runs under /bin/sh, which in 'buntus is linked to /bin/dash (and does so even if you put a shebang to the contrary in it) immediately after the window manager Openbox starts. Strangely, this doesn't work, if I start Conky later, from a terminal. If it gets killed, I have to restart Openbox for it to work right. Obviously I'm not using a regular Ubuntu. I build a real light system from the mini.iso with plain Openbox, no further DE per se. No Gnome, no Unity, no LXDE, just Openbox.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Routing error and output to a log, this is what happens under Ubuntu 14.04 with Conky 1.9.0:
Conky: forked to background, pid is 3244
Conky: desktop window (2b7) is root window
Conky: window type - normal
Conky: drawing to created window (0xe00001)
Conky: drawing to double buffer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Under the same circumstances in 16.04 with Conky 1.10.1 it logs this:
conky: Syntax error (/home/j/.conkyrc:1: '=' expected near 'yes') while reading config file.
conky: Assuming it's in old syntax and attempting conversion.
conky: desktop window (497) is root window
conky: window type - normal
conky: drawing to created window (0xc00001)
conky: drawing to double buffer
conky: forked to background, pid is 4253
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Assuming the ":1" in "Syntax error (/home/j/.conkyrc:1:" meant the error was in the first line (is that right?), I tried changing "yes" to "= yes", but it didn't make any difference.
I also tried the new conf file in config instead and tried all the window type statements. I haven't changed my openbox rc.xml so I don't think the change is there. I can try influencing the conky "window" with statements in openbox's rc.xml or by hitting it with wmctrl or xdotool, but I haven't a clue how to use those to bring about this click-through property, which is something I haven't seen in any other context. How can I make it pass the clicks through consistently?
I hope I haven't been exploiting an undocumented accidental "feature" that has been dropped, because it has been an extremely useful feature for me in the past.
If nobody suggests anything else, I may see if I can force the system to use an older version of conky. The Ubuntu repo doesn't have older versions, so I downloaded the tar for 1.9 and extracted it. "README.git-version" says I need aclocal to build it. That's in the package "eclipse-cdt-autotools" which consists of over a hundred files taking almost half a gig of drive space. Wow. If that's what it takes, I'll do it, but it seems surprising enough to mention. My entire 16.04 is only 3.3 gigs.
Thanks.
The text was updated successfully, but these errors were encountered: