[Bug]: Results list appears in top left corner of screen, detached from interface
usnmustanger opened this issue · comments
Before submitting your bug report, please confirm you have completed the following steps
- Searched the issue is not already listed in the Issue List (I've searched it)
- Searched in the Quicksilver Users' Group for questions relating to tech support.
- Downloaded the latest version of Quicksilver for your system and confirmed the issue still persists.
Bug description
The results list appears in the top left corner of my screen, detached from the interface. I'm currently using the bezel interface, but this happens regardless of which interface I'm using.
When I click the little gear at the right side of the results header, the resulting pop-up does appear where it should be if the results list was displayed below the interface.
The results list is not movable/draggable.
It may also be worth noting that the animated QS startup icon also appears in the top left corner of the screen, same location as the results list.
Steps to reproduce
- Activate Quicksilver
- Type something in the first pane
- Results list displays detached from interface, and in the top left corner of the screen
Expected behavior
Results list should display directly below the interface
MacOS Version
Other
Quicksilver Version
2.4.1 (4040)
Relevant Plugins
Crash Logs or Spindump
No response
Screenshots
Additional info
OS Version is latest OS 14 Sonoma beta (release 23A5337a, latest as of 9/8/2023)
I have tried the following, nothing changes the results:
- Delete prefs file
- Uninstall/clean reinstall Quicksilver
- Reboot Macbook Pro
- Installing QS in different "clean" user account
Thanks for the report! I don't know that any of the active devs plan to join the beta, but we'll look into this and try to reproduce once it is released.
Thanks for the report! I don't know that any of the active devs plan to join the beta, but we'll look into this and try to reproduce once it is released.
I understand, thank you!
FWIW, under 23A5286i (macOS 14 beta 3) I was able to move windows around. With macOS Sonoma build 23A339 (the latest Release Candidate), I get this same behavior. In addition, if I click the icon in the menu bar while focus is held by anything other than QS, input from the keyboard is mostly swallowed by something. I can recover by activating the QS shortcut and then clicking the menu bar icon again.
I'm not yet sure if this is a bug in the RC, or a change in macOS. If I figure it out, I'll let you know.
@usnmustanger if I deselect "Superfluous visual effects" from options, all the issues I observe go away.
@usnmustanger if I deselect "Superfluous visual effects" from options, all the issues I observe go away.
That fixed it for me too, thank you!
Also seeing this in macOS Sonoma 14.0 stable.
The QS launch icon, main interface window, and results dropdown all appear in the upper left of the screen.
I can move the main interface window to the middle of the screen manually, but:
- I can't move the result dropdown.
- The main interface window location is reset to the upper left if I restart Quicksilver.
- Sometimes the main interface window location is reset every time it shows anew.
Toggling "Superfluous visual effects" didn't help.
Okay, this worked for me briefly:
- Turn off "Superfluous visual effects".
- Change the interface from Nostromo to basic and back.
… but I relaunched Quicksilver to see if it persists, and now the settings window is stuck in the upper left as well. 😭
EDIT: tried again, and this time it worked!
Using Bezel (built-in) and deselecting superfluous visual effects, things seem okay. Required a relaunch after changing that setting.
Just wanted to chime in here that, on a fresh install on Sonoma, I can't even agree to the license agreement, much less toggle any UI settings.
Same here, with Sonoma 14.0 (23A344). Windows jump to wrong places. I cannot access settings. Computer becomes generally unresponsive at times. I have to force-quit Quicksilver to make the computer behave. Hoping for a fix, coz I honestly use Quicksilver all the time! Thanks!
Same issue on my system.
Computer becomes generally unresponsive at times. I have to force-quit Quicksilver to make the computer behave
on top of that I can add that when quicksilver is open (fresh install on sonoma, m2 max MacBook Pro 2023) the shortcuts on other apps fail to work as well.
Trying to chase this down,
[NSWindows setFrame:] doesn't seem to be working. I can manually set NSRect centeredRect = NSMakeRect(200, 200, 228, 204);; -- changing the second pair of values (width and height) changes the width and height of the intro QS animation, but the first two (which I arbitrarily set to 200, 200 here) doesn't change anything -- still just appears in top left.
Reading https://stackoverflow.com/questions/55965290/set-nswindow-size-programmatically-doesnt-work
Unfortunately moving setFrame into QSGCDMainSync doesn't seem to do anything. Neither does changing display:NO to YES, or adding animate:YES.
Commenting out [animation setTransformFt:QSExtraExtraEffect]; changes the intro QS splash so that it loads in the center again, but then moves to the top left.
I hadn't realized we were using private APIs (the vendored CPSPrivate.h, CGSPrivate.h) -- I wonder if that's related, as a lot of the animations seem to rely on transforms provided by these. That would make this pretty hard to debug I imagine.
I these private headers may also be related to the CGSWindowShmemCreateWithPort failed on port 0 that I see scattered throughout the console, and I think are new.
Tiny bit of very slow progress today, I think I was on the right track with the suspicion of cgs stuff above.
Changing cgs = _CGSDefaultConnection() to cgs= nil here allows the QS splash at startup and the results windows to both stay in the center of the screen instead of jumping to top left.
Culprit seems to be CGSSetWindowTransform, at both of these:
Here's a old related bug in which they speculate that CGSSetWindowTransform has abnormal behavior if called while a window is not visible: https://bugzilla.mozilla.org/show_bug.cgi?id=1448132
Guarding with if ([[self window] isVisible]) { does not fix the behavior in this case.
Issues persists even if I change to CGSSetWindowTransform(cgs, wid, CGAffineTransformIdentity);, so perhaps something about CGSSetWindowTransform is changing the positioning of the frame (or preventing it from being updated); IOW it doesn't seem to be a problem with the transform itself AFAICT.
I couldn't actually toggle "Superfluous visual effects" because the click events didn't seem to be delivered to the right control. But after UTSLing, I tried
defaults write com.blacktree.Quicksilver "Use Effects" -bool NO
and fingers crossed for now Quicksilver is working again on Sonoma.
and fingers crossed for now Quicksilver is working again on Sonoma.
unluckly i didn't work for me.
btw, on a computer where quicksilver was installed before the upgrade to sonoma I have no problem. on one where I installed quicksilver for the first time after installing sonoma nothing works
on one where I installed quicksilver for the first time after installing sonoma nothing works
interesting -- thanks for that tidbit, this may help me reproduce issues, since it's been running fine on my Sonoma system since day 1 (with superfluous visual effects disabled at least)
@n8henrie one way to proceed would be to:
- Remove
GCSPrivate.hfile - Xcode will then throw up build errors for places that call to undefined methods - remove all of these from the code
Aside: Plugins would also need checking.
I wonder if it is related to the "Stage Manager?" Following the below instructions I got the license windows etc. to stop flying completely off the screen (and playing whack-a-moving-button), but I noticed that the clicks were pushing the window to the edge of the thick grey outline when the desktop shows/hides. I could move the mouse to the upper-left (and click) and I could get the window to reappear, but as soon as I started to mouse over it (or click) it would slide away again. Is Stage Manager considering (at the very least) swallowing the clicks because it thinks you are clicking (through?) and on the desktop? After an app restart the "superfluous" fix seems to work, and with the below all seems....relatively good? :)