• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-1825
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Unassigned
Reporter: Nicholaz Beresford
Votes: 14
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Change Request: Change double click action for various inventory items

Created: 20/Jul/07 12:38 AM   Updated: 22/Jul/09 03:15 PM
Return to search
Component/s: User Interface
Affects Version/s: None
Fix Version/s: None

File Attachments: 1. File slviewer-v11843-InventoryDoubleClickActions_v2.patch.bz2 (1 kB)
2. File slviewer-v11850-InventoryDoubleClickActions_v2.patch.bz2 (0.8 kB)

Issue Links:
Relates

Linden Lab Issue ID: DEV-2520
Patch attached: Patch attached

Sub-Tasks  All   Open   
 Sub-Task Progress: 

 Description  « Hide
This is a more organized attempt to address the concerns/ideas from the UI triage around VWR-1752

I'll split the issue into subtasks to be able to discuss the various types individually.

However, the common theme is, that in my opinion an double click on an item should activate the most commonly used action and that it should not bring up dialogs of lesser importance (like properties on objects) and not have safety questions or intermediate steps (unless the action is irreversible).

Examples for this are:

  • double click on any operating system starts a program
  • double click on inventory textures shows texture
  • double click on inventory script shows script
  • in web browser even single clicks navigate away from your page
  • shortcut links in browsers are also activated just by a single click

What I want to say with this is that a double click is a specific user action which I believe should have an effective result especially because browsers sometimes do smilar things this even with a less specific action.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Kooky Jetaime added a comment - 21/Jul/07 03:53 PM
As I mentioned in UI Triage, while I understand the reason for choosing not to implement such a (as stated in the triage meeting) "major" change in expected behavior, with this kind of thinking in place SL would not be what it has become.

My view on this issue is consistency over "whats been for the past XX should continue." Whatever actions are taken, we should strive for consistency across the client. Double clicking on something in inventory should activate it. Right now, there is inconsistency in that double clicking.

Double Click Results:

Animation - Display option to play in world or locally.
Calling Cards - Displays card name profile.
Clothing - Wears selected article.
Gesture - Opens the Gesture Editor for that gesture.
Landmarks - Display option to Show on Map or Teleport.
Notecards - Opens Notecard for editing.
Objects - Opens Properties.
Scripts - Opens Script for Editing.
Sounds - Plays Sound In World
Textures - Displays Texture
Snapshots - Displays Snapshot

Every item/object is "Actionable." Double clicking should invoke that action, not pull up the properties on some things, or the editor on others.

Suggested List of Double Click Actions -
Animation - Play Animation In World
Calling Cards - Open Individuals Profile
Clothing - Wear Article.
Gesture - (De)Activate Gesture
Landmarks - Teleport to Target
Notecards - Opens Notecard for Editing.
Objects - Specialized, see below
Scripts - Opens Script for Editing.
Sounds - Plays Sound In World
Textures - Displays Texture
Snapshots - Displays Snapshot

Objects -
This one is a bit more complex, but would likely be more useful. Upon double clicking an object, if object has an assigned attach point, attach the object to the avatar, if the object does not have an attach point, rez the object in front of the avatar. This would increase speed in rezzing objects, and stop new people from wearing boxes when they need to unpack their purchases first.

An alternative option would be to specify in the preferences the default option. I'll add it as a sub-task to this entry, as it may provide a "win-win" solution to the problem of how to handle these.


kerutsen sellery added a comment - 21/Jul/07 07:40 PM
I haven't looked through the code enough yet to see what happens when you select "wear" (vs "attach to > (some body part)") in the client – ie: whether the client sends a "wear" message and lets the server handle it, or sees the wearable info for the object and says "attach to (attach point) at (position)". The latter would make more sense, though, in which case the client already knows whether the object has wearable info set. That'd make detection of attachments vs regular objects pretty painless, if it's the case. And if it's not the case, it should be.

Nicholaz Beresford added a comment - 22/Jul/07 05:36 AM

Nice overwiew .... I guess I'll look into the animation part, although I foresee some discussion there. Will also see if it is feasible to make a double click on active items deactivate (unwear, etc.) them.

Regarding the objects, I had briefly looked into them and as far as I can tell, unless the thing is actually being worn at that time, it just sends an attach request to server. I was just a quick check, but I did not see a way to tell if it has an default attachment point already.


Nicholaz Beresford added a comment - 22/Jul/07 05:39 AM

On the other hand, internally there seems to be an object type for attachments (IT_ATTACHMENT vs. IT_OBJECT). Maybe there is a bug in the server which does not assign this type to objects which have attachment points. So far I've seen IT_ATTACHMENT only on Linden inventory from the default avatars.

Torley Linden added a comment - 07/Aug/07 10:22 AM
Imported this for further UI discussion.

Haravikk Mistral added a comment - 12/Nov/07 09:07 AM
Regarding gestures; I believe the behaviour should be more along the lines of:
  • If active = play/perform gesture
  • If inactive = activate gesture

This will still require right-clicking to de-activate a gesture, however I believe that that is the least common-case. This has the advantage that the inventory window can be used to more easily find and organise gestures, and thus double-clicking them can activate and/or play them more quickly than the drop-down menu (which is pish, it shouldn't really be there IMO).


Henri Beauchamp added a comment - 19/Nov/07 11:02 AM
I attached two patches, one for v1.18.4.3 and another for v1.18.5.0RC.

Beside the backport of the teleport on double-click for landmarks from v1.18.5.0 to v1.18.4.3, they implement:

  • Double click on wearable items:
  • wear item if not yet worn (it was already the case: nothing new).
  • take off item if already worn (new).
  • Double click on objects:
  • attach to avatar if not yet attached.
  • detach from avatar if already attached.

Enjoy !


Coyote Pace added a comment - 19/Nov/07 11:26 AM
Henri B said: "Double click on wearable items: ...- take off item if already worn (new)."

In the name of all that's holy, please exclude Pants from this feature! I'd hate to see the number of naked newbies go up exponentially


PJ Gibbs added a comment - 27/Feb/08 06:52 AM
I have to agree in part with Coyote... for clothing, if it is worn, then I think double clicking should have no effect. This would also be inline with the consistency message that Kooky mentioned... across the piece, double click to activate/wear/rez, right click options to remove.

McCabe Maxsted added a comment - 27/Feb/08 07:36 AM
How is clothing removal inconsistent? As Kooky points out, double clicking on something in the inventory should activate it. Doing nothing is not an activation. The correct behavior of a double click should be an action, which in the case of worn clothing should be its removal. Remember: toggling is just activating two opposite states. Objects are a bit tricker, but clothing is either worn or not worn. Henri's patch makes sense.

Rob Linden added a comment - 27/May/08 09:46 AM
Looking at the comments in our internal JIRA instance, Kooky's proposed behavior was implemented, and Henri's patch was not applied.

CrystalShard Foo added a comment - 08/Jan/09 04:17 AM
Is there any update on the progress of this feature's implementation? Its been nearly a year since Kooky's proposed behavior was implemented according to the internal JIRA instance, but we are still not seeing this in any of the currently released clients.

Carl Wilder added a comment - 25/May/09 05:23 PM
i really think this issue is worth addressing, with a slight modification that would mitigate for those who are concerned with compatibility.

First, I think any change to "double-click" behavior should also have a checkbox in Preferences that switches between the current behavior and any new behaviors. The default(s) can be for current behavior so that existing users are not confused.

Second, any argument about consist UI should note that as of viewer 1.23 the pie menus have been considerably reworked, which certanly broke MY muscle-memory and has created a precedent for UI changes such as the one proposed here.

Finally, of all the double-click behaviors the one that seems the most "incorrect" today is double-clicking an object. Double-click is a shortcut for a common action, but seriously how often does anyone want to look at object properties?

With the proliferation of attachments I would argue that the MOST common use of objects (apart from rezzing, which cant be done with double-click anyway) is "wear".

I therefore propose:

(a) A new Preferences checkbox that says "Double click object to wear"
(b) This preference is OFF by default.
(c) When OFF the current (display properties) behavior is active.
(d) When ON, double clicking an object will wear the object.

As a side note, the WORST that could happen with a spurious double click is that an unusual object ends up being worn for a few seconds (and I've seen that happen enough anyway). Therefore this proposed change has no deleterious effects.


Soft Linden added a comment - 28/May/09 10:14 AM
The next set of proposed changes here needs a new JIRA, rather than reusing the old one. There's not a matching patch attached, and the QA pass is already completed on the old one. This would also have to come after some other pending viewer changes.

I created VWR-13743 for Carl's comment above.