[Pidgin] #7693: Always on top buddy list hides child dialogs

[Pidgin]

#7693: Always on top buddy list hides child dialogs
-------------------------------+--------------------------------------------
 Reporter:  Daniel Beardsmore  |           Owner:  datallah       
     Type:  defect             |          Status:  pending        
Milestone:                     |       Component:  winpidgin (gtk)
  Version:  2.5.2              |      Resolution:                 
 Keywords:                     |   Launchpad_bug:                 
-------------------------------+--------------------------------------------
Changes (by Daniel Beardsmore):

  * status:  pending => new


Comment:

 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.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/7693#comment:19>
Pidgin <http://pidgin.im>
Pidgin