Difference between revisions of "Skinning"
Jump to navigation
Jump to search
Ramzi Linden (talk | contribs) m (→Phase 4: renamed a jira task VWR-1885) |
Asuka Neely (talk | contribs) m |
||
Line 1: | Line 1: | ||
{{multi-lang}} | |||
[[Category:Linden Lab Projects]] | [[Category:Linden Lab Projects]] | ||
== See Also == | == See Also == | ||
Line 107: | Line 108: | ||
* Docking / Hosting - Make the 3D window a layout element and allow floaters to be docked | * Docking / Hosting - Make the 3D window a layout element and allow floaters to be docked | ||
** Possibly allow floaters to exist outside application window | ** Possibly allow floaters to exist outside application window | ||
'''Bold text''' |
Revision as of 19:52, 13 April 2008
See Also
- Viewer Roadmap
- User Interface Roadmap
- 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:
- A custom look using the same-sized images. (for example, Dazzle)
- Custom floaters that display HTML and can speak back to the client through SLURLS.
- Customizations or language customizations are retained across installs
- "Simpler" skins that allow parts of the UI to be removed
- 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)
- Objective: enable external developers and residents to preserve changes across updates and distribute custom UI layouts
- 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
- Objective: Make it easier to add and modify UI art
- 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
- Objective: Remove any UI art from the code
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
- Objective: enable menus and overlay bar to be more easily customized
- 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
- Objective: make it easier to change the XUI layout data
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