Bug 299716 - [CSS] relationship of CSS to 3.x themes and workbench presentations
Summary: [CSS] relationship of CSS to 3.x themes and workbench presentations
Status: RESOLVED WORKSFORME
Alias: None
Product: e4
Classification: Eclipse Project
Component: UI (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Bogdan Gheorghe CLA
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-14 18:23 EST by Susan McCourt CLA
Modified: 2019-06-05 07:42 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Susan McCourt CLA 2010-01-14 18:23:56 EST
We need to define how the 3.x themes and workbench presentations map to CSS.
From a programmatic as well as UI/preferences point of view.

API issues:
- Jface color registry still exists for jface-only apps
- is the workbench's jface color registry now populated based on CSS?  (ie, the compatibility layer's color registry)
- how are theme color definitions/mappings defined in CSS?  Do we just say that the p tag selector refers to the default theme colors?  Or is there a special class selector that represents a theme?
- when a plug-in defines a theme via 3.x extension point, what happens underneath, how does this map to the CSS?  

UI issues:
- What does Preferences->General->Appearance look like in light of CSS. We can assume the user is selecting a style sheet instead of selecting a presentation and theme.
- what about the colors page?  We might want to think of this as "user defined theme" and it maps to the CSS the same way a programmatic theme extension would...

This all needs some thought...
Comment 1 Remy Suen CLA 2010-01-14 19:31:50 EST
Funny, I was wondering about this today since org.eclipse.ui.editors listens for theme changes.
Comment 2 Eric Moffatt CLA 2010-01-18 14:10:22 EST
Susan, do you have any preference for this ? I'm wondering whether it makes sense to even attempt to reconcile the two (CSS vs Themes/prefs). In some ways it seems that we might be better off in e4 to go with only the CSS. As long as our story for editing the CSS is good then the only loss to clients is that the picky ones that tweaked their default values would have to set them up again once they switch to e4, presumably using a new mechanism that will be *much* clearer than the current legacy arrangements (I spent a quite frustrating time trying to change the font sizes once when I got a new hi-res monitor).

I'm not sure if dropping this is even acceptable but trying to support both seems like it's gonna be a can o'worms. I wonder if we could write a tool that could interpret a 3.x setup and generate a close approximation CSS file as a bridge?
Comment 3 Thomas Schindl CLA 2010-04-18 08:35:19 EDT
I started working on a CSS-Theme-Manager and CSS-Contribution system in bug 309593
Comment 4 Eclipse Genie CLA 2019-01-02 13:27:55 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 5 Lars Vogel CLA 2019-06-05 07:42:48 EDT
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard.

If this bug is still valid, please reopen and remove the "stalebug" keyword.