Closed Bug 22337 Opened 24 years ago Closed 22 years ago
Possible to install colormap on 8 bit displays?
I'm stuck on an 8 bit Sun display, so I use Netscape 4.x's -install flag to have Netscape install its own colormap. It looks much better that way than a reduced number of colors (and impacts other apps less), and I can tolerate the flashing. Does Mozilla have such a capability, and if not, could it be added? Thanks.
Assignee: nobody → pnunn
Component: Browser-General → ImageLib
QA Contact: nobody → elig
Sounds like a pnunn thing...
Sounds like a good option. -pn
Moving to m20
Target Milestone: M15 → M20
I disagree that this bug's severity should have been changed to "enhancement". I work for an organisation that has a large number of HP workstations with 8-bit PsuedoColour displays, and many of our applications are unusable if they can't allocate pens. Netscape has always had this option. Any X application that uses a lot of colours and cannot install its own colour map is *entirely useless* to us. We will simply be unable to run it. Upgrading our systems is not an option, and I really don't want to be stuck on Netscape 4 for ever. I'm quite surprised I'm the only person voting for this bug.
Are you volunteering to fix the bug?
I think the fix is pretty straightforward - a call to gdk_rgb_set_install(TRUE) early in the startup sequence. The trick is doing this in a clean way without introducing a hard dependency between mozilla and gtk.
I agree with Stuart Sharp that this is more than an enhancement - it is critical to have this functionality to make Mozilla useable in a low-colour environment. I'm sitting at a Sun with an 8-bit card... Netscape's '-install' flag would be sufficient but IE on Solaris does a better job by autosensing when it needs to install a colormap. This also has knock on effects with plugins etc - Netscape does not handle this correctly resulting in (for example) Netscape using its own colormap and an embedded Java 2 applet using the default colormap... Therfor it is not as simple as tor believes...
Umm. This looks very similar to bug #22058 . In all that time, nobody has noticed?
The reporter on bug 65881 commented on how to modify the colormap preferences so that it uses the installed colormap: From bug 65881: I don't have a diff handy, but the change is trivial. In widget/src/gtk/nsAppShell.cpp, there is a function HandleColormapPrefs(). Add gdk_rgb_set_install( TRUE ); return; at the top of the function. The same effect can be had by changing modules/libpref/src/unix/unix.js so that pref("browser.installcmap", true); instead of the default false value.
All pnunn bugs reassigned to Pav, who is taking over the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
I have many ultrasparc machines, all with 8bit displays, none of the default skins, nor any at x.themes.org will render properly on an 8 bit display. As I type this, I cannot hardly even tell where the scrollbars, buttons, or text boxes, etc begin or end. Except for the icons, which have sucked all but 2 or 3 of my colors, all the widgets are rendered in either black or white. With the forground, background, and some of the shadow details all rendered in white.Dont even ask about how the webpages are rendered. At this point **lynx** handles graphics better than mozilla on 8 bit displays. I will be happy to provide screenshots.
Reporter, we have a new imaglib, would you get a recent build and let me know if this is still an issue and if so, please attach screenshots, thanks
I'm the original reporter, but I've since moved up to a 24 bit display, so the whole thing became less important for me. I could start my home Linux box in 8 bit color mode to test things, if that would help. Gregg C, who posted a comment earlier, sounds like a good person to run this by, too, since he has lots of 8 bit Suns. So, the following line needs to be added to prefs.js to install a colormap? pref("browser.installcmap", true); I assume it's not automatic?
About this screenshot. This is an ultra10 running solaris. The two mozilla windows are from 2 different remote systems. The smaller window is from an Ultra E1 running Debian GNU/Linux 2.2, running M18 (Mozilla M18 Mozilla/5.0 X11; U; Linux 2.2.17 sparc64; en-US; m18 Gecko/20001113) (it does not have a graphics card on it, it will become a dns server shortly. The 2nd is from an Dell PC also running Debian 2.2 (Mozilla/5.0 (X11; U; Linux 2.2.15 i686; en-US; m18) Gecko/20001103). I added the color map option to both prefs files. It seemed to help somewhat, but this is still unusable. I could deal with this at home, but these systems are owned by my employer so I had to reinstall solaris on my test boxes. Managers, etc would find this unacceptable. They do have a point, these are not for surfing they are used as interfaces to systems controlling telco equipment, which often display long pages of complex forms, and table output with many rows of status indicators and links to change status, pull more info, etc. IMHO, all of this could be fixed with a skin, that has one shade of grey for the forground of all the surfaces and widgets, then 2 or 3 other colors for widget details, say black for lines and maybe a lighter or darker grey for shadows or other details. Instead of color icons, just have grey buttons like the ones you could use in netscape, when you selected "text only" for the buttons in the edit preferences window. Also a low color mozilla animated icon would really make it great. It's not just a seperate colormap, but even with all 8bit colors, the app had garbled areas, and it still effects the webpages. I would think the colors mozilla uses for the interface and the rendered pages would be shared, but from looking at these, I don't think that is how it works. I could also provide images of netscape 4.x on the same display. Unfortuneately I don't know how to make a skin, and I don't have time to investigate how to do so right now. I have to attend some telephony training classes while still working my normal duties. Which is why it has taken me so long to follow up on this. I'm about to download a recent nightly build to try out. I didn't see any for sparc on linux, so I'll try and compile the source, but I've never tried it before so I don't know how well that will go. Anything I can help with, I will be glad pitch in. ************* Wondering what screenshot I'm talking about. I don't know the best way to distribute it, so I'll just post it on my box at home. I'll place it at http://184.108.40.206/mozilla Anyone interested in looking at it can.
Gregg C, that URL gives an error. Please attach your screenshot using the `Create a new attachment' link in Bugzilla.
The url, is correct, just add a / to the end or just leave out the mozilla part, the root index.html has a link to the image, otherwise it is just a blank place holder. I can't seem to get network solutions to update my freaking DNS, so it grinds......
A 2 or 3 color skin would help alot, an 8 bit display only has so many colors, especially if mozilla is not the only app running, the display will look bad. I personally don't like using seperate colormaps, but the option is good to have, because in some circumstances that is the only thing practical. But even if the webpages look bad because of few colors, then at *least* the netscape widgets, forms and other graphical features should be visable and usable. That part should be free of "weird colors" and garbage. I could work on such a low color skin now, but I have not been able to find anykind of howto to make them. If someone would point me in the right direction, I could try, also a low color animated mozilla icon would help. I just want the application to look simple, clean, and not flash when changing focus. It just looks more professional that way. Except for the limited colors, the systems we have are very usable systems. Now, these machines are outdated in pure CPU power, but they are very stable with quality construction, some individual machines have upwards of a year or 2 of uptime under solaris. If I can get these running linux + mozilla then these boxes can serve their purpose for the next decade or so.
*** Bug 93248 has been marked as a duplicate of this bug. ***
This bug still open ? No '-install' option after one and a half(!!) year ? I can't believe this, since useable display in any colordepth is one of the basic principles of good program design EVERY student on informatics learns in the very first semester (at least in good old europe) !!! Hey, quality supervisors, where are you ??? I would mark this as a BLOCKER (and would fire the programmers, if this had been a software company..) !
Will this be fixed before 1.0? I know it's only aesthetics, but it's ugly, ugly, ugly nevertheless.
Actually, this is a 4.x parity issue- I'd add the 4xp keyword if I could! (and mozilla1.0 as well)
This bug is a blocker for N6 internal deployment at Sun as default browser. Can someone raise the priority of this bug to P2/major
I can modify the preference to install the colormap on Solaris, then the browser act stable as they used to be even when xv is running. But the problem to me is that the colormap has taken over the Solaris' system colormap. But the xv would not. Anybody can help?
I found the browser.ncols and browser.installcmap settings in $INSTALLDIR/defaults/pref/unix.js could overload themselves in $HOME/.mozilla/...../prefs.js. So you have to change all of them or just delete the same setting lines in one file. Unfortunatly, some people have told me the opposite concept before. And I donot know the appropriate ncols number on the 8 bit display. Can anybody tell me?
Hi, Since this is common in many old style workstations, and there is the change to install netscape to a server, could somebody told me the exact ncols and installcmap settings in the unix.js file? Could someone help?
I would concur that this is a showstopper issue for companies with lots of 8 bit workstations. I have been trying to use 0.9.8, but too many sites are now using color images for buttons and links. Besides being ugly, you cannot do any work because you cannot see the buttons or links. I have played with the ncols and installcmap preferences to no avail. In my case, it's a HP C3000. Please fix before 1.0
Philip, normally you should start Netscape6 before other applications like staroffice, ns4, xv etc. Otherwise, you should enable the installcmap setting: have you try it in unix.js: +++++++++++++++++++++++++++++++++++++++ In file: $INSTALL_DIR/defaults/pref/unix.js, Remove next two lines: pref("browser.ncols",0); pref("browser.installcmap", false ); Add one line: pref("browser.installcmap", true ); ++++++++++++++++++++++++++++++++++++++++
Yes I have tried several combinations including the one Jim Song suggested, which actually made it worse. Starting mozilla first makes the colors better, but does not improve the the quality into the "acceptable" range. Further it grabs enough color to make other programs hard to use or abort. Also starting it first is not always an option for everyone. Please restore the original "netscape -install" capability.
The prefs weren't working because of a bug in the logic and the user prefs haven't been read at the time the appshell is created. This patch does away with the prefs and adds a "--install" command line option for installing a private colormap.
Comment on attachment 79858 [details] [diff] [review] add a "--install" private colormap option looks good, but --install is too overloaded; how about --install-cmap or --installcmap as the option name? Fix that and firstname.lastname@example.org. /be
Attachment #79858 - Flags: superreview+
Just a question: if this is a 4xp bug, doesn't the option need to have the same name as it did in 4.x? In that case, it would be --install... I'm not sure if there's a policy on this, though. If not, --install-cmap would seem to be a lot more sensible. (Or --install-colourmap!)
Sorry, I forgot that 4.x used --install, and 4xp is set on this bug. I withdraw the --install-cmap idea. /be
Actually 4.x uses "-install". Mozilla takes an odd mix of "--" and "-", so I randomly picked the option used. Anyone want to make a final decision as to the right one?
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX
Comment on attachment 81065 [details] [diff] [review] "--install" -> "-install" for strict 4.x parity r=pavlov
Comment on attachment 81065 [details] [diff] [review] "--install" -> "-install" for strict 4.x parity Carrying forward brendan's sr (comment 32).
Attachment #81065 - Flags: superreview+
Checked into trunk.
Comment on attachment 81065 [details] [diff] [review] "--install" -> "-install" for strict 4.x parity a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #81065 - Flags: approval+
Checked into the 1.0 branch.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Running on HPUX with 8-bit graphics adapter. Visual defaults to "PseudoColor". When I launch Mozilla 1.0 RC3 without the "-install" option, colors look normal. When I launch *with* the "-install" option, the colormap is trashed. It looks like an application that has a private color map, but does not have focus. The colors in the application don't change as the app window gains focus, they stay messed up. Mozilla is the only application running at the time. This bug is marked resolved, so the code change itself must be working everywhere else. Any hints on how I might go about debugging this on HPUX?
I asked someone inside HP to try the latest nightly build (6/11/2002) of Mozilla on his 8-bit adapter machine, and he got the same results as I did. "when I tried running your new mozilla, this is what I saw: The colors in its window were all wrong and they would not correct themselves regardless of which window I clicked on. I saw the colors of another window (which uses a private colormap) change, which tells me that mozilla had indeed created a new colormap, but it seems that while it thought it was rendering with the colors of that colormap, it was actually using the same pixels from the default colormap which were wrong. Also, when I opened a second mozilla window (from the File->New->Navigator Window menu), it appears that both mozilla windows were using the same single private colormap rather than having one per window (as the old Netscape does)."
There are two parts to this problem: recognizing the "-install" option to make gtk install a private colormap, and allocating windows which then use that map. This bug got closed when just the first of those two issues got fixed, apparently. The other half of the problem is still open in bug 65881 and I just added comments to that bug, referencing this one, which gives the 2-line change needed to get gdk to use the cmap allocated by gdk_rgb_set_install(TRUE) when creating new windows. This has proven good results on a few systems now, so I'm not sure if the private colormap in Mozilla worked anywhere without this.
*** Bug 173587 has been marked as a duplicate of this bug. ***
I was able to verify that this works under Linux. We tested on a Red Hat 7.2 system with an NCD HMX thin client (8-bit).
*** Bug 98802 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.