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

[Pidgin]

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

  * keywords:  => autoparent
  * owner:  datallah => deryni
  * component:  winpidgin (gtk) => pidgin (gtk)


Comment:

 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.

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