Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/CSS/Visual Design"
| Line 1: | Line 1: | ||
This page summarizes the investigations into an updated visual design (default stylesheet) for the e4 workbench. | This page summarizes the investigations into an updated visual design (default stylesheet) for the e4 workbench. | ||
| − | + | == Goals == | |
The goals of this work are: | The goals of this work are: | ||
| − | * design a compelling | + | * design a compelling visual style for e4 |
| + | ** reduce visual noise, focus on the data | ||
| + | ** investigate additional breathing space, lessons learned from publishing and web | ||
| + | ** sleek/modern | ||
* drive the ability/flexibility of the CSS styling for SWT widgets | * drive the ability/flexibility of the CSS styling for SWT widgets | ||
* demonstrate the ability to keep a "classic" look and supply alternate designs | * demonstrate the ability to keep a "classic" look and supply alternate designs | ||
| − | + | == Visual Design Items == | |
This is currently just a list of ideas (not prioritized or committed). | This is currently just a list of ideas (not prioritized or committed). | ||
* tabs | * tabs | ||
** ability to define custom shapes | ** ability to define custom shapes | ||
| − | ** custom highlight colors and gradients | + | ** custom highlight colors and gradients for tabs |
| + | ** ability to express a background color for area behind tabs (ie, blank space on right) | ||
| + | ** custom fonts/bolding for selection | ||
** ability to remove keylines or specify their color independently | ** ability to remove keylines or specify their color independently | ||
*** remove or color top border without removing tab tops | *** remove or color top border without removing tab tops | ||
| − | *** remove, color, or set position of the line | + | *** remove, color, or set position of the bottom tab line |
* ability to style separately the color/presence of borders on widgets (per side)? | * ability to style separately the color/presence of borders on widgets (per side)? | ||
* view and editor toolbars | * view and editor toolbars | ||
| − | ** consider a local editor toolbar | + | ** consider a local editor toolbar (appears in location of current breadcrumb bar) |
** appearance of local view toolbars in consistent location below | ** appearance of local view toolbars in consistent location below | ||
| + | ** appearance/location of min/max view controls | ||
* view/editor visuals | * view/editor visuals | ||
** visual separation of view stacks without using keylines (coloring?) | ** visual separation of view stacks without using keylines (coloring?) | ||
| Line 25: | Line 31: | ||
* perspective switcher | * perspective switcher | ||
* status area | * status area | ||
| + | * toolbar with customizable background/transparency | ||
* ability to specify an image as a workbench background | * ability to specify an image as a workbench background | ||
| + | * reduce visual clutter - no need to decorate for the 90% case | ||
| + | |||
| + | == Interaction Design Items == | ||
| + | * Activity based layouts vs. perspectives | ||
| + | * "Split editor" interactions | ||
| + | ** Today creating a split is same feedback as stack manipulation but it's a different thing | ||
| + | ** Toolbar icons for managing split/unsplit (might be useful in "compare" also) | ||
| + | |||
| + | == Implementation issues/constraints == | ||
| + | * menubar is native | ||
| + | * we must assume view/editor content is limited in ability to style | ||
| + | ** selection colors are native | ||
| + | ** table headings are native | ||
| + | * CTabFolder/ETabFolder | ||
| + | ** limited ability to specify shapes in current implementation (anti-aliasing/blending issues) | ||
| + | ** ownerdraw model would require Java code to manage custom tab shapes | ||
| + | ** can we style it by supplying bitmaps for corners and top/bottom, stretch to fit text content | ||
| + | * Programmatic simplication? (revisiting individual items is costly) | ||
| + | ** diminish icons when views lose focus | ||
| + | ** compute decorator 90% case and show the exceptions instead | ||
| + | ** subtle fades of non-active views | ||
Revision as of 14:52, 5 October 2009
This page summarizes the investigations into an updated visual design (default stylesheet) for the e4 workbench.
Contents
Goals
The goals of this work are:
- design a compelling visual style for e4
- reduce visual noise, focus on the data
- investigate additional breathing space, lessons learned from publishing and web
- sleek/modern
- drive the ability/flexibility of the CSS styling for SWT widgets
- demonstrate the ability to keep a "classic" look and supply alternate designs
Visual Design Items
This is currently just a list of ideas (not prioritized or committed).
- tabs
- ability to define custom shapes
- custom highlight colors and gradients for tabs
- ability to express a background color for area behind tabs (ie, blank space on right)
- custom fonts/bolding for selection
- ability to remove keylines or specify their color independently
- remove or color top border without removing tab tops
- remove, color, or set position of the bottom tab line
- ability to style separately the color/presence of borders on widgets (per side)?
- view and editor toolbars
- consider a local editor toolbar (appears in location of current breadcrumb bar)
- appearance of local view toolbars in consistent location below
- appearance/location of min/max view controls
- view/editor visuals
- visual separation of view stacks without using keylines (coloring?)
- visual distinction of editor area
- perspective switcher
- status area
- toolbar with customizable background/transparency
- ability to specify an image as a workbench background
- reduce visual clutter - no need to decorate for the 90% case
Interaction Design Items
- Activity based layouts vs. perspectives
- "Split editor" interactions
- Today creating a split is same feedback as stack manipulation but it's a different thing
- Toolbar icons for managing split/unsplit (might be useful in "compare" also)
Implementation issues/constraints
- menubar is native
- we must assume view/editor content is limited in ability to style
- selection colors are native
- table headings are native
- CTabFolder/ETabFolder
- limited ability to specify shapes in current implementation (anti-aliasing/blending issues)
- ownerdraw model would require Java code to manage custom tab shapes
- can we style it by supplying bitmaps for corners and top/bottom, stretch to fit text content
- Programmatic simplication? (revisiting individual items is costly)
- diminish icons when views lose focus
- compute decorator 90% case and show the exceptions instead
- subtle fades of non-active views