Skinning

Template:Needs Translation/de Template:Needs Translation/es Template:Needs Translation/el Template:Needs Translation/fr Template:Needs Translation/he Template:Needs Translation/it Template:Needs Translation/ko Template:Needs Translation/nl Template:Needs Translation/hu Template:Needs Translation/no Template:Needs Translation/da Template:Needs Translation/sv Template:Needs Translation/tr Template:Needs Translation/pl Template:Needs Translation/pt Template:Needs Translation/ru Template:Needs Translation/th Template:Needs Translation/uk Template:Needs Translation/zh-Hans Template:Needs Translation/zh-Hant

< Viewer Roadmap, User Interface Roadmap

Overview

Skinning refers broadly to the ability to customize the user interface. The Skinning project is part of the User Interface Roadmap and specifically describes a path to make the Second Life user interface entirely data driven and customizable by Linden Lab, 3rd party developers, and individuals, without requiring changes to the primary application source code, and maintainable across updates.

Priority

See User Interface Roadmap

See Also

• Skinning HowTo/Basics - documentation on current capabilities

Objectives

• Enable internal designers to more easily customize the look of Second Life
• Enable external developers and residents to better serve their audiences, and save customizations and prepare skin "packages" that persist across viewer updates
  • "Skinning" can mean a lot of things. So for this project, skinning shall initially mean:
  1. A custom look using the same-sized images. (for example, Dazzle)
  2. Custom floaters that display HTML and can speak back to the client through SLURLS.
  3. Customizations or language customizations are retained across installs
  4. "Simpler" skins that allow parts of the UI to be removed
  5. Customized help links
• Please use the 'discussion' page to raise constructive architecture considerations if you like.

Tasks

Phase 0

• The first phase is to implement Project Dazzle, which is a first skin implementation and proof-of-needed-abstraction for changing the colors/look of the user interface.

Phase 1

Enable Packaging and Resident customizations

• JIRA: VWR-6027 Skinning - Phase 1
  • Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts
    • Allow residents to save changes to a user local directory (i.e. Documents and Settings\User\Application Data\SecondLife\skins)
    • Define location to search for installed skin packages
    • subtask: VWR-5059 Include the ability to change skins and restore the original skin
    • Specify XML files that modify only (translation strings) or override completely (user customizations)

• JIRA: VWR-1883 UI Texture Cache
  • Objective: Make it easier to add and modify UI art
    • Separate pre-cached images with asset ids from UI images
    • Rename UI Images to use file names not asset ids

• JIRA: VWR-1884 Remove hard coded art and colors
  • Objective: Remove any UI art from the code
    • Remove programmatic art with attributes, e.g. volume sliders
    • Remove any backgrounds from icons, etc (use alpha)
    • Ensure that all images can be cropped and scaled
    • Allow specification of fixed size borders (i.e. so that button graphics with narrow boarders scale correctly)
    • Enable additional attributes to widgets for colors, etc
    • subtask: VWR-2447 Text drop-shadow settings aren't configurable in XML

Phase 2

Improve Localizations

• Automated changelist generator for all releases
• strings.xml - Global translation pairs for text not associated with a XUI file
• Allow residents to package changes and easily distribute them for easy installation by other users

Phase 3

Cleaner XUI files

• JIRA: VWR-1882 Sparse XUI files
  • Objective: Make the XUI files less verbose and more readable
  • Create 'templates.xml' file with default attributes for each widget type
    • Other templates for common attribute sets can also be declared here
    • Widgets can declare a template (default to the default one for that type)
  • Remove all default values from the code (XML cleanup)
    • Create a tool to process all existing XML files and write out only the non-default values
    • Clean up the XML output at the same time

• Automatically Save Floater Positions and Sizes
  • Include minimized position (not currently saved)

• Document the UI XML format

Phase 4

Data Driven Menus

• Menus and Overlay bar to become data driven

• JIRA: VWR-1885 Dynamic Reloading of UI elements
  • Objective: Make it easier to see the effects of XUI edits
  • Dynamic Reloading - Allow all UI elements to be reloaded without restarting the client
    • Enable reloading of all floaters including the menus and overlay bar
    • Ensure all floaters can handle missing UI elements and will behave reasonably or refuse to open with an appropriate message
  • eg., Changing the language setting will reload all UI elements

Phase 5

Dynamic Layout

• Improve the widget layout language and add auto sizing

• JIRA: VWR-1886
  • Objective: enable menus and overlay bar to be more easily customized
    • Allow buttons to open floaters by name
    • Include support for opening a specific tab
    • Differentiate between toggling state of singletons, showing/focusing, and opening new instances
  • Allow menus to be expanded/collapsed for simple vs. advanced usage
  • Specify layout of overlay bar and menu bar in "viewer.xml"
    • Allow multiple "overlay bars" to be added so that side bars or corner panels with buttons can be added

• JIRA: VWR-1887
  • Objective: make it easier to change the XUI layout data
    • Choose a standard model for the layout language (e.g. CSS? qt-like?)
    • Allow elements to be grouped for layout purposes
    • Auto layout elements when no layout information is provided

Specific Requests

• Make iconic panels (i.e.. build tools) generally available
  • Combination of fully iconic buttons and the ability for a button to open a specific tab in a floater
• Docking / Hosting - Make the 3D window a layout element and allow floaters to be docked
  • Possibly allow floaters to exist outside application window

Bold text