Bug 81462 - [Perspectives] The background colour when closing all perspectives is hard-coded and non-standard
Summary: [Perspectives] The background colour when closing all perspectives is hard-co...
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1   Edit
Hardware: PC Solaris-Motif
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-16 15:31 EST by Douglas Pollock CLA
Modified: 2019-09-06 15:34 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Douglas Pollock CLA 2004-12-16 15:31:09 EST
I20041216-1200, Solaris, Motif, CDE 
 
When all perspectives are closed now, a custom background colour and 
foreground colour are chosen.  These colours are not configurably, and are 
non-standard (at least with respect to non-Windows apps).  These should 
ideally play nice with either native widget toolkit theming (e.g., GTK+) or 
with Eclipse's homegrown theming.
Comment 1 Nick Edgar CLA 2004-12-16 16:01:36 EST
The code is in IDEWorkbenchAdvisor.createEmptyWindowContents.
It currently uses SWT.COLOR_DARK_GREY and SWT.COLOR_WHITE.

If it's changed to use SWT.COLOR_TITLE_INACTIVE_BACKGROUND and
SWT.COLOR_TITLE_INACTIVE_FOREGROUND, it looks acceptable on Windows, and should
play well with the theme.

Billy, do you have any suggestions for which values look good here on GTK?
If possible, I'd like to stick to the predefined colours rather than defining
new ones via the themes xpt.


Comment 2 Billy Biggs CLA 2004-12-16 16:59:25 EST
The inactive title bar colours are not well defined on GTK+ (and seem to
actually map to the inactive selection foreground and background colours).

I am not sure what would be an appropriate choice here either.  Using anything
other than the default widget foreground and background makes the margins along
the sides of the window stand out in a strange way.  If it just drew a maximized
editor area frame instead of using colours I think it might fix the blankness
problem without getting into too much trouble with themes.
Comment 3 Nick Edgar CLA 2005-02-17 16:50:09 EST
Deferring.

We want to show extra instructions here, not just a blank editor area.
Comment 4 Nick Edgar CLA 2005-03-30 12:50:28 EST
Doug, can we live with this as-is for 3.1?
Comment 5 Douglas Pollock CLA 2005-03-30 14:00:37 EST
I must confess that I'm finding the lack of interest expressed on a few bugs of
this sort very disheartening.  (Bug 62900, Bug 62903, and Bug 85581, for
example).  The cumulative effect of not paying attention to appearance on
non-Windows platforms is an unprofessional overall appearance on non-Windows
platforms.

Now that I've had my chance to rant ... yeah, sure ... after 3.1 is fine.
Comment 6 Nick Edgar CLA 2006-03-15 11:46:50 EST
Reassigning bugs in component areas that are changing ownership.
Comment 7 Paul Webster CLA 2006-09-28 15:14:21 EDT
Is this still a problem in 3.3?

PW
Comment 8 Denis Roy CLA 2007-06-22 09:32:45 EDT
Changes requested on bug 193523
Comment 9 Eclipse Webmaster CLA 2019-09-06 15:34:57 EDT
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.