Adium

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#4451 closed defect (fixed)

Message Window not saving location when closed.

Reported by: adium Owned by: evands
Milestone: Adium X 1.0.3 Component: Adium UI
Version: Severity: normal
Keywords: messagewindow ui messages message Cc: cameron@…
Patch Status:

Description

When I close a message window, when ever I recieve a new IM or open a new window to IM someone, the message window continues to move downward and to the right, until it hits the edge of the screen, then moves to the far left and begins again. Seems to think that with each subsequent open/close of said window, it hasn't closed, so not to hide the previous window, it files down a bit.

Basically, it does not save window position on close. This is a bug with 1.0b1

The images attached should make sense.

Change History (19)

comment:1 in reply to:  description Changed 14 years ago by adium

Okay, so it's bitching to me about upload size. I've uploaded the images here:

http://images.desk003.com/adium1b1bug/

comment:2 in reply to:  description Changed 14 years ago by adium

I am experiencing this as well, with 1.0b3

When opening new windows on my own, they continue to cascade as with new IMs, no matter where I move the window to. Moving the window to a specific spot and restarting the application will set the initial window position to that spot, however.

The window position does seem to follow that of a "new window atop current window" model, as if it is actually using the cascading mechanism, although certainly there are no other windows present.

comment:3 Changed 14 years ago by adium

Still having this in 1.0b4, fyi. :)

comment:4 Changed 14 years ago by anonymous

Still there in b7....does anyone read these?

comment:5 Changed 14 years ago by Eric Richie

priority: highnormal
Severity: majornormal

yes we do, but you have to remember that we are all volunteers and we currently have over 800 new tickets to sift through, so please just be patient, we'll get to it when we can

comment:6 Changed 14 years ago by desk003

Just wanted to point out that the last 'adium' wasn't the submitter. :)

comment:7 Changed 13 years ago by tickswifey

Milestone: Adium 1.0 - After beta 1Adium X 1.0

comment:8 Changed 13 years ago by desk003

This seems to have gone away, at least for me, in 1.0b7.

comment:9 Changed 13 years ago by Eric Richie

Resolution: worksforme
Status: newclosed

The user has reported this as resolved in beta7. I have also not been able to replicate the issue. If anyone else is still seeing this please provide us with specific information about the issue if you reopen the ticket.

comment:10 in reply to:  9 Changed 13 years ago by adium@…

Resolution: worksforme
Status: closedreopened

This is still occurring for me, in 1.0b7, with dual displays. Simply put, if I open a message window, then close it and open a new one, the window position moves. I have one spot I like to put it in, but this is not remembered. Not sure what other info is needed...

Replying to edr1084:

The user has reported this as resolved in beta7. I have also not been able to replicate the issue. If anyone else is still seeing this please provide us with specific information about the issue if you reopen the ticket.

comment:11 Changed 13 years ago by Chris Forsythe

Milestone: Adium X 1.0Adium X 1.0.1

comment:12 Changed 13 years ago by Chris Forsythe

Milestone: Adium X 1.0.1Sometime after 1.0

comment:13 Changed 13 years ago by Ari

This happens for me when I have "Create new chats in tabs" turned off, in the latest subversion 'trunk' code. With that preference turned on, Adium remembers where the window was. Oddly, it remembers the last place a window came up with the preference turned off, as long as the preference is turned on when the window is closed. So, below, sequence A will trigger this bug and save the wrong position of the window while sequence B will just open it in the wrong position.

A:

  1. Turn off "Create new chats in tabs" preference
  2. Open a conversation window by double-clicking a contact - it will appear somewhere on the screen according to a cascade pattern
  3. Turn on "Create new chats in tabs" preference
  4. Close the conversation window
  5. Open a new one, it will be where the one closed in (4) was

B:

  1. Turn off "Create new chats in tabs" preference
  2. Open a conversation window - it will appear in the cascade pattern
  3. Close the conversation window window
  4. Turn on "Create new chats in tabs" preference
  5. Open a new conversation window, it will be where the last one closed before you did step (1) had been

This is a regression, although I can't say how recent. It definitely works right in whatever 1.0 version I have running on my PowerBook, where "works right" means that each contact has a window size and position remembered when the "Create new chats in tabs" preference is turned off.

This appears related to #5055 (which applies a fix to tabbed windows) but I can't find a ticket relating to non-tabbed windows.

comment:14 Changed 13 years ago by Evan Schoenberg

Patch Status: None

#5055 appears unrelated - did you mean a different ticket?

comment:15 Changed 13 years ago by Evan Schoenberg

Owner: changed from nobody to Evan Schoenberg
Status: reopenednew

:D It's not that it's different code on your powerbook -- it's that your powerbook has a stored preferences that much the horribly outdated code in use in AIMessageWindowController. This is why class interdependencies -- especially undocumented ones -- are bad bad bad!

AIMessageWindowController checks to see if there's a saved frame, based only on its own identifier for the frame name, for a window, and decides whether to cascade based on that. AIWindowController, its superclass, is responsible for saving that data when the window closes... but it (as of 1.0) saves in a window configuration dependent manner, not just based on the identifier supplied by AIMessageWindowController.

comment:16 Changed 13 years ago by Evan Schoenberg

Milestone: Good idea for "later"Adium X 1.0.3
Status: newassigned

comment:17 Changed 13 years ago by Evan Schoenberg

(In [19553]) Fixed determination of whether a message window should cascade when 'open new chats in tabs' is disabled. See #4451 for details. Fixes #4451.

comment:18 Changed 13 years ago by Juan Manuel Palacios

Resolution: fixed
Status: assignedclosed

Trac hook didn't seem to have caught r19553's request to close the ticket, so closing manually (per Evan's commit message).

-jmpp

comment:19 Changed 13 years ago by Evan Schoenberg

(In [19556]) Merged [19553]: Fixed determination of whether a message window should cascade when 'open new chats in tabs' is disabled. See #4451 for details. Fixes #4451.

Note: See TracTickets for help on using tickets.