[Pidgin] #6268: Menus are enabled or visible even when they have no functional purpose

Pidgin trac at pidgin.im
Tue Jul 8 17:41:07 EDT 2008


#6268: Menus are enabled or visible even when they have no functional purpose
-----------------------+----------------------------------------------------
  Reporter:  foxmajik  |       Owner:  deryni
      Type:  defect    |      Status:  new   
  Priority:  minor     |   Milestone:        
 Component:  XMPP      |     Version:  2.4.3 
Resolution:            |    Keywords:        
   Pending:  0         |  
-----------------------+----------------------------------------------------
Comment (by deryni):

 I could have stuck with suture kits, but tacked on bandages to make the
 case clearer. I apologize if my attempt at clarity offended your doctor-ly
 leanings. Nonetheless my argument stands, the issue is one of mode of
 presentation (and cost of divestment) as well as an issue of learning
 about available options.

 The conversation window is not the buddy list. Claiming that because a
 menu exists in one it must exist in the other is taking consistency to
 ludicrous levels (and while I appreciate the rhetoric value inherent in
 such tactics I would appreciate them being left out of this discussion in
 the future). The context issue is nowhere near that large. The
 conversation window *is* the same between IM tabs and chatroom tabs. Tabs
 for both can even exist in the *same window* so claiming they don't share
 a context is a stretch.

 I will admit that the Send To menu being displayed for chat rooms is, by a
 wide margin, the strongest of the claims you made and the claim my defense
 is weakest against. This is largely because (for most people) the
 difference between an one-on-one IM and a chatroom is pronounced. (It is
 worth noting that for people who come from MSN that difference is
 vanishingly small, as MSN allowed you to freely morph one into the other.)

 My claim about the Send To menu (which I'm assuming is the main thing you
 are now arguing against because I fail to see how your defense works on
 the other items you initially indicated) is that the "context" for the
 menu bar is firstly "conversation window" and only secondly "active tab"
 and as such the Send To menu should continue to exist even in chat rooms.
 I will grant that if the "Separate IM and Chat Windows" placement
 preference were being used that there would be (a mostly valid) reason to
 hide the Send To menu from the "chat" window (it would need to return if
 an IM window were manually dragged into that window however, for
 contextual consistency).

 To bring in a small bit of technical argument, not requiring a continual
 cycle of hide/display/hide/display when switching between chat and IM tabs
 in a given window has efficiency merits. This is by no means an important
 point but is something that has a small amount of weight in deciding
 between roughly equivalent options.

 To be clear about the non-Send To items. Your Conversation->More menu is
 empty because you don't have any plugins loaded that supply you with
 actions on your chat room, mine is not. The Conversation->Insert Image is
 disabled because that feature is *currently* not supported for the chat
 rooms on that protocol (but might be on other protocols) and at some
 future point may even be supported on that protocol in which case the item
 will cease being disabled.

 I would also like to point out that you seemingly ignored my points about
 menu location learning and the ability to see what options are possible in
 other similar contexts.

 Do you have further reasons that you believe the Send To menu should not
 be visible in chat rooms? Can you explain, without resorting to an analogy
 (that we have both made bad attempts at creating), why you believe it
 better to remove a menu item entirely rather than simply disabling it? Can
 you explain how removing them doesn't hurt learning the location of menu
 items or the ability to learn where the items for features you haven't
 needed to use yet live (so that you can find them more quickly in the
 future when you do need them)?

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


More information about the Tracker mailing list