Closed
Bug 4762
Opened 26 years ago
Closed 24 years ago
Apprunner displays poorly on 8-bit displays (Linux only)
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M17
People
(Reporter: cpratt, Assigned: german)
References
Details
(Keywords: platform-parity)
Attachments
(4 files)
My linux box is only capable of displaying 256 colors on the screen due to
hardware limitations. When I start Communicator or Navigator 4.07, they look
like any other applications and the window manager looks okay too. However, when
I start apprunner, everything else turns all kinds of wiggy colors (black,
purple, etc.), and the apprunner window can have graphic problems as well (for
example, the menu and title bars turn dark blue and purple). This has never
worked for me. Phillip Bond sez it has something to do with using a private
color map...?
Updated•26 years ago
|
Target Milestone: M7
this is the expected behavior on low depth displays.
you probably are running kde and communicator, which are both color hogs.
try a very simple window manager setup with no icons or colors and no programs
running.
if you still get the color problems, then yes, maybe there is an issue.
in any case, i dont expect to look at this bug till much later.
marking m7
I think everything is about as simple as it gets - I'm using fvwm (yuck) and not
KDE, and I'm not running Communicator when I launch apprunner. I understand this
isn't high priority right now - but there is definitely a problem on low-end
systems such as mine.
Summary: Apprunner displays poorly on 8-bit displays (Linux only) → [PP]Apprunner displays poorly on 8-bit displays (Linux only)
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M7 → M9
ok. thanks for the info.
i still cant get to this till much later cause of all the other doomness...
marking assigned m9.
Moving all Apprunner bugs past and present to Other component temporarily whilst
don and I set correct component. Apprunner component will be deleted/retired
shortly.
Updated•25 years ago
|
Assignee: ramiro → german
Status: ASSIGNED → NEW
Comment 5•25 years ago
|
||
Comment 6•25 years ago
|
||
probably need to stay inside the 216 color palette... gramps said you should
look at this bug first and if you don't want it send it back to him
Updated•25 years ago
|
Assignee: german → don
Updated•25 years ago
|
Assignee: don → german
Didn't I fix this a while back? There are preferences settings I added that can
be used to control this.
Added mcafee to cc list; he has a bug like this. The bug I filed and fixed was
8413. Perhaps we need to document more clearly in release notes how this works
(see 8413 for instructions).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Assignee | ||
Comment 10•25 years ago
|
||
The icons will eventually fully comply to the web-safe palette ( I thought they
already are, so I ma not sure why they are showing up weird on the screenshot
supplied earlier). Wrt to the background colors, those are specifically create
to detect problems before beta with regards to hardcoding to grey where icons
have flaws in their transparency and XUL elements have grey hard-coded in their
css files. This and the fact that any web-safe color outside grey (#CCCCCC)
would be too glaring for day to day use. Hence #CCCCDD for now. This will be
fixed for beta one, but we should seriously think whether those poor souls on
low-powered Linux displays should be treated as an edge case,one that we fix
other than making everybody else suffer from the lowest common denominator. (By
supplying an extra xul.css for those case, it's just some lines that define
color that would change)
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Comment 11•25 years ago
|
||
There's a whole class of 8-bit solaris displays
that should not be considered edge cases.
Reopening.
Comment 12•25 years ago
|
||
I also fail to understand why a bug that "should be fixed for beta 1"
got ? LATERED. Later is for "fix this in 6.0".
Assignee | ||
Comment 13•25 years ago
|
||
good points on solaris. will reconsider.
my fault for setting later, I meant to set to m12 (just before beta 1)
Updated•25 years ago
|
Target Milestone: M12 → M17
Updated•25 years ago
|
Resolution: LATER → ---
Comment 14•25 years ago
|
||
This needs to be fixed before we can use any new UI. If the UI is going to look
like crap on 8bit displays then someone didn't put much thought into the UI.
This needs to be fixed by the time a new UI lands.
Updated•25 years ago
|
Component: other → UE/UI
Comment 15•25 years ago
|
||
UE/UI
Assignee | ||
Comment 16•25 years ago
|
||
the new and look feel (to come in shortly) will use colors from the web palette
to make this work. Stay tuned.
Updated•25 years ago
|
QA Contact: beppe → claudius
Updated•25 years ago
|
Summary: [PP]Apprunner displays poorly on 8-bit displays (Linux only) → Apprunner displays poorly on 8-bit displays (Linux only)
Comment 17•25 years ago
|
||
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Comment 18•25 years ago
|
||
can you illustrate by including some screen grabs?
Comment 19•25 years ago
|
||
Comment 20•25 years ago
|
||
For the latest screen shot, maybe I have eye problemes ;-) but it looks as
normal as we saw today on Window's. Do we consider this bug is fix? or the
problem is still there?
Comment 21•25 years ago
|
||
Looking at the screen shot, I really think that is the best we are going to be
able to do. Clearly we are getting the colormap, visual right. To me the UI
looks as good as it does on deeper displays, given limitations of 8-bit. About
the only defect I see is some dithering in the conent which is unavoidable.
Closing.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 22•25 years ago
|
||
agreed, this looks pretty good for me.
Another bug has been filed for non-imglib rendered
icons (desktop, etc.): http://bugzilla.mozilla.org/show_bug.cgi?id=28369
Comment 24•24 years ago
|
||
This is a _really_ minor point but if you look above the Mozilla M up at the top
right of the the second screenshot you can see the grey has been dithered. Why
not make it the same grey as the grey to the left/right/below the M so it
doesn't dither?
Also, input boxes look ugly in 8-bit because they are missing the bottom grey.
Severity: normal → minor
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 25•24 years ago
|
||
Comment 26•24 years ago
|
||
Upon looking at a screenshot from a newer build, it appears that the dithering
above the button has been fixed. However, the bottoms of certain widgets do not
appear... (see new screenshot).
Comment 27•24 years ago
|
||
sitsofe, i think your issues need to be reported as new and different bugs. This bug should be reverted back to it's verified status.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 28•24 years ago
|
||
Latest build on 5/5 hasn't done anything for me as far as psych dithering. I
don't know if this is normal or what. I am running Mozilla on OpenBSD from my
Linux box and the dithering for the interface and pictures on pages is not close
to the quality of Netscape 4.x
Hmm. Should I put this as a separate bug?
Comment 29•24 years ago
|
||
Comment 30•24 years ago
|
||
Marking VERIFIED this bug should not have ever been reopened. IF you have issues, file NEW, very specific bugs.
Status: RESOLVED → VERIFIED
Comment 31•24 years ago
|
||
Split 8-bit form element display into bug 39250.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•