Opened 10 years ago

Last modified 10 years ago

#7693 new defect

Always on top buddy list hides child dialogs

Reported by: Daniel Beardsmore Owned by: deryni
Milestone: Component: pidgin (gtk)
Version: 2.5.2 Keywords: autoparent
Cc: anoftc, Dawudd


When the Windows Pidgin Options plugin setting Keep Buddy List window always on top == Always, child dialogs of the buddy list do not inherit the always-on-top status.

Normally this is not obvious in my case, as I have a large monitor and keep the blist on the RHS of the screen; child windows normally open in the middle of the screen or on the left.

However, the New Instant Message... dialog always opens centred on the blist, which causes it to appear behind the window. For a while, I thought that a subsystem of Pidgin had frozen, as I wasn't able to get this dialog to open at all (and being a dialog, it is not listed in alt-tab) but eventually I found where it was going to!

Another window that has the centre-above-parent (aka centre-behind-parent) behaviour is About.

I'm using 2.5.2 with the Pidgin's GTK 2.12.12, in Win XP SP3. (No more Win2k for me)

Change History (30)

comment:1 Changed 10 years ago by datallah

  • Status changed from new to pending

I suspect this will have changed somewhat in GTK+ 2.14.6 (perhaps not for the better). Please test.

comment:2 Changed 10 years ago by anoftc

No change. If I enable "keep buddy list window on top - always", then the buddy list window stays on top, but the conversation window and the debug window does not.

However, one thing changed in the "always on top" field since the upgrade to 2.5.4 ... I have "keep buddy list window on top" is "never". So, buddy window is not on top. BUT, if I have the debug window or the file transfer window opened, then they are ALWAYS above the conversation window and the buddy list.

So, even if I click on the conversation window, the file transfer is hiding out part of the conversation window, even with the focus being on the conversation window...

Just saw, its the same with the about window as well - about window stays on top of the buddy list/conversation window, even if the buddy list has the focus...

Winpidgin 2.5.4, xp sp2

Bye Zs

comment:3 follow-up: Changed 10 years ago by deryni

That is likely to be Windows keeping transient children and dialogs above their parents/main windows and not something pidgin can do anything about directly (not without changing the type of those windows).

comment:4 Changed 10 years ago by anoftc

In last version (i used 2.5.1 before this one), file transfer and debug window were not like this. They were the same as the conversation window/buddy list: the one that was active was on top. Now file transfer and debug windows are always on top of other windows. So something must've changed (new gtk, i guess?) ... could this be reverted to the old behaviour?

comment:5 Changed 10 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:6 Changed 10 years ago by anoftc

could this bug be re-opened?? it is a strange thing that a bug where there are no comments goes into "closed" state after two weeks. This means that if a developer says nothing to a bug for two weeks then the bug is solved?!

comment:7 Changed 10 years ago by Daniel Beardsmore

Well, it got sillier recently. Submenus now cause the parent menu to vanish. For example, open the Buddies menu, and move the cursor over Show. The Show submenu appears and the Buddies menu disappears. Not sure when it started doing it, but obviously that's a GTK+ bug.

comment:8 Changed 10 years ago by datallah

  • Status changed from closed to new

The ticket will be closed if there is no activity in two weeks while it is pending status (it doesn't matter who says something).

The pending status will only be removed if the reporter replies in that period.

There is no point keeping stuff open that we're waiting for information on indefinitely.

comment:9 in reply to: ↑ 3 Changed 10 years ago by Daniel Beardsmore

Replying to deryni:

That is likely to be Windows keeping transient children and dialogs above their parents/main windows and not something pidgin can do anything about directly (not without changing the type of those windows).

Well, one would assume that when an always-on-top window opens another, the new window has to be set as always-on-top also. Generally, in Windows, always-on-top applications will set all windows to the same state, e.g. Winamp with its multiple windows.

The problem with Pidgin having an always-on-top buddy list is two-fold. Firstly, it does not use modal dialog boxes when by Windows convention it should, so dialog windows are not automatically kept in front (at least, one hopes that Windows would at least deign to do that to dialogs?)

Also, windows that are spawned can get placed behind the parent. This is probably due to a window management fault on the part of Windows, given that Windows is supremely stupid about window placement. Pidgin centering dialogs on the parent is perfectly sensible (Windows would just dump them in the middle of the screen) but that's awkward if they're not actually modal windows that block their parent.

comment:10 Changed 10 years ago by deryni

*Dialogs* modal-to or parented-to an always-on-top window should be always-on-top, whether that is the job of the widgeting toolkit or the windowing environment is not somehintg I have an opinion on at the moment (though I think I would lean to putting the onus on the windowing environment, since it would be perfectly reasonable not to require dialogs to stay in front of their parents). All other windows spawned from that window should act as whatever type of window they are.

Which dialog boxes in pidgin do you think should be modal which aren't?

pidgin avoids modal dialogs when the dialog interaction really shouldn't prevent interaction with the rest of pidgin, most applications horribly overuse and abuse modal dialogs. That being said, yes I would hope that Windows would automatically keep dialogs above their parents whether they are modal or not (and in fact Windows does seem to do this, see the New Instant Message dialog as an example, it is non-modal and is kept on top of the buddy list at least when the buddy list is not set to always-on-top). That it doesn't work when the buddy list is set to always-on-top indicates that something in pidgin is broken/suboptimal (unlikely), something in GTK+ is broken/suboptimal (more likely), or that GTK+ and Windows disagree on whose job it is to handle this case (most likely).

Normal windows spawning behind other normal windows is a perfectly fine window management decision, on Windows it just happens to not be one I think they ever intentionally choose so the fact that it happens is likely a bug.

pidgin doesn't, to the best of my knowledge, center dialog boxes itself (that is I bleieve this is something that either GTK+ or Windows is doing for us).

Can we get a clarification of what issue (exactly) this ticket is reporting? There have been a number of related discussions and I'm not at all sure what the complaint is at this point.

comment:11 Changed 10 years ago by Daniel Beardsmore

OK, steps:

Use the Windows Pidgin Options plugin to set 'Keep Buddy List window always on top' to 'Always'.

Now go to the Buddy List window and select Buddies > New Instant Message. The dialog is centred on the parent but stacked behind it and almost inaccessible (fortunately it comes out slightly wider and I can resize it out from underneath). Other windows from other applications will cover it over (as it behaves as a regular window, which is wrong), but clicking into the Buddy List window will bring the dialog to the front, but still behind the Buddy List window.

The same applies to Help > About, Buddies > View User Log etc.

Also, open Buddies > Show: the Buddies menu disappears as the Show submenu opens.

In Windows, dialogs are only modal to their parent. The New Instant Message dialog would be modal but only to the Buddy List window. It would not obstruct any conversation windows, Preferences, Plugins etc. Instead, it is functioning as a regular document window.

comment:12 follow-up: Changed 10 years ago by deryni

The Add Buddy dialog has no reason to be modal to any windows, and as such is not. It is set to have the buddy list window as its parent though. So the question is who is responsible for keeping it above the buddy list window, I maintain that it should be the job of Windows to do that, it would appear that Windows disagrees.

Modality is generally to an entire application, I cant't at the moment think of any dialogs that are modal only to a single window at the moment (though I certainly imagine there are some).

The real issue here is that the Add Buddy dialog is being set to be a "transient child" of the buddy list window, it shouldn't be. Were it not, Windows would place it as a normal window and this problem would be mitigated down to the level of 'normal' windows interacting with an always-on-top window.

Displaying the Show menu does not cause the Buddies menu to disappear for me.

comment:13 in reply to: ↑ 12 Changed 10 years ago by Daniel Beardsmore

Modality is generally to an entire application, I cant't at the moment think of any dialogs that are modal only to a single window at the moment (though I certainly imagine there are some).

That is a common and bizarre misconception. Window-modality awareness was increased by sheets in OS X, but dialogs in Windows were already window modal. Open two Firefox, Windows Explorer or Internet Explorer windows and open a dialog box in one of the windows -- the dialog does not block any other windows of that application. The prevalence of SDI in Windows though will skew perception: there is very little on my PC that uses more than one top-level window per process.

Outlook dialogs are also window modal, but the program deliberately and extremely obnoxiously forces the dialog back in your face on purpose if you try switching to another window; there is absolutely no cause for this. Outlook Express also pretends to have application-modal dialog boxes for no reason (also incredibly irritating). There is no shortage in Windows of extremely badly implemented applications: not just Outlook but the whole of Office and Adobe Reader do a terrible job of windowing, for which I can find no excuse. After all, Windows Explorer has no problems doing it right. (Explorer also keeps running happily when a single window freezes solid!)

comment:14 Changed 10 years ago by deryni

I was speaking of modality in general not specific to Windows. Modality certainly can work in both ways.

I don't recall Explorer having window modal dialogs (but as I'm not in front of Windows at the moment I can't check my memory), and in my experience the only time Explorer (the file view part) continues when one window is frozen is when the user has chosen to run them in separate processes, a setting which last I recall (as of XP at least) was not the default.

Note that there is a difference between saying that a single thread of a given Explorer window has frozen and saying that the window itself has frozen.

I am rapidly approaching the very limits of my understandings of the inner workings of Windows and as this branch of the conversation is not particularly useful in resolving this ticket I would like to suggest that it be dropped and we move back to determining what *exactly* is the issue being discussed here and what (if anything) pidgin can do to fix it.

I have already commented that I believe the parenting the Add Buddy (and friend) dialogs to the Buddy List window (in reality whichever window happens to have the toplevel focus, not that that can currently be any other window) is a mistake and is something that should be fixed and I fully intend to do that.

Is there anything else at issue here?

comment:15 Changed 10 years ago by Daniel Beardsmore

As far as I am concerned, it's not possible to seriously address graphical interface issues without genuinely understanding the GUI in question. I don't know why we even need a debate, unless this bug is local to my PC -- is it? As long as it's reproducible, that should be all you need to know from me.

comment:16 Changed 10 years ago by deryni

  • Status changed from new to pending

The issue is that I don't know *what bug we are discussing* anymore. Because, as I've said, if the issue is that Windows (per window management policy) requires that applications manually set dialogs parented to windows that are set to be always-on-top to be always-on-top themselves, then I find that a particularly poor policy decision and *in this specific case* one that I intend to work around by removing the code in pidgin which parents the dialogs in question to the buddy list window. That code was added to make using pidgin easier on devices like the Nokia tablets and has caused only problems for desktop users.

Removing this code will mean that Windows default window placement policy will be in effect for these dialogs and thus we will remove the placement component of this issue entirely. And as I have been given no reason to believe these dialogs should be modal to the buddy list window they will thusly have no reason to be set as always-on-top anymore.

comment:17 Changed 10 years ago by Daniel Beardsmore

  • Status changed from pending to new

I shall bow to your infinitely superior knowledge on the matter.

comment:18 Changed 10 years ago by deryni

  • Status changed from new to pending

That wasn't my intent at all, I really just don't know if there is a further issue here. Assuming the dialogs in question cease being parented to the buddy list and as such are positioned as normal windows, is there still an issue?

comment:19 Changed 10 years ago by Daniel Beardsmore

  • Status changed from pending to new

Working with Windows is not easy. Deciding whose flow to go with is always hard. I noticed the other day that in Outlook 2003, the mouse wheel scrolls the pane under the cursor instead of the one with the focus. That's not Microsoft's way, but even someone at Redmond had the good sense to do mousewheel scrolling properly for once.

Personally I'd simply have dialog boxes like New Conversation and Add Buddy simply be bog standard modal dialog boxes with the buddy list as the parent. As long as Windows isn't really stupid, it should fix the z-order problem and make the dialog boxes behave as you'd expect in Windows.

Everything you've said so far indicates a disturbing lack of experience with Windows, which raises a red flag for me. The aim of a developer should always be to stick with the native platform behaviour unless there's a very good reason for not doing so. For example, I consider Microsoft's mouse wheel behaviour to be so absurd, that I am glad that many third-party developers have gone with the Linux/OS X behaviour instead. However, for more ambivalent cases it's best to simply do what Microsoft do, and let all your applications look, work and behave the same. Saves a lot of wasted effort tracking independent behavioural models. (What's with all the applications that don't stick to Tools > Options ... ?)

That said, letting a dialog box get positioned by the OS won't be a disaster. The down side is that Microsoft have a fetish for displaying dialogs nowhere near the mouse cursor, which gets worse as monitors get larger (and worse still if it ends up on the wrong monitor entirely). Personally, I'd centre the dialog over the parent window -- keeps Fitt happy -- but that would then mess up where the dialog box is intentionally obscured by its parent.

Just using regular modal dialogs -- but keeping the current window positioning -- should solve the problem in a simple and straightforward way.

comment:20 Changed 10 years ago by deryni

  • Component changed from winpidgin (gtk) to pidgin (gtk)
  • Keywords autoparent added
  • Owner changed from datallah to deryni

To paraphrase many people smarter than myself:

Some people, when confronted with a problem, think "I know, I'll use a modal dialog." Now they have two problems.

Abusing modal dialogs because you like how the window manager handles them better than how it handles normal windows isn't solving a problem, it is introducing a new one. Namely that modal dialogs tend to suck and annoy people, especially when the action being forced upon you is in no way important enough to require immediate attention. So suggesting that we "solve" the Z-order placement issue by making the "New Conversation" and "Add Buddy" dialogs modal is (as I've said a number of times now) not something I think is useful or a good idea.

I can't help the fact that you seem to think I don't know Windows, I'll grant you that I prefer other operating systems and use them when at all possible and that the majority of my development and "deep" understanding lives on the X side of things but I do use Windows every day at work and have been slowly coming to understand slightly more about how the window management works internally (a say slightly because I haven't seen anywhere near the discussion or resources about the management model on Windows as I've seen on Linux, though I will admit to there likely being a confirmation bias at work here).

I fail to see what I have said which indicates that my knowledge of Windows is so severely lacking as to be problematic nor what I have said to indicate that I don't have an understanding of window management concepts sufficient enough to understand the way Windows works when presented with that information.

Given the way Windows handles focus I think the decision to scroll the focused widget is entirely reasonable albeit rather annoying to anyone who has ever use a non-click-focus driven system.

I agree that sticking to environmental conventions is a good idea in general and as a rule pidgin does that, I fail to see how that applies to this case however. Unless of course your point was that in Windows "Dialogs Are Modal" in which case I will stand by my right not to punish users like that unnecessarily.

Windows-only applications have little excuse to buck convention, multi-OS applications have a much greater reason, especially applications (like pidgin) which consider Windows a second-tier platform in terms of target.

Centering the dialog over the parent window is a weak way to appease Fitts, since there is no guarantee that the center of the parent window is going to be anywhere near the current mouse location (consider that some people run with the buddy list maximized).

The fact that Windows can't be trusted to handle dialogs in a way that makes them usable when not tightly tied to parent windows (and, apparently, in cases where the parent is always-on-top specifically made modal to those parents) is not something I feel the need to work around.

Seeing as how I have not seen any indication that there are further issues here other than the fact that Windows cannot sanely place dialogs parented to always-on-top windows I will close this ticket when I remove the auto-parenting code that is responsible for this problem.

comment:21 Changed 10 years ago by apidginuser

I am not too sure as to the status of this issue. I experience this behavior with a WinXP system but not on a WinVista? system. The file transfer window will stay on top of message window in XP, but is willing to go behind in Vista.

comment:22 Changed 10 years ago by apidginuser

I have updated to version 2.5.5 and still get other Pidgin windows covering my conversation window in Windows XP, while in Windows Vista, Pidgin version 2.4.3 does not have this problem.

comment:23 follow-up: Changed 10 years ago by deryni

  • Status changed from new to pending

apidginuser: As I said, this issue is a window management one. The fact that it works in Vista and not in XP illustrates that fact. You indicate that 2.4.3 on Vista doesn't have this problem, does 2.5.5? I'm going to bet it doesn't. (Sorry for the delay in responding.) And I think you are talking about a different issue than what this ticket is discussing, your issue sounds like #9060 or #6054.

Daniel Beardsmore: Looking over this ticket again, the issue still appears to me to be that Windows seems to require that windows/dialogs parented to windows that are set to be always-on-top must also have the always-on-top value set for them, is that correct? Does that match up with your understanding of things? I haven't looked at the GTK+ code in question but (as far as I know) pidgin just asks GTK+ to create a dialog window for it (and then automagically parents it to the buddy list, thus causing the centering). It is still my intention to kill the autoparenting entirely, which should help mitigate the original problem, but possibly not solve it.

comment:24 in reply to: ↑ 23 Changed 10 years ago by Daniel Beardsmore

  • Status changed from pending to new

Replying to deryni:

Daniel Beardsmore: Looking over this ticket again, the issue still appears to me to be that Windows seems to require that windows/dialogs parented to windows that are set to be always-on-top must also have the always-on-top value set for them, is that correct?

I've reinstalled Winspector Spy, and yes, this appears to be true, seemingly as a hint to the "window manager" (MS doesn't do inheritance). For dialog boxes, however, Windows appears to take care of this for you. I have a toy that lets me make any window or dialog box be always-on-top. If I set any window or dialog to WS_EX_TOPMOST, then any dialog boxes it opens are assigned WS_EX_TOPMOST automatically, including common dialogs and grandchild dialogs. I've tested this in several programs.

GTK+ appears to create regular windows even for dialog boxes. For example, the File Transfers window is created to look like a resizable dialog, but still fails to inherit WS_EX_TOPLEVEL, by not making the window be a genuine dialog box (AFAIK dialogs in Windows can only be created by CreateDialog? -- CreateWindow? using DS_MODALFRAME just fails; CreateDialog? is special, and may include statically inheriting z-order flags).

comment:25 Changed 10 years ago by Daniel Beardsmore

grr, WS_EX_TOPMOST. "Top Level" is something else :)

comment:26 Changed 10 years ago by deryni

Something is definitely odd with how the file transfers and plugins windows work, if you have them both open focusing the buddy list will raise them above occluding windows from other applications, focusing either of them will not raise the buddy list and will actually raise the other of them above the window you selected (if they are overlapping). I don't see anything obvious in Winspector to explain that, but I may just not be familiar enough with it/Windows to know what to look at/for.

I'm unsure why GTK+ doesn't appear to use actual dialog windows, but that's an issue better taken up with them.

Given that the file transfer window and plugin windows aren't actually set transient to the buddy list, I'm still not convinced they should be made always on top, but things like the (current) about dialog and the add buddy dialog likely should (since they are set transient to the buddy list, or at least set to center on it).

comment:27 follow-up: Changed 10 years ago by Daniel Beardsmore

IMO, the file transfer window should be a regular window, with minimize and maximize. (And appear on the tray icon menu ;) The log viewer window also lacks these. (Didn't I have another bug for this?)

Plugins and Preferences follow the Macintosh model of settings windows with no cancel and no undo (if you mess up, oh dear...) and in this model, they're regular windows that you can leave open while you experiment with the result of your changes. Minimise wouldn't go amiss, though! Making these always on top doesn't seem necessary.

However, what I feel would just be best as regular, modal dialogs are things like New Instant Message, Join a Chat, Get User Info etc. They're very short-lived, just open, type/paste, then OK/cancel. However, removing auto-parenting would also work.

comment:28 in reply to: ↑ 27 Changed 10 years ago by anoftc

Replying to Daniel Beardsmore:

IMO, the file transfer window should be a regular window, with minimize and maximize.

Yes, yes, YES! :)

I've been wanting this for 4 months, and all the replies was about a gtk bug and a windows thing...

Couldn't just the window type be changed? that'd solve everything...

Pleeease :)

Bye, Zs

comment:29 Changed 10 years ago by anoftc

hm, a new bug that has connection with this one...

comment:30 Changed 10 years ago by deryni

Yes, I've become convinced that the File Transfer window is not a dialog and that our creating it as such is incorrect and should be fixed.

I'm not yet convinced about the Log Viewer, though I am getting there as well.

Ideally pidgin wouldn't need to deal with making anything always on top itself, GTK+ and Windows would collaborate to have that happen automatically. The problem is that GTK+ is doing things in such a way as to make Windows unable to do that.

pidgin isn't making the decision about whether or not to have a minimize button on the windows/dialogs in question, GTK+ is (well pidgin is choosing to make them dialogs not normal windows, but beyond that decision GTK+ is handling the details). I'm not even sure there is anything pidgin can do about that.

I hate modal dialogs, especially when they are uselessly modal as would be any of the dialogs you suggested. None of those dialogs are workflow obstructing in any way, nor should they be.

anoftc: It would have helped if you had actually stated that was all you wanted at some point. We could have been having that discussion than, instead we had the very useful (but somewhat unrelated) discussion about window management issues. Which discussion did bring up the interesting discovery that GTK+ doesn't seem to actually use native Windows dialogs at all.

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!