Closed installgentoo closed 7 years ago
Do you have a program to reproduce it? Can you try it with Git master (to become 4.1 soon), please?
as i said program is called worker http://www.boomerangsworld.de/cms/index.html
@Elv13 sorry, i've assigned you because from the first glance it was similar to a placement issue with dialogs for which i did not had enough data for a report
it is still broken as of 4.1.
what more info do you need? just install the fucking program and see for yourself.
@installgentoo It might be related to you moving the mouse pointer accidentally?!
But as you can see from @Elv13's reaction your attitude is really not helpful. I am unlocking the conversation for now, so you can answer eventually, but please be more polite and help us with tracking the issue down.
Somebody would have to investigate, and nobody apparently has - not even you, although you have the source of awesomeWM..! (let's not discuss this - either provide more information or leave this issue open).
holy shit, that reaction.
no, i am not moving the pointer. guys, i gave you explicit report on how to reproduce the bug. download the program, run it, and delete a non-empty directory. you'll see that focus is bugged. what more useful info can i give?
how do i know it's bugged? because behaviour is not present in 3.5, dwm, and indeed ANY other dm. and more importantly because current behaviour is inconsistent. focus sometimes goes back to the parent window, sometimes it functions as it should.
if you have inconsistent behaviour in your program- there is a bug.
http://www.boomerangsworld.de/cms/worker/index.html
low requirements (basically only the X11 libraries)
My time is limited and the above makes me suspect that this issue could be in worker and not in awesome (X11 is way too easy to get wrong...). This means that I do not have much interest in spending some hours to figure out what exactly goes wrong only to conclude that I cannot do much about it, because something is not following the standards correctly. I already wasted enough time that way on Java. This does not mean that I were just ignoring this issue, but just that I did not have the time to look into this yet. Anything which starts with "install this piece of software" feels like something requiring lots of time from my end. Of course, the Worker devs might react quickly to such a bug report. That might give me a warm fuzzy feeling of having improved the world. However, there are enough others warm-feeling-sources currently.
what more info do you need? just install the fucking program and see for yourself.
And now this issue fell off the end of my todo list... Welcome to Open Source where all the work is done by volunteers. Part of this means that you do not get to make requests. If you actually paid for something, you might be in the position to make requests (but good luck with that in practice). If you are profiting from other people's hobby work, then you do not get that right. I have currently 60 "things waiting for me to look at" and that number hasn't reached zero in years.
jesus christ...
you do realise this only happens in awesome 4.*? there is a bug.
Closing as "Cannot reproduce".
I installed worker from debian testing (Version 3.8.5-2). I created a directory to delete via cd /tmp && mkdir foo && echo bar > baz
. I then started worker
and had to click through some configuration dialogs for a minute. "This is the first time you start worker, should I create a default config or just use a builtin default config" builtin please. "Your config is for worker 3.0. Should I upgrade it to version 3.1?" no, thanks, you stupid thing... "Your config is for worker 3.1. Should I upgrade it to worker 3.2?" Honestly? What the fuck. This continued for a while. Then I had to figure out how to actually use this. Ok, eventually I found a button labelled "/tmp", let's click that. Ah, now it shows my foo
directory. Let's click on it. Ok, what now... Ah, there is a button with "Delete". When clicking it, worker asked "Do you really want to delete this directory recursively". I clicked yes and that was it.
Compare this with your description of the problem:
focus breaks on second popup(first is "do you really wanna delete", second is "delete it recursively?")
There is no second popup.
you do realise this only happens in awesome 4.*? there is a bug.
Ok, I'll agree that there is a bug. Now please agree that you are not the best bug reporter that exists. Also, please agree that I followed your instructions as good as possible.
Feel free to reopen when you have working reproducing instructions. I am not going to figure out how to configure this thing so that it breaks.
Edit: Oh and even though I said "no", worker
created a ~/.worker
directory with a configuration.
And since you want to have some technical details, I grabbed the source of worker and grepped for XSetInputFocus
: https://sources.debian.net/src/worker/3.8.5-2/src/aguix/popupwindow.cc/#L98-L110
This function unconditionally (well, I guess "onScreen == true" just means "the popup window is visible") calls XSetInputFocus
with CurrentTime
.
ICCCM section 4.1.7 says: https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
Note that clients must not use CurrentTime in the time field.
Should I also find some specific example on how Worker violates all four possible input models from ICCCM, or is this (pretty clear) example enough?
There is no second popup. delete non-empty directory.
I couldn't resist: grep
finds no mentioning of WM_TAKE_FOCUS
and there is code in awindow.cc
and aguix.cc
which sets the input field of WM_HINTS
to true, so I guess worker
is using the passive input model (see the corresponding table in ICCCM § 4.1.7). The description of that input model in ICCCM § 4.1.7 is:
The client expects keyboard input but never explicitly sets the input focus.
So, there should not be any call to XSetInputFocus
ever.
Assuming that worker
also creates some windows with the input
flag in WM_HINTS
: That would be the "No Input" input model and I doubt a lot that it is used by worker.
@installgentoo are you using "sloppy focus" in awesome wm?
yes i do.
however with click-to-focus bug still occurs. i'm not moving the mouse.
Output of
awesome --version
: awesome v4.0 (Harder, Better, Faster, Stronger) How to reproduce the issue: start up "worker" file manager, delete non-empty directory. i'm quite sure you can also reproduce this with other programs that spawn a few popups. Actual result: focus breaks on second popup(first is "do you really wanna delete", second is "delete it recursively?") and goes back to file manager from it. sometimes it doesn't and works correctly, but this does not depend on anything you, user, do. Expected result: focus should stay on popups as it did on awesome 3 and does on every single other wm.it may also appear that this does not happen on happen on default config, but it actually does, in something like 1/20 tries.
i swear there wasn't a single fucking release of awesome that wasn't broken in some way. constant config fuckery is bad enough, but when you break old functionality...