Bug 64824 - mini_commander_applet does not honor bg color preference
Summary: mini_commander_applet does not honor bg color preference
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnome-applets
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mark McLoughlin
QA Contact: Aaron Brown
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-05-13 08:16 UTC by Alessandro Tommasi
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-05-23 10:01:50 UTC
Embargoed:


Attachments (Terms of Use)

Description Alessandro Tommasi 2002-05-13 08:16:15 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:
The mini_commander_applet applet ignores the background color preference set by
the user in its 'preferences' window. No matter what color is selected, the
backgorund will be white.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.add a mini-commander applet to a gnome-panel (found among 'utility' applets)
2.right click, open the preferences window
3.set any color but white as background color
	

Actual Results:  background color remains white.

Expected Results:  background color changes to the user selected one.

Additional info:

The foreground color works as expected. Default setting has black background and
white foreground, making the text invisible. Fresh 7.3 installation, occurs with
or without nautilus.

Comment 1 Alessandro Tommasi 2002-05-23 10:01:44 UTC
Weird. Re-installing 7.3 from scratch (due to clumsy parted usage...) resulted
in mini-commander functioning properly. The problem might depend on some obscure
panel-wm-nautils configuration. Reproduction info is therefore not as precise,
but I think it's still a bug.

Comment 2 Havoc Pennington 2002-07-06 23:11:09 UTC
Appears to work in Rawhide, and the prefs storage code is quite different, so
it's unlikely to have the same corner case failures (if that's what this was).


Note You need to log in before you can comment on or make changes to this bug.