Hey, can you use another service since Lufi seems not getting best results for the image (https://postimages.org/). For your question:

All the named desktop-environments are depending mandatory onto D-Bus.
You can install different window-managers or Lumina in a whole as supported desktop-environment without D-Bus. Here is a possible image how this can look:

Hello good person))

Thank you for supporting the topic and thanks for the photo, I think your desktop photo would be better than this)) I thought how to do it (attach a photo) when I wrote a message, where is this function? . I used https://lufi.ethibox.fr because this service does not have google scripts, in the one you offer trackers and google scripts. I've attached links below, take a look.

https://upload.disroot.org/r/YG2jFHeh#I … Fmv/+1xco= 

https://upload.disroot.org/r/WqRsrjtZ#R … FaTAcgBos=

https://upload.disroot.org/r/Ey7q2UrJ#R … TrPR34spg=

https://upload.disroot.org/r/42bv2D5U#E … kY2Uz1kZM=

As far as desktop customization is concerned, I know that all of the desktops listed have a dependency on Dbus.

I would like this topic to be dedicated primarily to setting up the desktop and not the window manager. For example, the user downloaded the distro as in my example and then configured the . So any user who downloads Ht will come here on the forum to look at the instructions and quickly set up their desktop.

I thought I wouldnt, because:
1. Embarassingly, I can't provide the dotfiles. I gave that pc to my nephew and haven't made a copy of the settings... My current machine runs on devuan because I'm using some notably hyperbola-incompatible software like nodejs, though I hope to daily drive hyperbola at some point. I'm confident the desktop works fine, but I don't wanna post stuff like "here's what I use" because that's just not true.
2. Hyperbola ships very old build of pekwm, so I compiled the git master myself, among other things. The whole thing's not terribly reproducible, and definitely not with simple instructions. So again, I don't wanna go "here's my hyperbola" because that's misleading.
I showed off the thing on fedi, maybe bother me there with questions specific to this particular screencap. https://eientei.org/notice/AQuEutiH5mEdgzWT9E
I'm happy to help with more general desktop matters right here though. Tint2, menu-driven wms, dzen2 scripts, all the crunchbang type goodness, I got you. (crunchbang/busenlabs forums are a nice resource for these by the way, though largely hyperbola-incompatible)

Such matters would likely be better served by a proper guide and discussion in the desktop subforum, or a wiki article. I should do something like that, I enjoy setting up desktops... Need a new hyperbola pc first though.

I have some strong opinions on this, which I hope to keep to myself... It's trivial to go full hyperbola and never look back, but there's a right way to do that and not lose precious money too, and I hope to do that.

1. Ever an issue! tint2 lets you create arbitrary command lunchers, do that. use a text editor or tint2config.
One matter is creating the apps menu. Will be slightly different depending on your wm, sinc it's mostly these that handle the menus. Here's a relevant thread on busenlabs forums - again, keep in mind, largely hyperbola incompatible. https://forums.bunsenlabs.org/viewtopic.php?id=3387
I, like many people, can't really bother with making sure dynamic menus work, so I just write my menu configs with my two hands and don't install new software for the following two years I use the pc. Check the linked thread for utilites for generating these through gui if you're not willing to write the whole thing yourself, there's a bunch for openbox, whcih you should be using if you're text-editor-illiterate.
Another matter is launching it from something else than right click... That's how most of these menu-driven wms handle menus, they just pop the unnavigable apps menu any chance they get (I'm talking about puppy linux jwm rn, but it'll be relevant to some other people too). I imagine that will suffice for most use cases, but if you need a taskbar button screaming START you'll want to either:
a) use the built in pop-menu functionality
pekwm does that! and I'm pretty sure openbox doesn't.
define AppMenu in config filed and bind this command:  pekwm_ctrl -a run "showmenu AppMenu"
pretty sure pekwm_ctrl is only a feature in the git master builds of pekwm... your wm might provide a similar wm control interface though. if so you should use that.
b) use xdotool to spawn the menu
I won't pretend I ever had to do that, but here's a relevant arch wiki article https://wiki.archlinux.org/title/Openbox
Basically xdotool lets you make executable scripts for keybinds, and you use that to launch menus from taskbar buttons. It's a whole mess and i'd reccomend just adjusting your workflow instead if you're stuck in that... or changing software.

2. you mean like the MATE volumes applet? that's a cool applet, but I just figured how to live without it... if your file manager is at least as good as spacefm, it should have a configurable mount script functionality, figure out how to make that work and don't forget to post the thing. if it doesn't... that's embarassing.
othwerwise, I've no idea what you mean. I just use fstab and manual `mount` commands for my storage management
for network connection, use dhcpcd, though ou may need to config wpa-supplicant outiside fo the gui. have't tried, all of my pcs use wifi drivers hyperbola won't run
for brightness, that's also always a bitch. but the good news is pretty much every applet uses the same sysfs interface, so if it doesn't work right now you'll fix it the same way as any other guy does. I don't know a good applet if that's what you're asking for, I just do xbacklight -set 50 and similar any time I need it.
and for the sound, sndio control is a travesty of it's own. I ended up linking it to alsa with some package and just using alsamixer... I think retrovol is an applet for that but I honestly have no idea.

3. use tint2config
4. use tint2config
don't wanna sound like a dick but really, just carefully read through the tint2config settings, it's all there. and if you don't use tint2config... start doing so it's a rare good config gui. can't really help with text files as I haven't touched these for this particular program.

yeah, that's a bunch of apps usefull for any desktop. though I wasn't willing to do a pkgbuild of qt5-styleplugins, I was direly missing it... I have to learn proper pacman and arch type package management at some point. do post relevant links if you've got any, I'll read them.

wpa_supplicant and dhcpcd are add to the default run level not boot, so you will have to run these commands

rc-update add wpa_supplicant default
rc-update add dhcpcd default

but first you will have to remove them from the boot run level by using these commands

rc-update del wpa_supplicant boot
rc-update del dhcpcd default boot

Oh for sure the named thread is relevant as a "desktop" is quite more than those named environments. When you look at the memory those are consuming quite more memory and you can do it otherwise with all the packages Hyperbola is offering. You don't need  XFCE, LXDE, GNOME, KDE, MATE for any kind of working desktop!

Hyperbola GNU/Linux-libre and HyperbolaBSD won't support bloated Linux-only frameworks. That's the part and change for 0.4. And all the named desktop-environments are incompatible with this. But there is no further influence on a working desktop.

You await a working system right out of the box: This is not the goal of Hyperbola. Getting your own system under your control, getting the full control. For your backlight-point you can for example check this:

Check your

/sys/class/backlight

folder. If you can see an intel_backlight folder there and still you are getting the error

No outputs have backlight property

then creating a

/etc/X11/xorg.conf

file with the below configuration could work for you.

Section "Device"
    Identifier  "Intel Graphics" 
    Driver      "intel"
    Option      "Backlight"  "intel_backlight"
EndSection

There are different approaches to find out what errors are there and how to solve, including also to report back if something is missing within the packages with a tryout to rebuild them first local. Hyperbola is giving all those freedoms to do that, but it is a not a system running out of the box and has this also not also as a common goal. Besides: You have brought in this from my point of view strange part of retrospective about desktop-environments while a desktop is not defined by those. So either we start here doing that as you noted or this thread is about solving troubles.

Please read again: A working system NOT out of the box but surely working when following clear configurations. That is what I have written. And again: We would have integrated other flavors if they would be working without D-Bus. The point is next: What is unstable with Lumina? As I have also pointed out: Hyperbola is running stable but needs configuration for the own flavor to run.

Sorry, but at the point now you are again repeating the arguments I have already heard and have pointed out the reasoning.
To point at the guides you have linked. The first one:

rcctl enable messagebus ## enable dbus

And from the second one:

dbus_enable="YES" 

This will be the last time I mention it again: We don't support this framework and won't do it either.
Both links approve that there is no way around. So I just don't understand why you are concrete making those appointments. It is for everyone clear to read what Hyperbola is up to, what the goals of the system are and what we don't support. Hyperbola is not just another "distribution without systemd but with the rest convinience from Linux".

We can for sure include the information in the article about D-Bus.

I perfectly understand that Hyperbola does not support Dbus. Maybe I didn't explain correctly, I don't mean Hyperbola stability, I mean Lumina!

For example, do you know how to set up ? But others do not know and the most important information is not in the wiki. If we look at the wiki, we will see this

https://wiki.hyperbola.info/doku.php?id … na_desktop

The user will install Lumina and he will not be able to use the system!

In my examples, Lumix bugs are visible, as well as the absence of many important elements for daily use by the system.

Maybe for the sake of respect for your users, you should indicate this information in the wiki?

The question is: What kind of "important elements for daily use by the system" you rely on? Next to follow: Reporting the parts missing, so people can look behind. Again to clear up: We are not a big team so "donations" are helpful. And to clear the wording "donations": This is not money. It can be also adding missing information in the wiki / documentation, doing own packages and step therefore up as maintainer, approval and testing. When you demand something, please provide also information we can together build upon. We respect for sure the users! But we also ask for being respected back. Just to clarify: When we provide packages in the testing-branch, we need feedback! Without feedback in the forums or the issue-tracker, we can just use our experiences. When something is not working or something missing, there needs to be fixing or better documentation done together.

I understand when parts are missing, but the wording "bug in lumix" is so generic that I cannot do anything about . So you imagine: I would have to install Lumina, retest the behaviour or experiment with possible alternatives then to understand what possible solutions could be. This costs much more time and I am last but not least for the moment the only person here doing that as the rest of the team is in focus for HyperbolaBSD. Please also take into perspective that I get just more feedback in the back and I need nevertheless to approve that also. A bit of help with reports, a bit of help to sort that out or test ... is always welcome. I hope this helps also to understand quite better - besides I am not the author of the wiki-entry, so I would also need here to get into and adjust from the beginning.

EDIT: Here a concrete thread to sort out problems with Lumina ... https://forums.hyperbola.info/viewtopic.php?id=793
And we are for sure NOT doing what you have original implied in the thread, so I verify again: There is no ready to be used environment being installed in any way. Every window-manager and further basic package on that level needs more adjustment. We have nothing comparable towards Xfce and this will be my last message onto that desktop-environment. Please understand: I'm not willing to debate something we don't have and we also have no intention to build something in need for foul compromises. So can we stop compare towards those? That would be great. Thanks! On the opposite: Everyone is for sure invited to compile and test Xfce on Hyperbola GNU/Linux-libre 0.4. When you see a chance for feedback and getting a run without other packages? Please do it and feel invited. But our focus for version 0.4.3 stands and it won't contain any further new package. Also here to explain again: Every new package needs further porting when HyperbolaBSD is ready. When there are more people here having interest? Sure. Otherwise we have to stay at those we have and that's for reasoning having a stable and secure platform, because that's our foremost interest towards the community. That's our part of respect!

Yes, there are many other systems out looking different. Hyperbola is the one with strict principles and values towards free, libre culture and soft- / hardware. Is this something to bring us "plus points"? As it seems: No. What should  be interesting: To learn and emancipate. And this is a process being only possible when carrying experiences and information, best practice parts and advices, all together. When there is no interest in doing that, no interest in testing, the complete community behind free software should get back to construction and ask: How free do we really want to be? Because relying only on "ready to use"-environments is something very bad at a wide and concrete point.

I would like to shorten that a bit: Making a "donation" is used within Hyperbola here that users don't need to make financial support but can also donate information. So I see for sure the need and you can trust me for sure: As I have read the wiki-article yesterday I was already onto the point that this needs a rework. Nevertheless I wanted and want to point out that this system needs help from its community as it is surely designed the way being a fully common community-system.

One sentence to underline: By the community for the community! Nothing in between. So taking this with and seeing the need for a rework we have nevertheless a struggle as the team is not that big. So we need to cut out further "wished packages" for example. And we need to cleaning up, making a list:

1. First absolute stable releases, meaning testing the packages and all dependencies.
2. Fixing all the packages having issues because of earlier faults or problems - nobody is perfect.
3. Document the software.

Those three points in repeat so we have for sure now with the release of version 0.4.2 another good and stable system. As with 0.4 there was a complete cut for Hyperbola GNU/Linux as the earlier versions used a so-called snapshot taken. Something Parabola for example is doing nevertheless. Hyperbola has decided different as this would lead nevertheless to on-going problems. But with a complete redesign and a complete own build-structure and repositories other problems occur. Now we are independent but need for sure help and therefore the regular question about that also here. Our invitation stands up for to identify the issues and find solutions for them as said step by step.

For Lumina therefore as proposal in an own thread! But also to say it again: The decisions came up with a cost and this means we have no ready-to-use environment. We have nevertheless stable packages, designed on security-measures. And a system running stable low consumption of memory. But for a graphical interface there is more to be done by the users: We can help by documenting more and enhance that part.

Thanks for linking, surely an interesting idea also for a possible integration. Again I can renew the invitation: Feel free for a tryout. First for a local compile, next up for packaging with "makepkg" and also for releasing a PKGBUILD for the community to be shared and furthermore tested. As it is meant: By the community for the community!