|
|
Post by oblio on Oct 28, 2021 14:36:44 GMT
Leave us alone we have 32 gb of ram we like heavyweight distros...  Super funny, made my morning!
To health!
|
|
|
|
Post by simotek on Feb 23, 2022 10:00:25 GMT
... Like I say I was just curious if the two desktops (despite being so similar) would play nicely with each other?
Has anyone tried it?
Thanks.
As Moksha is currently coded it is a bit of a challenge to make the two desktops play nicely together. First of all they have to be installed to different locations. Even then you have the issue they both use the file /etc/enlightenment/sysactions.conf so you must ensure this file works with both e24 and moksha. Ok if you have made it that far then you have the issue of moksha's and enlightenments config files. By default this is at ~/.e in both cases. I usually just use a different user for each desktop. If you log into e24 using moksha's ~/.e folder e24 will 'trash it' and vice versa of course. There may be other ways of dealing with this issue. Then you have various other misc issues like which command enlightenment_remote runs when typed into a terminal. This will be determined by your PATH variable. Similarly if you compile Moksha or Enlightenment modules you need to consider which header files pkg-config will pick up on and if it is the wrong set of header files adjust your PKG_CONFIG_PATH.
I'm not sure if your using systemd yet, but if you are enlightenment ignores sysactions.conf and just performs the actions via systemd directly so that would be a solution to that problem. Likely the only sensible way to deal with the rest of the issues is to rename them to .moksha etc and whether this amount of effort is worth it probably depends on the number of people / distros that want to ship both, if it got to the point where distros were going to ship both alot then its probably worth fixing all the conflicts if not its probably not.
|
|
|
|
Post by simotek on Feb 23, 2022 10:20:36 GMT
Anyway, I hate the E24 systray. The module behaviour is written better on the shelf than our Moksha's one but in the background it supports appindicator over xembed protocol. It means many linux apps are not supported and can not see the icons on the tray. What I like in E24 is iBar with combined taskbar also with live app content preview. This is very hard to port to Moksha so maybe my another programming challenge. Unfortunately as I explained many times, all these Moksha changes are hand in hand with the theme scripting. It means I will need to add the feature into all maintained themes which increases my work load. Maybe I will think about it in BL 7 if not BL 8 era. Very hard to do. S These days due to wayland, KDE has also had to swap to appindicator only and i'm pretty sure xfce has gone that way as well so now if your distro is building everything right pretty much every application will support appindicator all Qt/KDE apps work out of the box as do Electron apps if the distro is doing it right, almost all Gnome apps have atleast a build time option for it including NetworkManager-applet, I frequently have 6-7 apps in my tray, the only thing I can think of that wont work out of the box is hexchat which I wrote patches for but still need to upstream them.
As for live previews that's something that is relatively simple if you have a compositor and probably near impossible without.
|
|
|
|
Post by ylee on Feb 23, 2022 20:23:26 GMT
I'm not sure if your using systemd yet, but if you are enlightenment ignores sysactions.conf and just performs the actions via systemd directly so that would be a solution to that problem. Likely the only sensible way to deal with the rest of the issues is to rename them to .moksha etc and whether this amount of effort is worth it probably depends on the number of people / distros that want to ship both, if it got to the point where distros were going to ship both alot then its probably worth fixing all the conflicts if not its probably not.
We are not using systemd for that but anyway on the name clashes I plan on dealing with that at some point. It is mostly grunt work that fixes no moksha issues. Just makes Moksha play better with enlightenment. |
|
|
|
Post by simotek on Feb 24, 2022 3:22:32 GMT
I'm not sure if your using systemd yet, but if you are enlightenment ignores sysactions.conf and just performs the actions via systemd directly so that would be a solution to that problem. Likely the only sensible way to deal with the rest of the issues is to rename them to .moksha etc and whether this amount of effort is worth it probably depends on the number of people / distros that want to ship both, if it got to the point where distros were going to ship both alot then its probably worth fixing all the conflicts if not its probably not.
We are not using systemd for that but anyway on the name clashes I plan on dealing with that at some point. It is mostly grunt work that fixes no moksha issues. Just makes Moksha play better with enlightenment. Yeah my point was more e24 / e25 enlightenment ignores whatever you used to configure there and just has a bunch of hard coded options it checks so you don't need to worry about sysactions.conf on later versions of e git.enlightenment.org/core/enlightenment.git/tree/src/bin/system/e_system_power.c |
|
|
|
Post by ylee on Feb 24, 2022 20:29:17 GMT
|
|
|
|
Post by simotek on Feb 24, 2022 22:58:03 GMT
Yeah I wasn't suggesting you should follow it, more that you don't need to care about sysactions.conf with respects to e and Moksha conflicting :-) |
|
Super funny, made my morning!
