Use .Xresources instead .Xdefaults by default in FreeBSD

TheUser

TheUser

Hi, what should i do to use .Xresources instead .Xdefaults by default in FreeBSD ?

Currently I use .Xdefaults but I want my programs to be able to read the color settings from .Xresources such as DWM Window Manager and ST terminal that have patches that read from .Xresources and I don't want to do manual loading with the command because I have the configuration duplicated in both X files so that everything works.
Then i do
Code: 
xrdb -load .Xresources
 
From the man page of xrdb(1)
Xrdb does not load any files on its own, but many desktop environments use xrdb to load ~/.Xresources files on session startup to initialize the resource database, as a generalized replacement for ~/.Xdefaults files.​
So install a DE and inspect the startup scripts, then deinstall. Sorry I have no better hint that RTSL.
 
If the files have the same content, you can create a symlink (or a hardlink if you prefer). Then you have to edit just one file when you want to make any changes, and they will be picked up by all applications, no matter which one of the files they use.
 
TheUser said:
I have the configuration duplicated in both X files so that everything works.
Click to expand...
There's nothing wrong with this necessarily, but you should be able to simply rename or link .Xdefaults to .Xresources, provided you load/merge them using xrdb(1). Getting the X Environment Defaults explains this in more detail:
To create a database, XGetDefault uses resources from the RESOURCE_MANAGER property on the root window of screen zero. If no such property exists, a resource file in the user's home directory is used. On a POSIX-conformant system, this file is "$HOME/.Xdefaults". After loading these defaults, XGetDefault merges additional defaults specified by the XENVIRONMENT environment variable. If XENVIRONMENT is defined, it contains a full path name for the additional resource file. If XENVIRONMENT is not defined, XGetDefault looks for "$HOME/.Xdefaults-name" , where name specifies the name of the machine on which the application is running.
Click to expand...
Basically, if you used xrdb(1), old programs relying upon XGetDefault to get defaults from .Xdefaults will continue to work, and newer applications that use the Xrm* functions to interact with the RESOURCE_MANAGER property such as your patched DWM and ST will also behave properly. Without xrdb(1), the RESOURCE_MANAGER property may not be created*, and .Xdefaults is loaded and parsed every time you start an X application, not that it will matter to anything that uses the Xrm* functions. This is really the biggest reason to migrate away from the old .Xdefaults behavior completely and rely on xrdb(1).

* If you're unsure whether the RESOURCE_MANAGER property was created for some reason, you can use xprop -root | grep RESOURCE_MANAGER to check.
 
memreflect said:
There's nothing wrong with this necessarily, but you should be able to simply rename or link .Xdefaults to .Xresources, provided you load/merge them using xrdb(1). Getting the X Environment Defaults explains this in more detail:

Basically, if you used xrdb(1), old programs relying upon XGetDefault to get defaults from .Xdefaults will continue to work, and newer applications that use the Xrm* functions to interact with the RESOURCE_MANAGER property such as your patched DWM and ST will also behave properly. Without xrdb(1), the RESOURCE_MANAGER property may not be created*, and .Xdefaults is loaded and parsed every time you start an X application, not that it will matter to anything that uses the Xrm* functions. This is really the biggest reason to migrate away from the old .Xdefaults behavior completely and rely on xrdb(1).

* If you're unsure whether the RESOURCE_MANAGER property was created for some reason, you can use xprop -root | grep RESOURCE_MANAGER to check.
Click to expand...

Apparently I don't have that property:

Code: 
$ xprop -root

_NET_ACTIVE_WINDOW(WINDOW): window id # 0xc00006

_NET_CLIENT_LIST(WINDOW): window id # 0xa00006, 0xc00006, 0xe00006

_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_WM_NAME, _NET_WM_STATE, _NET_SUPPORTING_WM_CHECK, _NET_SYSTEM_TRAY_S0, _NET_SYSTEM_TRAY_OPCODE, _NET_SYSTEM_TRAY_ORIENTATION, _NET_SYSTEM_TRAY_ORIENTATION_HORZ, _NET_WM_STATE_FULLSCREEN, _NET_ACTIVE_WINDOW, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_DIALOG, _NET_CLIENT_LIST

_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x800017

WM_NAME(STRING) = "2020-08-18 22:52:27"

ESETROOT_PMAP_ID(PIXMAP): pixmap id # 0x600001

_XROOTPMAP_ID(PIXMAP): pixmap id # 0x600001

XFree86_DDC_EDID1_RAWDATA(INTEGER) = 0, -1, -1, -1, -1, -1, -1, 0, 88, 88, 0, 0, -112, 6, 26, 4, 1, 0, 1, 3, -128, 0, 0, 120, -18, -18, -111, -93, 84, 76, -103, 38, 15, 80, 84, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, -70, 41, -112, 6, 96, 26, 6, 64, 2, 2, 34, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -3, 0, 0, -56, 0, -56, 100, 0, 10, 32, 32, 32, 32, 32, 32, 0, 0, 0, -4, 0, 86, 66, 79, 88, 32, 109, 111, 110, 105, 116, 111, 114, 10, 0, 0, 0, 16, 0, 10, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 32, 0, 82

_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "en", "", ""

XFree86_has_VT(INTEGER) = 1

XFree86_VT(INTEGER) = 9
 
To see the differences of the files:
Code: 
diff .Xdefaults .Xresources
To merge text from one file to the end of the latter file:
Code: 
cat .Xdefaults >> .Xresources
Use both >> or it will overwrite, instead of amend to the file. 1 > will overwrite it. You can use notepad or type it out all manually, if you're worried about that. Then delete duplicate lines in the file.

Use
Code: 
ln -s .Xresources .Xdefaults
to link from .Xdefaults to .Xresources. .Xdefaults may have to be deleted for this to work.
 
TheUser said:
Apparently I don't have that property:
Click to expand...
Then that means whatever you're using to load dwm isn't using xrdb(1). If you're using xinit or startx for example, you'll want to add something like this to your ~/.xinitrc:
Code: 
userresources="${HOME}/.Xresources"
[ -f "$userresources" ] && xrdb -merge "$userresources"

If you're using a display manager such as GDM, LightDM, SDDM, etc., then things can get more complicated. The unfortunate situation is that they can use one or more of a few different files. This answer on Unix & Linux Stack Exchange explains them better than I can. Honestly, if I were to use a display manager, I'd keep things as simple as possible by using x11/xdm and a ~/.xsession file containing just three lines:
Code: 
#!/bin/sh
xinitrc="${HOME}/.xinitrc"
[ -f "$xinitrc" ] && . "$xinitrc"

That way, everything remains contained in ~/.xinitrc. I tried to do the same with LightDM using the couple of files in this AUR package (modified to be FreeBSD-friendly), but I always ended up back at the login screen before DWM even started. Whatever the cause was, I gave up on it. Someone else might be able to help you better with GDM or LightDM or whatever; I prefer to just use startx.
 
sidetone said:
To see the differences of the files:
Code: 
diff .Xdefaults .Xresources
To merge text from one file to the end of the latter file:
Code: 
cat .Xdefaults >> .Xresources
Use both >> or it will overwrite, instead of amend to the file. 1 > will overwrite it. You can use notepad or type it out all manually, if you're worried about that. Then delete duplicate lines in the file.

Use
Code: 
ln -s .Xresources .Xdefaults
to link from .Xdefaults to .Xresources. .Xdefaults may have to be deleted for this to work.
Click to expand...

Well, the most simple solution found for now is creating .Xresources with all settings and linking as you say with .Xdefaults to avoid a double config mess. And Yes, I'm using startx only.

Code: 
ln -s .Xresources .Xdefaults


I'm going to try the memreflect suggestions too.
 
You can do the same for .xinitrc and .xsession as well. ln -s .xinitrc .xsession

If both are linked, the full permissions needed for both files is needed for the target file. ls -l ~/.x*

.xsession requires an additional read and execute attribute for group and owner (user).

chmod ug+rx .xinit
or maybe
chmod 554 .xinit

I'm unsure about the permissions for other, whether it needs to be the same, read only or none. None works for other if the user belongs to the right groups.
 
Here's what I noticed, Xresources is in /usr/local/etc/X11/xdm/, and it's referenced in /usr/local/etc/X11/xinit/xinitrc. Both point to ~/.Xresources, and to a file in their respective xdm or a nonexistent one in the xinit directory.

The Xresources file in /usr/local/etc/X11/xdm/ sets up the login screen for the login manager, and Xconsole. Xconsole is a program that often executes in the login manager, and it carries on into the desktop after logging in. Xinit logs directly in, and doesn't use a login manager.

I didn't find anything in these directories that points to any case of Xdefaults. There's a few references to .Xdefaults in the /usr/local/lib/X11/ directory.

grep -i .Xdefaults /usr/local/lib/X11/*/*
Code: 
app-defaults/XScreenSaver:! Though app-defaults files have (mostly) the same syntax as your ~/.Xdefaults
Binary file xdm/libXdmGreet.so matches

Interestingly, there's xmodmap(1) for keyboard settings referenced in /local/etc/X11/xinit/xinitrc, that points to ~/.Xmodmap.
 
Messing with .Xdefaults and .Xresources may have caused it not to log in after using the correct password on XDM. I got permission denied in .xsession-errors. If this happens, move/rename them with ".bk" on the end and see if that works. This seemed to correct the problem on mine. Then see if renaming them back and adjusting permissions works.
 
You must log in or register to reply here.
Back
Top