Comment by ~scoopta on ~scoopta/wofi
If desired an option could be added to only search application names rather than all the additional metadata wofi defaults to. Something like
drun-no_meta_search=true. Not sure how many people are interested but it should be a fairly trivial option to add, if I remember right that's how wofi used to be until a request was opened to match on additional metadata like descriptions etc.
REPORTED RESOLVED IMPLEMENTED
Comment by ~scoopta on ~scoopta/wofi
Ok, I'm now convinced this is some weird sway bug with damage tracking or the like. I just accidentally ran across some extremely bizarre behavior. If I have a program below wofi then it works as expected, if I have nothing below wofi and I'm just on my wallpaper then I get corruption, again only if the target monitor is a lower resolution than 0,0. Here's where it gets weird though. If I open wofi over some other program on the target monitor using wofi's
--monitoroption then not only do I get the corruption but the corruption stays even AFTER I exit wofi with escape, at which point wofi is no longer running yet the corruption doesn't clear until I move my mouse over that other program, bringing it into focus and fixing the corrupt bits.
Comment by ~scoopta on ~scoopta/wofi
TL;DR I've reproduced this, hopefully I'll actually have time to fix...as a workaround if you set wofi's dimensions in pixels this will stop happening, ofc that's not a good solution as then it will stop scaling based on monitor size.
So I've actually sat down and reproduced this...partially. So the thing about GTK is the monitor your program is currently on isn't known immediately, wofi compensates for this by setting its size based on the current monitor at program launch(this is always the one at 0,0) and then 50ms later it does a resize if the resolution of the monitor has changed(in reality the monitor we're on was originally wrong). This has always worked in my testing but I'm not sure I tested all cases. Either way it currently still works as intended...sort of. For me if the monitor at 0,0 is lower resolution than the others it works correctly, I don't get any weird artifacting so I'm not sure how you were getting artifacts inside the window Yoitsu. However, if the monitor I open it on is a lower resolution than 0,0 I do get artifacts outside the surface where the surface had originally been. This behavior makes more sense to me intuitively because if wofi's window needs to grow then it should redraw all the inside bits too and result in no corruption, however if the window needs to shrink then it could be that the old bits of the buffer are becoming corrupt and just glitching out. Even then I'm not sure why this is as I'm not just resizing the window but before I do that I resize the layer surface so I would THINK the compositor should take that part of the screen back, maybe I'm just missing something but I'd be curious to know if this happens on other compositors besides sway, maybe something for me to test, regardless I'm going to go read the layer shell documentation and make sure I didn't make an oopsie anywhere.
Comment by ~scoopta on ~scoopta/wofi
I believe this is a duplicate of #183
REPORTED RESOLVED DUPLICATE
Should be addressed in the latest master (thanks for all the feedback ~scoopta). @Maxim baz, let me know your thoughts and whether this addresses your issues.
Comment by ~scoopta on ~scoopta/wofi
I'm interested in the multi-contains patch as well and I did understand your original message, I'm just far more excited for the fuzzy matching. While I don't personally use it it's something that I've known needed improving for a while. Looking forward to the updates and patches.
Comment by ~scoopta on ~scoopta/wofi
I will look at this when I have time...which is hopefully soon, I'm actually really excited about this as the fuzzy matching has always been rather poor but it's a bit outside of my skill set to implement
Comment by ~scoopta on ~scoopta/wofi
This is really weird and I'm honestly not even sure where to start because neither I, nor anyone I know personally has this issue. I'm running sway 1.7, wlroots 0.15.1, and mesa 22.0.5. Unless it's a bug specifically in mesa 22.1 I have no mechanism to reproduce this. I guess the first question is are all you guys running tip? If not please update, if so did this start happening after a system update, after a wofi update? I need as much information as possible to have any hope of finding this. When I get some time I'll try updating to mesa 22.1 but I'd be surprised if it were mesa causing it, definitely could be but that seems like an odd one especially since GTK3 uses shm for rendering IIRC.
Comment by ~scoopta on ~scoopta/glpaper
Fixed by f89e60b7941f
REPORTED RESOLVED FIXED
Comment by ~scoopta on ~scoopta/wofi
I can probably fix the prompt issue trivially(I hope), I'm not so sure about
--lines 0I'll look into both if I have time. I might start trying to work on addressing the open issues here, no promises but it could be good for me to work on wofi again.