When starting an X-app that comes with a separate "<app-name>-color" file in /etc/X11/app-defaults, the settings in this file are completely ignored. On most other distros, they override settings in the app-defaults file without the "-color" suffix. Affected apps are: bitmap, editres, oclock, xcalc, xlogo, xedit, xmessage (and other apps that come with -color app-defaults that are not part of xfree). Reproducible: Always Steps to reproduce: 1. Start xcalc on a Gentoo system 2. Start xcalc on a SuSE system 3. Note that xcalc on other systems appears in nice colors and with roundish buttons by default, app-default files are exactly identical. Actual Results: xcalc is displayed with only black and white pixels and with rectangular buttons. Expected Results: I want colors!
still no colors!
This is low priority to me, if you want to look into the problem yourself it would be quite helpful.
does that mean I should give up?
No, it means do what you can to figure out why this is happening. It's likely an issue of how some config files are set up, you just need to track down the differences between Gentoo and SuSE (a diff -urN of the /etc/X11/ directories of both may prove useful, especially when piped to a grep for 'color'). This bug is more minor that those that involve things like "XFree is broken and crashes" so it falls lower on the priority list. If we are able to recruit more people to work on XFree-related things, this will be more likely to be worked on by us, but as it is resources are limited.
Do you have --- #ifdef COLOR *customization: -color #endif --- in your personal or global `.Xresources' file? If that doesn't work, the next step is (1) $echo "*customization: -color" | xrdb -merge $xcalc or passing this string directly to one of those programs, for example (2) $xcalc -xrm "*customization: -color" This causes the resource manager to check for app-defaults files with the customization string appended first, and, if not found, falls back to the plain name.
Sorry, almost forgot about #26354.. Could you try the above steps in a `startx' session?
ok, works in startx But from xdm, kdx, whatever, I have to use xrdb manually (wasn't this already established?) Dear Gentoo X-windows packagers, could someone PLEASE look at bug #26354, which is open almost as long as this one and not reduced to "minor". thanks
one more thing XTerm-color is broken. displays invisible text (white on white).
by which I underlined text (sorry, hit send to fast)
[hoping I'm deciphering the last two comment correctly] Yes, it seems the default `/etc/X11/app-defaults/XTerm-color' sets the color for underlined text to yellow-on-white and bold text to white-on-white, both not really easy on the eye. [Spyderous, if you're reading this-- xfree defaults to mapping both bold and underline to colors, although xterm would just as well support bold and underline... what is the "correct" fix here? Adopting the colors from `XTerm' or using bold and underlined characters instead?]
[see also bug #22267]
I also think there should be no color resources in noncolor XTerm. Doesn't seem right.
Reporter, could you please not change the severity? Thanks.
Does that mean I should REALLY give up?
No, it simply means that I prioritize xfree bugs in a certain way, and they're that way for a reason. Changing the severity of this bug will accomplish absolutely nothing except forcing me to change it back again. If a fix is posted to this bug, I'm more than willing to commit it. When one of the xfree team members gets to this bug, a fix will be worked on if it hasn't been found yet. Hopefully that will happen sooner rather than later because I'm recruiting more people to help out. There's only so much one person can do. I find time to fix the bugs that completely break xfree in addition to other maintenance, and that's difficult enough. Thanks.
I thought that is what "Priority" is for and "Serverity" is for the Reporter to express how severe HE thinks the problem is? This Reporter actually thinks this is a major problem and XFree shouldn't be marked stable because many programs don't work as expected.
forgot: but they do with most other linuxes/unixes.
They're both for us. A problem may be minor, but we may really want to get a fix in because it affects nearly every user: Thus low severity, high priority. A problem may be major but affect very few people: Thus high severity, perhaps low priority. See the logic? Andrew, could you look at this please?
Also: when I view the buglist, I sort it by severity because it's easy to see differences. With priority, this is more annoying because of the vagueness of the categories.
Well actually...the solution is quite easy: put this in a global `Xdefaults' file (see comment #5) ===CUT=== #ifdef COLOR *customization: -color #endif ===CUT=== Problem is, this requires bug #26354 to be solved first. Sorry again I was commenting there without a complete solution...what I had in mind is something more flexible that is shared with kdm, gdm, wdm, etc. and I didn't have the time to install them all yet.
Then perhaps somebody could look at bug #26354?
See my comment in http://bugs.gentoo.org/show_bug.cgi?id=26354
PLEASE TEST I have changed the scripts around a whole lot but to the extend of my testing (ie, startx, /etc/init.d/xdm start, and /usr/X11R6/bin/xinit <options>) the system now works with colours, and resource / modmap files in a uniform and simple configuartive place. Basically everything now acts as a wrapper for /etc/X11/xinit/xinitrc which merges resources, the system resources are merged first and then the users, so that user preferences over-ride the system ones :) Files of NOTE /etc/X11/xinit/ - xinitrc : The file to configure for system wide changes, startup prefs - Xresources : colours etc... - Xmodmap : keybindings etc... /etc/X11/xdm/ - Xservers : important to change this so -nolisten tcp is used as an option - Xsession : wraps to xinitrc with some fancy variable passing /usr/X11R6/bin/ - startx : wraps to xinitrc with some fancy variable passing I have left debugging outputs to boot in the 0.1 version of these scripts so IF you exeperience any difficulty please use at least the xinitc script from this tarball so I can see where you are having difficulty. There are two tarballs available containing the changed files http://dev.gentoo.org/~cyfred/xfree/ xinit-scripts-{0.1,0.2}.tar.bz2, as noted above if you dont want to see lots of echo'd lines on your console and logs, use the 0.2 version unless you have problems. The tarball has full paths to the files that it should replace so extract to a tmpdir and then copy them over the top, make sure you back up first!!!! Duplicating this comment on bug #26354 for consistency
colors are working fine now, BUT: 1. startx args are discarded: "startx -- :1" if a server is already running on :0 does not work! I see these processes: PID PPID 7117 5616 /bin/sh /etc/X11/xinit/xinitrc start -- :1 7128 7117 xinit -- -nolisten tcp -deferglyphs 16 7129 7128 [X] <defunct> Error message sez X is already running on :0 (!) On non Gentoo boxes I get a working second xserver on :1. 2. "start" and "dm" in startx client args dont work any more (think of users with custom startx scripts) 3. very odd: if "xinit -- :1" is called directly, sometimes it complains it cant find "xvt", sometimes it starts a second xinit process and an unkillable X; no clients; CTRL-C on original tty does NOTHING PID PPID 7160 5616 xinit -- :1 # in D state 7161 7160 [X] 7164 7160 xinit -- :1 # in T state after pressing CTRL-ALT-BACKSPACE: PID PPID 7160 5616 xinit -- :1 # in D state 7161 7160 [X] <defunct:> # zomby 7164 7160 xinit -- :1 # in T state On non Gentoo boxes I see a functional xserver and 1 xterm. 5. xserverrc is not used any more; what if I share /usr/X11R6 over multiple boxes, but some boxes need a different xserver binary? 6. should I reopen? (prob in summary seems fixed?)
Can't comment on the rest right now (dev.gentoo.org doesn't resolve for some reason), but the `xvt' bit comes from `0126_all_4.2.99.3-startx.patch' introduced somewhere between patches 1.1.7 and 2.1.10... ===0126_all_4.2.99.3-startx.patch=== @@ -148,7 +148,7 @@ <<-- this section should not be there char *default_server = "X"; char *default_display = ":0"; /* choose most efficient */ -char *default_client[] = {"xterm", "-geometry", "+1+1", "-n", "login", NULL}; +char *default_client[] = {"xvt", "-geometry", "+1+1", "-n", "login", NULL}; char *serverargv[100]; char *clientargv[100]; char **server = serverargv + 2; /* make sure room for sh .xserverrc args */ @@ -431,6 +431,7 @@ [..] ===
Point 3 above has been fixed for a while.
Sorry to disagree, but in xfree it's not. tree last synced Jul 16, 2004 03:57:16 CEST, xfree-4.3.0-r6, PATCH_VER="2.1.25.5": $ grep 'default_client' 0126_all_4.2.99.3-startx.patch -char *default_client[] = {"xterm", "-geometry", "+1+1", "-n", "login", NULL}; +char *default_client[] = {"xvt", "-geometry", "+1+1", "-n", "login", NULL};
=== long version === WHOO-HOO! /me opens bottle of very strong alcoholic beverage * purchased long time ago specifically for this kind of purpose /me starts fireworks screensaver on a SuSE box; user-level-customized per Xresources * running in xdm session; Xresources work right out of the box and always did /me starts celebrating 1st anniversary of reportage of this really annoying bug * low priority or not; it's not funny anymore * makes gentoo less usable in enterprise environments. * could somebody please reopen this bug; spyderous always yells at me if I change settings. === short version === *BUMP* This still isn't working; please fix!
cyfred: Can you take another look into this and the related couple of bugs, and update things so they work with xorg if necessary? reporter: I'm glad you've got such a great sense of humor. Please start testing these things against xorg-x11, as xfree is deprecated in Gentoo and essentially will remain static, excepting security vulnerabilities.
Created attachment 49708 [details] xcalc ilustation Another 6 months and this still isn't working. To illustrate what I mean, I have created a little illustration illustrating what xcalc looks like *by default* on different operating systems. As you can see, on gentoo it uses only 2 colors, just like it would look like on those other systems if it were running on a 2 bit display. But it's not! And since this affexts productivity appications as well, desktop users are not complety satisfied with their gentoo X11 experience! Is it time to finally give up?
That is quite a nice illustration, reporter. Unfortunately I just don't have the time to commit to this right now nor in the foreseeable future. I'm actively trying to recruit more help and I'm also eager to accept ready-to-go, minimal fixes. So if you have either of those, please help out. I'm interested whether vanilla, upstream xorg works as you'd like it to, or whether those are results of distribution- or OS-specific customizations.
Removing my cc as it doesnt make much sense to get it all twice...
Our engineers have determined this to be a problem in the gentoo operating system.
Reporter, could you more clearly answer my question in comment #31? A problem in Gentoo can be either something it does to break vanilla or something it doesn't do to be the same as everyone else.
No user response here for over 6 months. Reporter, see comment 31 and comment 34 and reopen if you are able to asnwer those questions.
Why, I didn't close it. Besides, Donny always gets mad at me if I change status on my bugs assigned to him. Besides 2, if I knew the answer to these questions, I would have answered over 6 months ago, but that does not mean the problem is resolved; it is still as alive as ever. Does that mean there's no hope?
(In reply to comment #36) > Does that mean there's no hope? > It means you should try one of the vanilla X servers (6.8.99.15 preferably) and see if things work the way you want.
I already tried the latest version; that's how I know the problem is still alive.
Once modular X is in a more usable state, it might be interesting to try in that. We apply almost no patches to it.
Just for the record: I'm running the modular release on ~x86. Comparing against the shot in the attachment by default I get an monochrome Xcalc. If I: cat /etc/X11/app-defaults/XCalc-color >>~/.Xdefaults I then get a colour Xcalc just like the Debian(New) and Suse(New) shots. This even though I have: #ifdef COLOR *customization: -color #endif in ~/.Xdefaults. (Of course they would look even better if libXaw3d were installed such that *all* Xaw apps would link against it..... But I digress.) This should work w/o using Xresources files. Xresource files (including ~/.Xresource) are server-side files; Xdefaults and ~/.Xdefaults are client-side. But the client-side files will not be opened by libX11 if it detects that any resources were loaded to the server via Xresources or xrdb(1x). You can even have ~/.Xdefaults-${HOSTNAME} files so that the client box can have settings specific to each server. Because of that it is vital not to load anything to the server unless the user explicitly does so via xrdb(1x) or ~/.Xresources. Even removing the #ifdef and forcing *customization: -color failed to load the -color version of the app-defaults file (confirmed via ltrace). It will take me more than a little effort to discover how those traces look on a system where the *customization: -color setting works, but I'll work on it. It is possible there is an issue with x11-libs/libXt; I'm remerging it w/ nostrip so that I can try it in a debugger.... I'll post if I find anything of use.
This is illustrative of the problem: :; strace -e access xcalc access("/etc/ld.so.preload", R_OK) = 0 access("/home/cloos/.Xauthority", R_OK) = 0 access("/usr/lib/X11/locale/C/XLC_LOCALE", R_OK) = 0 access("/usr/lib/X11/locale/C/XLC_LOCALE", R_OK) = 0 access("/usr/lib/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 access("/home/cloos/en_US.UTF-8/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/en/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/en_US.UTF-8/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/en/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/X11/en_US.UTF-8/app-defaults/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/X11/en/app-defaults/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/X11/app-defaults/XCalc", R_OK) = 0 As a result of that I found that if I do: ln -s /etc/X11/app-defaults ~/en then everything works as it should. But it doesn't explain why it only looked in $HOME for app-default files modified by the customization and not also in /usr/lib/X11.....
I was able to get enough installed on my debian uml to test this there. This is the strace -e access of xcalc with the same LANG, LC_foo, and ~/.Xdefaults as the gentoo (modular) test: access("/usr/X11R6/lib/X11/locale/C/XLC_LOCALE", R_OK) = 0 access("/home/cloos/.Xauthority", R_OK) = 0 access("/usr/X11R6/lib/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 access("/home/cloos/en_US.UTF-8/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/en/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/en_US.UTF-8/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/en/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/XCalc", R_OK) = -1 ENOENT (No such file or directory) access("/etc/X11/en_US.UTF-8/app-defaults/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/etc/X11/en/app-defaults/XCalc-color", R_OK) = -1 ENOENT (No such file or directory) access("/etc/X11/app-defaults/XCalc-color", R_OK) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/home/cloos/bitmaps/gray3", R_OK) = -1 ENOENT (No such file or directory) access("/usr/X11R6/include/X11/bitmaps/gray3", R_OK) = 0 as you can see the -color customization is attempted in the system app-default dir as well as $HOME. So that is the bug. The summary should probably read something like "*customization X resource only used when searching $HOME for app-defaults files but not also when searching /etc/X11".
Well, if you still have issues w/ modular X, kindly forward them upstream. This bug has made zero progress in 4 years; closing.
(In reply to comment #43) Well, since it's a gentoo-only problem (bug in gentoo specific init scripts), to me X11 upstream does not seem like the best place to report this. On one hand, IIRC Donnie B. published a list with his personel projects, among them being a rewrite of gentoo's X11 init scripts, so it seems there's still some hope. On the other hand, I seem to remember he said on more than one occasion this area is low priority to him (last October he even lowered priority from P2 to P3), so maybe 4 years isn't THAT long. Yes, I do "still have issues" (wrt. bug title) with modular X.
I think Uberlord is going to pick up that rewrite, so I'm reopening this to make sure it's noticed in the process.
(In reply to comment #45) > I think Uberlord is going to pick up that rewrite, so I'm reopening this to > make sure it's noticed in the process. I was, but then I retired from Gentoo. From a personal perspective I have little interest in this myself.
5 years into this bug, I think it's time to close it. No one in the x11 herd cares about xcalc and core-X applications anymore. Besides, these apps do work fine, they just look ugly. If anyone here has a patch, I'll gladly apply it. Meanwhile, let's stop pretending we're going to spend time on this. Again, patches are more than welcome. Thanks
