Opened 10 years ago

Last modified 10 years ago

#8789 new patch

Allow all window managers to handle conv window placement

Reported by: karvanitis Owned by: deryni
Milestone: Patches Needing Improvement Component: pidgin (gtk)
Version: 2.5.5 Keywords: conv window manager


Under Win32 pidgin attempts to handle window placement of conv windows by placing them at previously known locations.

An issue which occurs when placing the window manually is that newly created conv windows (such as when not using tabbed windows) get positioned directly over top any currently opened windows. This common scenario, which can be rather annoying, occurs while conversing with one buddy and then receiving a separate message from another.

This patch attempts to resolves such problems by allowing Windows to perform the window placement of all conv windows (as it is done on all other OS's).

Attachments (1)

gtk_window_placement.patch (4.5 KB) - added by karvanitis 10 years ago.
window placement patch

Download all attachments as: .zip

Change History (21)

Changed 10 years ago by karvanitis

window placement patch

comment:1 Changed 10 years ago by datallah

  • Milestone set to Patches Needing Improvement

I recognize that there is an issue related to opening several conversation windows at the same location, but I don't think that removing the ability to save and reuse the previous window location is the right way to fix it.

If Windows' "Window Manager" automatically placed the window at the previous location and then cascaded from there, this probably would be a good thing to do, but as it is, you're hurting the most common case (single tabbed window) to help a less common one (lots of windows).

comment:2 Changed 10 years ago by karvanitis

While I agree with your initial assessment, this patches behavior attempts to duplicate the behaviour which currently exists on Linux (with or without tabbbed windows). Tested on Ubuntu 8.10.

Newly created windows on Linux do not appear to retain their previous location and are always placed by the window manager regardless of tabbing or not. Now i may be wrong, and this may only be one of many window managers.

Having said that, what would one prefer the proper (as well as consistent) behaviour to be?

comment:3 Changed 10 years ago by karvanitis

After some further investigation (and testing of various other apps) here is how I believe this feature may be improved.

Restore the position of the previous conv window unless a conv window already exists in which case allow the window manager to perform the placement.

I believe this to be optimal in most cases, and modify the patch as such with some effort.

comment:4 Changed 10 years ago by deryni

That would certainly be an improvement over the current patch, but runs in to problems of which-window-wins for saving the next window location.

The core issue here is that Windows users (according to virtually all the reports I've ever seen) want the conversation window to always appear where they want/left it and have no way of having their environment do that (as the Windows window manager is not particularly configurable).

comment:5 Changed 10 years ago by karvanitis

I considered the issue with "which-window-wins" and the conclusion that I a came to, which is how the sample of Windows applications I tested performed, was to store the location of the last closed window.

The reason I believe that this technique works, is that it is the users actions (closing the window) which set the position for any upcoming window - therefor taking the logic away from the window manager and effectively giving it to the user.

Given this behaviour I would still consider it to be an improvement over the current implementation.

comment:6 Changed 10 years ago by deryni

Yes, but using the last closed window doesn't match what I was saying most people (again as far as I've seen/recall) requested.

I'm not arguing with the logic of your position, it is sound. I'm arguing that many Windows users seem not to want that sort of logical system.

comment:7 Changed 10 years ago by karvanitis

I see your point, but I'm having trouble trying to understand how a solution, which continues to place windows directly over top existing ones, can be better.

Let's note that the current pidgin implementation places conv windows where the last configured (sized, moved, stacked) window has been located. This does not always result in placing the window where the user left it.

I believe the solution I've proposed will attempt to do what your reports described, and open new windows where old ones have previously been left (ie: closed).

To take it simply as a use case, and not to belittle the work being done here, MSN Messenger behaves exactly as I have described - and there are many Windows users using that (for better or worse).

comment:8 Changed 10 years ago by deryni

Assume the user moves the window exactly once, to where they want it, and then never moves or resizes the window again.

Consistently placing new windows in that location means that for the rest of time windows will appear exactly where desired.

Cascading the new windows (or whatever placement policy the wm employs) will require constant moving of the new windows, remembering to always close the first window last, or always remembering to move the last window to be closed to the right location.

Assuming people are lazy and want the window to appear where they put it initially which of those is easier? (Again I agree with you completely that this is a stupid thing for pidgin to do, a stupid thing for pidgin to need to do, and a fallout of the entirely broken and pathetic window management environment that is Windows.)

I will say that I think we may be able to make the amended change you suggested because I imagine (or at least I hope) that most people use tabs and thus don't ever see this issue, but without some numbers to back that up (numbers we may hopefully actually be able to get sometime in the future) I'm not convinced this is going to help more people than it hurts.

comment:9 Changed 10 years ago by deryni

  • Owner set to deryni

comment:10 Changed 10 years ago by karvanitis

I have been using a patched version of pidgin with includes the intial patch I wrote for sometime now, and have to admit its not quite ideal either. I've been meaning to update the patch so that it complies with some of my more thorough concepts. I will do that soon.

I do not believe it is enough to simply assume that users are "want the window to appear where they put it initially". It is more important to presume that "users do not want the window to appear where they don't want it".

This is effectively the reason why my initial patch doesn't completely work, because it always allows the window manager to place new windows. Which throws me off when I expect my last closed window to reappear in the same location as where I closed it.

Given all this the updated patch I have been contemplating places brand new windows at the position of the last closed window (ie: where the use previously left it) and any subsequent windows are to be placed by the window manager. This is the most common implementation that I have found for our given scenario under Windows. And from a user interaction perspective makes the most sense.

We may not agree with the implementation of the given WM, but that should not be a excuse for behaving inappropriately. In most cases when it comes to UI it's best to stay within the capabilities of the given system than to stray away on your own - if nothing else but to keep up with the status quo.

comment:11 Changed 10 years ago by deryni

As I already indicated, the placement policy of "first window in saved location, successive windows placed by wm, save location of last closed window" fails if the user wants the placement of the first window to persist unless the user always closes that window last. This is a substantial window management burden.

The "first window saved, successive wm, save close location of first window" policy functions better for people who want consistent initial placement and fails for people who expect last-window-closed behaviour.

The current behaviour is, I readily grant, an awkward mix of those two policies.

I am not convinced which of the current or 'improved' behaviours is more natural for people on Windows. And as I said last time I'd love to have tabbed versus untabbed usage numbers to consider. But I think I'd be ok accepting a patch implementing the improved behaviour of "first saved, successive wm placed, last closed saves" and see what happens.

I know I, personally, very much dislike the multi-window last-saved-restoration policies in Firefox and IE and would much prefer being able to specify a location for the first window and let subsequent windows be placed (without affecting the saved location), but I have no idea if my usage is common or not (I'd wager not).

I would love nothing more than to remove all position and size remembering from pidgin entirely, but do not look forward to the lynch mobs that would come after me were I to do that.

comment:12 Changed 10 years ago by devros81

There are at least five tickets about this issue. There seem to be at least four viewpoints:

1) Some people would simply prefer that the window manager handle this. The usual response from these developers is, "Please switch to a better window manager."

2) Some people otherwise like their current window manager, but find it annoying to drag every new IM window down from the top left of the screen. (Compiz does this if no other small windows are open, which is usually the case for a person just web browsing and IMing.)

3) Some users would prefer that apps which open a lot of windows, like Pidgin, remember where they last put windows, just in case the window manager can't do it. (And to be fair, most WMs don't actually seem to do this well.)

4) Some users, like non-technical business users, simply don't have the option to switch to a different window manager or configure their current manager without consulting their company's sysadmin. (Similarly, casual users of, say, Ubuntu may not even know what a window manager is, let alone how to switch to a different one.)

This doesn't require a consistent policy. This is obviously a user preference. A simple checkbox preference would solve all of these problems, apart from the "code purity" issue.

Create a preference called "Allow the window manager to place new message windows" (on by default) or perhaps something like "Remember message window positions" (off by default). Obey the preference when placing new message windows. If two options aren't enough, offer a dropdown with three options. This doesn't need to be a religious war.

comment:13 Changed 10 years ago by deryni

The problem is the choice isn't that simple. "Don't ever remember window location" is simple, but for people with capable window managers the fact that pidgin remembers the location doesn't hurt anything anyway (since the window manager will just ignore what pidgin asks for and use what the user set up). The problem is how to handle the "remember window position" case when more than one window is in use. Do you remember the position of the first window created (even when it is moved)? Do you remember the position of the last window to be closed (regardless of what order it was opened in)? Do you let people set an "always remember this" position and never change that regardless of how the wm or user moves the windows? etc.

So having a remember/don't remember toggle isn't particularly useful (well except for the people who want normal wm placement without a set location, that is tile/cascade/etc. as appropriate for the current window situation) and as I've said before I'm not at all sure what behaviour most people expect (and whether that expectation is dependent on pidgin-external OS/environment/etc. choices).

I'd be more than happy to improve this situation for people using non-competent window managers but I'm not sure exactly what that entails.

Oh, one last thing, on non-Windows even if pidgin requests a window location the wm is free to ignore that and place it anyway (I eluded to this before but wanted to make it extra clear just in case).

comment:14 Changed 10 years ago by devros81

I just did some experimentation with an older Windows version of the official AIM client, which has DeadAIM installed.

When DeadAIM is set to use tabbed IMs, it remembers the location of the last window moved (not necessarily the last opened). Since tabs are being used, there's only ever one window and new IMs appear in that location. If the IM window is closed, new (tabbed) IMs appear in that same location.

Without tabbed browsing (when the AIM client has control over window opening), it appears that AIM remembers the last/current location of the most recently opened window, and cascades the next window down-right from there. This persists when the application is shut down.

Trillian, if I remember correctly, remembered the last location of every specific IM window, so that User1's IM would always appear at (x1,y1) and User2's IM would always appear at (x2,y2). I don't remember the placement of entirely new IMs. This was probably annoying once or twice, but overall I have good memories of using that program.

It would be interesting to see how people arrange/stack multiple IM windows during normal usage. I tend to arrange them in a staggered circular pattern (without thinking about it). Do you think that enough users would install a plugin for tracking this sort of "anonymous usage information" to obtain meaningful data?

I can see benefits to all three of the above ways of tracking window placement. These are the kind of options I think would highly benefit and entice casual users.

comment:15 Changed 10 years ago by deryni

We have been talking about a general preference instrumentation plugin for a while now as something we really need to have (I know some work was done on it but I don't know how far it got or what the status of it is now).

Right, if you limit to a single window the policy choices collapse to "remember position" or "don't remember position" and that's easy enough to let users pick between, unfortunately that's not all pidgin has to support.

With no tab support it is possible to remember per-user window locations, with tab support that is based on some static attributes you can do this as well (tabbed by buddy list group, tabbed by account, etc.). That doesn't really work for generic tabbing though so you are left with the various options for which window you remember position/size from/for.

As I indicated there is merit to remembering based on the first created window, based on the last closed/moved/sized window, based on a specific window, based on manually specified settings, etc. the problem is that it is rather difficult to meaningfully support all those options (and likely even harder to make it apparent to users what the differences between them all are.

I would be happy to accept a patch which made conversation window placement manageable via plugins but I don't know how many plugins will actually do this as the possible placement options and window creation scenarios are many.

I think casual users are exactly the sort of people *least* likely to have any desire to even begin to understand the various choices you (and I) have presented here and are *much* more likely to be happy with whatever default policy is chosen (and will get used to whatever its quirks are).

comment:16 Changed 10 years ago by devros81

I tested a few more Windows IM clients this morning, and it appears that they mostly use the "track the last-changed still-open window and cascade from there" approach. If all windows are closed, the first new window usually opens in the last-closed-window's position, rather than cascading

Having never coded for this project before, I don't know what it would take to create a plugin interface for window location control. I could certainly take a look at it and submit a patch. I would also implement at least one plugin (providing the remember-cascade behavior) using the new interface.

The plugin interface would need to report "window opening/opened/size/move/closing/closed" events, and at least be able to receive a screen coordinate from a plugin implementing the "before opening a new window" event. Anything else you can think of off the top of your head?

comment:17 Changed 10 years ago by karvanitis

The cascading effect you are experiencing is the Windows window manager placing the new window for you. If you look through my patch there is a change in there that allows for this in Pidgin.

As discussed in previous posts, the expected behaviour is to place the first opened window at the location of the last closed window and thereafter allow subsequent windows to be placed by the window manager. This is effectively how almost all IM clients (and multi-window applications) on Windows behave.

Pidgin does not need to do anything special here, other than fix the current behaviour which is clearly broken.

I do not see the need for a plugin for such a fundamentally broken design of Pidgin. To the same effect I do not see the need for a preference. Pidgin should simply behave expectedly out of the box. The right thing to do here is to allow the window manager to place subsequently opened windows. If people have a problem with that, then they need to change their window manager, not their IM client.

comment:18 Changed 10 years ago by deryni

Your patch doesn't "allow for th[at] in Pidgin" it removes pidgin's ability to place windows entirely, that's not quite the same thing (nor is it place-first-cascade-subsequent, which is what was being discussed).

As I've said more than once that is *one* possible desire and by no means am I convinced it is the main one, nor is it what your patch does (as I indicated above).

I would be perfectly happy to remove all size/location remembering code from pidgin entirely but that would negatively affect an enormous percentage of pidgin users.

I'm not at all convinced that IE, firefox, or opera behave anywhere near that simply in terms of remembering window positions (at least not given my experience with multiple monitors at work). I don't know what other programs do or do not do.

I actually wonder how the cascading works with an initially placed window, I actually think the application probably has to do that itself since I can't see how Windows would handle that correctly automatically, but I'd love for someone who actually knows to comment on that.

If it was possible for pidgin to place the initial window and then let Windows do the rest I would accept a patch which tested for the existence of another conversation window before placing the new window. I'm not at all certain I'd accept a patch which implements manual cascading.

You've also managed to avoid considering any of the non-placement points under discussion, that is the points about which windows position and size to save for the next placement. Which is, in reality, where this gets most complicated anyway.

I fully admit that if placing the initial window is all that is necessary to trigger Windows to do the right thing with subsequent window placement that allowing that to happen is almost certainly better than what we have now, but I'm not convinced that is the case, nor am I convinced that everyone will want that (hence the plugin-able action discussion).

comment:19 Changed 10 years ago by karvanitis

I agree that the initial patch, and we already discussed this, was incomplete. The fix in the patch I was referring to was only to do with allowing the Windows window manager to place the window for you.

I did not avoid anything, I was rather clear in stating that the last known position is that of the last closed window. I don't see how this is complicated. If cascading were to take effect at all that would be handled by the window manager, and by no means should pidgin perform this.

I dont know what you want to be convinced but as far as I know this is how Windows behaves, try it for yourself. To consider that not everyone would want improved behaviour is ridiculous given the current implementation of placing consecutive windows directly over top existing ones.

comment:20 Changed 10 years ago by deryni

I refute your assertion that no one could possible want all their conversation windows placed in the same location, it is clear that such a desire could be had, as such your assertion that cascading is by-definition "improved behaviour" is simply incorrect. That being said I have admitted that I think leaving Windows to do its job (assuming that job is to cascade subsequent windows from the location of a first window) is a good thing and one that I would accept a patch for (once again assuming it was made clear that that is in fact what Windows will do).

You did in fact specify last-closed positioning, I missed it, I apologize for that. However, I think your comfort in assuming that is what everything does and what everyone wants is greater than mine. I don't use any applications at the moment with which I routinely use multiple windows and so am not in a good position to determine exact behaviour but I do know that on more than one occasion I have been unable to get IE to use the location I wanted it to use despite closing the last window in that location (eventually it would take, I have no idea why), so my confidence is not particularly high.

As I said, a patch implementing place-only-the-first-window is something I would accept were I to be convinced (or shown) that Windows will correctly cascade (from that location) any subsequently created Windows. I would accept it even given that I think there are legitimate reasons to want Windows to all be placed in the same location mostly because I think placement shouldn't be up to the application basically at all and the closer I can get pidgin to that the better.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!