Adium

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#7862 closed defect (fixed)

Problem with windows not following spaces rules (Leopard)

Reported by: hotch Owned by: nobody
Milestone: Adium X 1.1.4 Component: Adium UI
Version: Severity: normal
Keywords: leopard spaces Cc:
Patch Status:

Description

OS X 10.5 Leopard Build 9A527

I read the ticked regarding orphaned windows when you minimize then use spaces. I'm also having an issue with Adium not following my setting to show it in every space. If I quit then reopen it will work for a while, but then it forgets again. Sometimes both my contact list and message window lose this setting, when that happens I can close and reopen my message window and it will work again for a little bit.

Any ideas? all my other software works just fine...

Change History (24)

comment:1 Changed 13 years ago by Eric Richie

Milestone: Leopard

comment:2 Changed 13 years ago by proton

This is probably a bug in Spaces.

Please file a bug with Apple.

comment:3 Changed 13 years ago by Sam Hotchkiss

i have filed the bug with Apple, but Adium is the *only* app that doesn't act properly

comment:4 Changed 13 years ago by Sam Hotchkiss

Follow up:

This problem still exists in 9A559

comment:5 Changed 13 years ago by Ryan Govostes

Version: 1.1.21.2svn

Docking the buddy list to one side of the screen is also problematic. I have the buddy list docked screen left and set to auto hide when Adium is in the background. Adium is configured to "every space."

Here's how it works (or doesn't):

  1. Adium is in front, on space 1.
  2. Switch to space 2. Adium remains in front.
  3. Switch to Finder. Buddy list autohides, can unhide by waving cursor at left of screen.
  4. Switch to space 1. Wave cursor at left side of screen -- no list.
  5. Switch back to space 2. Wave cursor at left side of screen -- list!

comment:6 Changed 13 years ago by Elliott Harris

Resolution: fixed
Status: newclosed

This is fixed in Leopard GM 9A581.

comment:7 Changed 13 years ago by Matthew Riedel

This is still a problem with Leopard GM 9A581

comment:8 Changed 13 years ago by Eric Richie

Resolution: fixed
Status: closedreopened

comment:9 Changed 13 years ago by Damien Sorresso

For what it's worth, Quicksilver's Clipboard plug-in window had a similar issue, where it would not obey the Spaces "Every Space" binding. The latest Quicksilver fixed this issue, so it might be worth talking to the developer to see what he changed. Both the Adium contact window and the Quicksilver clipboard window are NSWindow sub-classes, so maybe there's a certain behavior that Spaces doesn't like.

comment:10 Changed 13 years ago by cheesy

I poked at this a bit, maybe this will help shed some light on whether this is a spaces problem or an adium problem:

If I have my contact list and message window open, then switch the spaces settings to "all desktops", both windows become sticky. That works great until I open up a new tab in the existing message window, at which point the message window (but not the contact list) loses its stickiness. Every newly created chat window (even when created by tearing off a tab) is sticky, until I open a new tab again. Closing a tab does *not* affect stickiness.

Here's the *really* weird thing: If I have two chat windows open and then toggle the spaces setting to force them to be sticky, opening a new tab (which of course only affects one window) causes *both* to lose their stickiness! If I *drag* a tab between two sticky windows, they don't change their stickiness.

Just for completeness, opening and closing the contact list (Cmd /) causes just the contact list to lose its stickiness.

Hope that's useful.

comment:11 Changed 13 years ago by Zachary West

Milestone: LeopardAdium X 1.1.4
Version: 1.2svn1.1.3

Spaces does not behave well with Adium.

  • Contact List can't be dragged "through" the menu bar to another space
  • Contact list and message window don't always respect "every space" -- they get stuck on certain spaces

This effects 1.1.3 as well as 1.2svn.

comment:12 Changed 13 years ago by Evan Schoenberg

How do you drag a window through the menu bar, in general?

Is this standard or borderless contact lists?

comment:13 Changed 13 years ago by Zachary West

With a Spaces arrangement such as:

1 2 3 4

Dragging a window "up" into the menu bar (not through) from Space #3 will cause it to move to Space #1.

This is with Standard contact lists, I haven't tested borderless.

comment:14 Changed 13 years ago by Zachary West

That is:

1 2
3 4

comment:15 Changed 13 years ago by Zachary West

It's difficult to get the not-through-menu-bar to occur. It requires a message window open.

comment:16 Changed 13 years ago by Evan Schoenberg

Oh. Drag it to an edge, then hold it for a moment. Works on any screen edge for normal windows. Works for me just now with message window and standard contact list, both at the 'normal' window ordering level. Borderless contact list doesn't work... and I'm not sure how we can make it work for that given that a normal drag (of, say, an icon in Finder) doesn't do the switching behavior.

comment:17 Changed 13 years ago by Zachary West

It's difficult to reproduce getting stuck (and not movable on edges), but it's not difficult to reproduce the "all spaces" problem. I'm not sure how to make Borderless work either.

Contact list (dock-style) hiding does not work with all windows, either. My Contact List is currently sitting in space #1. My message window is in #2. The inverse happens pretty often too.

comment:18 Changed 13 years ago by Zachary West

Okay, I played with it a little. With CL + MessageWindow open…

Starting in space 1...

  1. Drag MW to space 3. CL stays in space 1.
  2. Go back to space 1. CL and MW are both there.
  3. Drag CL to space 3; MW follows.
  4. Try to move CL to space 1.

Often times, it won't move out of the space.

comment:19 Changed 13 years ago by Evan Schoenberg

Resolution: fixed
Status: reopenedclosed

(In [21399]) Disabled our hackery which was intended to let windows ignore expose, useful only when ordering below other windows and then revealing the desktop. This was causing intermittent problems with Spaces in 10.5 and simply isn't worth it IMO. I've left the code in place but commented out in case someone thinks its worth working towards a fix which can maintain the old feature.

This fixes all the cases which I could reproduce before with Spaces problems, with the exception that windows which are set to order above other windows do not switch spaces when dragged-and-held at the screen edge. This seems to be either a Spaces bug or intentional behavior. I've filed it as radr://5565888

Fixes #7862.

comment:20 Changed 13 years ago by Zachary West

(In [21400]) As per [21399], -setIgnoresExpose: no longer exists. Refs #7862.

comment:21 in reply to:  20 Changed 13 years ago by Evan Schoenberg

Replying to zacw:

(In [21400]) As per [21399], -setIgnoresExpose: no longer exists. Refs #7862.

Oops, thanks; since that file is in a dumb location, I missed it on my commit ;)

comment:22 Changed 13 years ago by Zachary West

<3 Spotlight.

comment:23 Changed 13 years ago by Zachary West

Should probably merge this to 1.1, hm?

comment:24 Changed 13 years ago by Evan Schoenberg

(In [21408]) Merged [21399] and [21400]: Disabled our hackery which was intended to let windows ignore expose, useful only when ordering below other windows and then revealing the desktop. This was causing intermittent problems with Spaces in 10.5 and simply isn't worth it IMO. I've left the code in place but commented out in case someone thinks its worth working towards a fix which can maintain the old feature.

This fixes all the cases which I could reproduce before with Spaces problems, with the exception that windows which are set to order above other windows do not switch spaces when dragged-and-held at the screen edge. This seems to be either a Spaces bug or intentional behavior. I've filed it as radr://5565888

Fixes #7862.

Note: See TracTickets for help on using tickets.