Clipboard History appears on application start #691

Closed
piersb opened this Issue Feb 8, 2012 · 11 comments

4 participants

@piersb

Since the recent auto-update to B64 3915, the Clipboard History window now appears every time the application is started. There doesn't appear to be a setting in Preferences to stop this happening, and an Internet search says it's a bug - but I can't find a bugreport here.

So I'm creating one.

@pjrobertson
Quicksilver OS X member
@piersb

It appears in the middle of the screen when the app starts, then closes. It's closed when I quit Quicksilver, and the plugin is v 1.1.1.

@pjrobertson
Quicksilver OS X member

Hi again.

The Clipboard module was recently fixed to avoid this behaviour, so it is strange you are still seeing it. May I suggest you browse to this directory in Finder and delete the 'clipboard module'
~/Library/Application Support/Quicksilver/PlugIns

Once you've done that, try re-downloading the plugin.

Do you have the problem if you restart Quicksilver by pressing ⌘⌃Q or only when Quicksilver is first launched (e.g. when you log in)?

@skurfer
Quicksilver OS X member

This happens with the Shelf too. It has nothing to do with B64. It’s been happening to me for at least 6 years.

The Clipboard module was recently fixed to avoid this behaviour, so it is strange you are still seeing it.

I thought that was for people that did want to see it on launch but only if it was docked. If you’re wondering why I didn’t bring it up, the recent changes didn’t bring up any new problems and never promised to fix my old ones. :-)

I also haven’t been able to find enough of a pattern to make a good report. I’ve seen it on a fresh launch and with a relaunch. Sometimes the panels go away after a second, sometimes I have to move the mouse over them, then mouse out of them and they’ll go away, and sometimes I have to click the close button (which doesn’t close them) then mouse out before they’ll go away.

I’ve mentioned this before, but I’m convinced (in my case anyway) that these panels think they’re docked to a screen edge even though they aren’t. That would explain

  1. Why I can’t dock them to an edge
  2. Why they tend to only go away when I mouse out of them

I haven’t ben able to figure out where the state for these panels is stored between launches, or I would try trashing the settings.

@pjrobertson
Quicksilver OS X member
@skurfer
Quicksilver OS X member

I did not know anything about the panel appearing on launch.

I guess I always thought it was the same thing that made it appear randomly at other times, but now that I think about it, the random appearances when quitting apps does appear to be fixed. I wasn’t suggesting you missed something. :-)

Hmmm. QSPasteboardHistoryIsVisible seems to be NO when Quicksilver is shut down, but when running, I see it set to YES at times. (This is without doing anything in Quicksilver since launch.) I think QSPasteBoardController corresponds to “Hide after pasting”.

I think NSWindow Frame QSPasteboardHistoryWindow must be what I’m looking for. I’ll mess with it tomorrow.

@skurfer
Quicksilver OS X member

More info… The problem seems to be with line 61, which reads

BOOL visible = ![(QSDockingWindow *)[[self sharedInstance] window] hidden];

The result seems to alternate between YES and NO every time Quicksilver quits. That is, quitting seems to toggle the setting. So every other launch is where I see the window reappear.

@pjrobertson
Quicksilver OS X member
@skurfer skurfer added a commit to skurfer/Quicksilver that referenced this issue Feb 9, 2012
@skurfer skurfer initialize the value for `hidden` - fixes #691 dc9874e
@sanzoghenzo

I'm experiencing the same problem, should I assume the next version contains the fix?

@skurfer
Quicksilver OS X member

should I assume the next version contains the fix?

No, but we’re working on it.

@skurfer skurfer referenced this issue in quicksilver/elements.clipboard-qsplugin Apr 12, 2012
Merged

determine startup state on startup instead of shutdown #3

@skurfer
Quicksilver OS X member

This should have closed automatically when the fix was merged, but of course, didn’t.

@skurfer skurfer closed this Apr 12, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment