Other CDE Users Unite!

Yeah, I knew that. I guess I should have been more clear, I was really asking if dbus was really needed for CDE to interact with "modern" technologies. For example, librewolf complains about not being able to talk with dbus when run from the terminal.
Oh right. CDE doesn't need dbus but software like librewolf might need it. If its similar to firefox, it should work without. I think it uses dbus for some filesystem stuff.

Though note that CDE has no idea how to even use dbus (as you know, it didn't exist back then) so there won't be any comms through it. Building CDE doesn't pull in i.e libdbus for example.
 
<sigh> dbus and the like are a reimplementation of an old concept. The mainframe had (MVS) and has (zOS) the subsystem interface. Messages are passed to a function which in turn calls all its subsystems (apps that have registered with it) callbacks to notify it of the event/data. Unfortunately for UNIX/Linux, there was no one standard. It's the Wild West here.
 
Another question: on my dual monitor setup dtlogin always starts on the laptop panel despite that in my sessionsetc I set up the external monitor as primary. Is it possible to change this behavior?

But the weirder thing is that after resuming from suspend only the laptop keyboard can be used to input the password, every other DE I tried could use the external keyboard just fine.
 
Is it possible to change this behavior?
Since I don't use a displaymanager myself, and I'm not sure which comes first dm, or X, and what overrides what, so my answer may not solve your issue, but you can use xrandr(1) to define a primary monitor (see section "RandR version 1.3 options")
 
Since I don't use a displaymanager myself, and I'm not sure which comes first dm, or X, and what overrides what, so my answer may not solve your issue, but you can use xrandr(1) to define a primary monitor (see section "RandR version 1.3 options")
Yeah, I have a xrandr command in my sessionsetc that works just fine but it's executed after dtlogin, therefore it is of no use in this case. I'll see if dtlogin can be customized but it's no big deal in any case.
 
Yeah, I have a xrandr command in my sessionsetc that works just fine but it's executed after dtlogin, therefore it is of no use in this case. I'll see if dtlogin can be customized but it's no big deal in any case.
:-/ Well, it's completely up to you, of course, but maybe it's worth just a try (edit one line in two files each), and maybe leads to a satisfying solution for you:
As I said, I don't use no DM. My ~/.login simply ends with exec startx &
The rest (xrandr) is in ~/.xinitrc, of course:
Code:
[...]
default .xinitrc stuff
[...]
#my xrandr line
xrandr --output HDMI-0 --mode 1920x1080 --rotate......

# numlock be used as numlock by default
numlockx &

# start my WM:
fvwm # must be 'cde' here?

# gimme sound!
mixer vol 100:100
mixer speaker 100:100
mixer mix 100:100

This way I don't get a nice "welcome screen" when I start my machine up, but the default TTY login, and when I login (as user), then X and my WM is started.
I can abstain of (the to me) pure optical frills. As I said: If you see it otherwise, okay. It was simply a suggestion. You don't need to deal with DM setups, but "just" with X, and CDE.
Maybe it works, to change your primary monitor, maybe it won't. Maybe you say, 'that's more I like it', maybe you say, 'Nah, I prefer the other way.'
 
:-/ Well, it's completely up to you, of course, but maybe it's worth just a try (edit one line in two files each), and maybe leads to a satisfying solution for you:
As I said, I don't use no DM. My ~/.login simply ends with exec startx &
The rest (xrandr) is in ~/.xinitrc, of course:
Code:
[...]
default .xinitrc stuff
[...]
#my xrandr line
xrandr --output HDMI-0 --mode 1920x1080 --rotate......

# numlock be used as numlock by default
numlockx &

# start my WM:
fvwm # must be 'cde' here?

# gimme sound!
mixer vol 100:100
mixer speaker 100:100
mixer mix 100:100

This way I don't get a nice "welcome screen" when I start my machine up, but the default TTY login, and when I login (as user), then X and my WM is started.
I can abstain of (the to me) pure optical frills. As I said: If you see it otherwise, okay. It was simply a suggestion. You don't need to deal with DM setups, but "just" with X, and CDE.
Maybe it works, to change your primary monitor, maybe it won't. Maybe you say, 'that's more I like it', maybe you say, 'Nah, I prefer the other way.'
Take a look at this post:

 
OK. I never really dealt with any DM. Don't know in which file this thing is started, how it interferes, or if you have to deinstall it first... I'm no top-down, but a bottom-up kind of guy: starting on a white, empty sheet of paper, think of what I need, look for the quickest, and most easiest was to get there, and when it works I'm satsified with what I have. :cool:
 
2025-12-15-135846_3840x1080_scrot.png


My current CDE setup, very happy with this. However, my OCD is telling me something's wrong with XCalc as the "divide" character is not showing along with the middle character in the top row (which should be the square root).

Can anyone help me?
 
An even better solution: add those lines to ~/.Xresources:

Code:
!===============================  X  C  A  L  C  ===================================================================
XCalc.ti.button3.label:  SQRT
XCalc.ti.button21.label: PI
XCalc.ti.button35.label: /
!===================================================================================================================

2025-12-17-182927_226x394_scrot.png
 
This is super dope. Just installed xlibre & cde-devel using pkg and followed the instructions from the pkg-descr and it works!
 
Threads like this make me grin, feel happy. All the fancy new age DEs that need tons of resources and "along comes CDE" One can argue/discuss the visuals, but when things work :)
 
Threads like this make me grin, feel happy. All the fancy new age DEs that need tons of resources and "along comes CDE" One can argue/discuss the visuals, but when things work :)
Speaking about resources: yesterday I replaced LibreOffice with OpenOffice (devel) and thus got rid of pulseaudio and pipewire completely.
 
Because it doesn't have enough people to work on it and is kind of a security problem? Seems legit...
Are we talking about OpenOffice, CDE or FreeBSD? I think all would fall into that "problem" I suppose.

I guess the advice of "don't sit there stark naked on the internet or eat things off the floor" apply.
 
Are we talking about OpenOffice, CDE or FreeBSD? I think all would fall into that "problem" I suppose.

I guess the advice of "don't sit there stark naked on the internet or eat things off the floor" apply.
I believe he's asking why there has been pressure to remove OpenOffice from other platform's repos. BTW, I'm curious to know that too.
 
I'm curious to know that too.
Me too. Though, rather than any technical reason, I suspect it is lobbying from The Document Foundation squeezed by Collabora to move people towards their product. Note: Collabora is just a cleaned up LibreOffice with commercial support.

Related to Red Hat removing Open/Libre from their official repos as an agreement with Collabora to help push adoption of their "enterprise" office offering. If the free offering was official and supported by their OS vendor, companies would have just settled with it and the free offering would have the monopoly. Now it enables Collabora to be back in the running to make a tidy profit.

Similar with the community branding introduced a number of years back to encourage large enterprises to avoid vanilla LO. Luckily it looks like they are undoing that.

Just a hunch ;)
 
I see, I didn't know any of that, thanks. However, I feel to see anything OpenOffice related in those two links, I'll dig it further in the next few hours (it's 3AM here and I just woke up).
 
How I finally got rid of dbus and related stuff under CDE

Besides the obvious dbus_enable="NO" in /etc/rc.conf, there are apps that "think" they rely on it and invoke it every time. In my case it was librewolf: at every login I found three processes that were dbus-related:
  • dbus-launch;
  • dbus-daemon;
  • at-spi-bus-launcher.
Getting rid of the third one was easy, it's a service started by dbus itself and therefore it's mask-able. This took care of it:

Code:
[6:29][fmc000@dabrafenib ]$ cat .local/share/dbus-1/services/org.a11y.Bus.service                                                                                                                               ~
[D-BUS Service]
Name=org.a11y.Bus
Exec=false
SystemdService=at-spi-dbus-bus.service
[6:29][fmc000@dabrafenib ]$

To stop the "proper" dbus processes from running just removing completely ~./dbus/ wasn't enough, I also had to link ~./dbus to /dev/null and remove ~/.cache/librewolf and logout. Now when librewolf starts I have no dbus processes running.
 
Chromium does not require dbus but firefox does those as user's process.
However almost certainly disable the components that involve root.
I have started CDE from startx and only the service rpcbind_enable="YES" running. This caused three open ports. I have basic IPFW "workstation" firewall enabled also. Some users here use CDE as regular basis. So I can hope that above firewall is enough for home users also.
 
Back
Top