Understanding desktop-session-antix

[Forum Admin Dave]

Helpful

Up

0

::

The menu-applications are regenerated in desktop-session from lines 222 – 236.
I think the main menu is initially set in live init. Then it is altered in the installer to remove the installer entry.
Perhaps it is also still in the control centre for when you change your locale from there but it has been quite a while since I have looked in there. It *used* to be (from my memory) when you changed the locale via a gtkdialog it would change the locale, keyboard layout, and copy the menu from /usr/share/* to ~/.wm/menu, then rebuild the applications menu.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Xecure]

Helpful

Up

0

::

Thanks, Dave.

I thought that, when changing the locale (in /etc/default/locale), rebooting, and then creating a new user, the menus would be in the language selected, but I couldn’t get this to work. I wanted to see if the user-antix or desktop-session would automate the change but to my surprise it didn’t, so I though maybe I did something wrong.
Can anyone confirm that this is the normal behavior (loading a localized menu for the new user) or if I had false expectations?

If this wasn’t the default behavior, I will send a merge request to desktop-session-antix to include this function.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Forum Admin Dave]

Helpful

Up

0

::

I think there is no longer a method for changing locales post install without alot of manual steps.
Ah, this was set years ago in the antix-system management program (line 258-298).
https://gitlab.com/antiX-Linux/system-antix/-/blob/master/bin/antix-system.sh
It seems in the past I was trying to move to python instead of gtk dialog but did not get very far at all (was spending time on user-management-antix/group-management-antix IIRC).
https://github.com/antiX-Dave/antix-system/blob/master/antix-system

Is desktop-session the place to handle this? Should it be moved to desktop-menu and linked from desktop-session instead?
The live-init system would need to be investigated as it is likely far better at setting up the locale than was done in the past via antix-system, etc.

Edit:
Also in the past is was frowned upon to alter certain aspects of the user’s home directory.
So we will need to keep in mind if the system locale is altered that we do not override / overwrite any custom changes in the home directory.

• This reply was modified 1 year, 7 months ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Xecure]

Helpful

Up

0

::

Thanks, Dave. I will start looking at what you have linked.

Dave wrote:

Is desktop-session the place to handle this? Should it be moved to desktop-menu and linked from desktop-session instead?

Yes. You are right. This is a better place for it.

Dave wrote:

Also in the past is was frowned upon to alter certain aspects of the user’s home directory.
So we will need to keep in mind if the system locale is altered that we do not override / overwrite any custom changes in the home directory.

You are right. I was thinking not to do this automatically, only on first desktop-session launch for a user, but if the user has a custom /etc/skel/.<wm>/menu, then this “forced translation” is a not desirable at all. I will have to think about it. Maybe only include this option in the locale-antix script I am making.

Thanks for pointing me in the right direction.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Forum Admin Dave]

Helpful

Up

0

::

Xecure wrote:

You are right. I was thinking not to do this automatically, only on first desktop-session launch

Indeed then should we make it part of the desktop-menu package and have a hook in /usr/lib/desktop-session/first-run-script to update the locale of the menus.
Subsequent changes should then be allowed/enabled via running the same code via a desktop-menu script/option manually. After changing system locale, or accidentally installing using the wrong locale for example.

There is a section in desktop-session that does not get much use. It allows the program/package maintainer to update/notify the home directory files if given user consent to do so.
This is found on lines 255-287. It corresponds with the SESSION_PROTECT option in desktop-session.conf. Items are set in /etc/desktop-session/file_compare with overrides in ~/.desktop-session/file_compare IIRC. Though this may be outdated information. Basically ~/.desktop-session/file_compare was meant to store the files that you do not want to update to avoid annoying nagging if SESSION_PROTECT is set to ask. It *might* be useful for this situation, but also maybe not.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Xecure]

Helpful

Up

0

::

Thanks, Dave.

Dave wrote:

SESSION_PROTECT

When I was reading the desktop-session code, I always feared touching this would be too dangerous, so I am not too keen on introducing bugs as I did in another project. For now, I will see about including the script in desktop-menu-antix and perform a few tests calling it from outside manually.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

Is it solved by by just modifying the desktop-session script? It could consult $LANG and, unconditionally (without regard to wm or min-*, nor first-run status) call desktop-session-menu “– update global”

(I don’t know: Does the menu update operation take a looooong time to complete on low-spec systems?)

[Forum Admin Dave]

Helpful

Up

0

::

desktop-session already calls desktop-session-menu –update-global based on a change to LANG; generally by live init. (/etc/live/config/lang or ~/.desktop-session/lang)
This changes the applications menu (filename: menu-applications) and regenerates it to the selected language. This can also be changed at a later time without too much issue as the standard applications menu is known to auto generate (or a least that is what is intended so apt automatically adds the installed applications to the menu) Though this too can break between 2 users as the applications menu is a symlink to /usr/share/desktop-menu/* and if you have 2 users with different locales then they should remove the symlink and keep local copies.

The main problem (I think) is that this is not where the root menu (filename: menu) is changed. It is set in live init and / or install and is not touched afterward, generally because this is a static menu that is regularly altered by the user. As noted this causes problems as /etc/skel is not altered for the locale; nor is it when the system locale is changed and/or a second user uses a different locale. Then the localized menu file (and probably the other window manager files) would need to be manually copied over after adding a fresh user.

• This reply was modified 1 year, 7 months ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member stevesr0]

Helpful

Up

0

::

After installing and reinstalling desktop-session-antix, I still lack files in the home directory. I have all the other desktop-session and .desktop-session files that exist in other directories on my system running Antix 19.

This system is a Sid version that I deliberately installed minimally and have been adding applications as I needed/wanted.

After the reinstall, I notice that in the /etc/xdg/menus/ there is no applications.menu file, only an lxde-applications.menu. In addition, there is debian-menu.menu file which is only a symbolic link to a file /var/lib/menu-xdg/menus/debian-menu.menu. However, when I try to examine the latter file, neither it nor it’s directory (menus) nor the /menu-xdg directory housing /menus exists according to ls.

Appreciate suggestions on what further to do to diagnose what is improperly installed or missing.

Thanks in advance.

(Amazed that so much is working with this messed up.)

stevesr0

[Forum Admin Dave]

Helpful

Up

0

::

stevesr0 wrote:

After installing and reinstalling desktop-session-antix, I still lack files in the home directory. I have all the other desktop-session and .desktop-session files that exist in other directories on my system running Antix 19.

The installation done via apt/dpkg does not (or should not) touch the home directory. So this makes sense. You will need to copy the files found in /etc/skel.

stevesr0 wrote:

This system is a Sid version that I deliberately installed minimally and have been adding applications as I needed/wanted.

After the reinstall, I notice that in the /etc/xdg/menus/ there is no applications.menu file, only an lxde-applications.menu. In addition, there is debian-menu.menu file which is only a symbolic link to a file /var/lib/menu-xdg/menus/debian-menu.menu. However, when I try to examine the latter file, neither it nor it’s directory (menus) nor the /menu-xdg directory housing /menus exists according to ls.

This is not part of desktop-session, it will require installing deskop-menu-antix.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member stevesr0]

Helpful

Up

0

::

Hi Dave,

Thanks for the comments.

I did have desktop-menu-antix installed.

My desktop-session directories and files were not matching the ones in antix 19. I have tried to remove and to reinstall the desktop-session-antix package, but that is blocked by an error involving a file that apt looks for and cannot find (/usr/local/lib/desktop-session/desktop-session-login-manager.sh). I made a dummy file with that name and location, but that didn’t changes the error.

I will keep trying to force these programs off so I can maybe properly install them <g>.

stevesr0

[Member stevesr0]

Helpful

Up

0

::

Hi all, Dave pointed me towards two files that were causing the problems (99-update-loginmanager and 99-update-menu) and after removing them, apt is updating fine without error messages.

These files are apparently unnecessary because I don’t use a login manager, just startx.

I also don’t have desktop-session-antix, or desktop-menu-antix; only apt-antix and desktop-defaults-net-antix. I am not sure what I am missing out on, because my Openbox-based graphic system seems to work ok.

stevesr0

[Forum Admin Dave]

Helpful

Up

0

::

Just a post for an update.
Newer versions of desktop-session had some update changes (for example to xdg environment setup).
Along with this you can also have a mirror to the startup file being a shutdown file (~/.desktop-session/shutdown and/or /etc/desktop-session/shutdown).
I have used this for clearing temporary files, cache files, and saving

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member ModdIt]

Helpful

Up

0

::

Along with this you can also have a mirror to the startup file being a shutdown file (~/.desktop-session/shutdown and/or /etc/desktop-session/shutdown).
I have used this for clearing temporary files, cache files, and saving

Thanks for info Dave, may I be so cheeky and ask for example here, this is especialy good clearing temporary files, cache files, and saving.
Any user with chrome based browser can have multi Gigabyte Cache build within an hour or so. Chromium leaves that pretty much forever,
in any case until it risks crippling a system. One gigantic supercooky mess as serviceworkers can be used to follow visitors by referencing cache content
at every revisit, by sites sharing data across sites..Why do many companys have hundreds of domains, tracking and obscurity.

[Forum Admin Dave]

Helpful

Up

0

::

ModdIt wrote:

Thanks for info Dave, may I be so cheeky and ask for example here, this is especialy good clearing temporary files, cache files, and saving.

Basically the same as the snapshot excludes is a good place to start. Keep in mind that whatever you add will increase the shutdown/logout time. So if you have multiple GB worth of cached data, you will probably want to remove them manually the first time. Then with regular use (multiple logouts/logins) it should be kept small enough not to cause a significant speed problem. Another way is to move them to a trash location rather than remove them; then remove them when you do not mind waiting.

$ cat ./shutdown 
rm -r $HOME/.cache/mozilla/30as99eb.Junk
rm -r $HOME/.mozilla/firefox/30as99eb.Junk
cp -r $HOME/.mozilla/clean/30as99eb.Junk $HOME/.mozilla/firefox/30as99eb.Junk
rm -r $HOME/.cache/mozilla/f74jq05y.Default
rm -r $HOME/.mozilla/firefox/f74jq05y.Default
cp -r $HOME/.mozilla/clean/f74jq05y.Default $HOME/.mozilla/firefox/f74jq05y.Default
rm -r $HOME/.cache/chromium
rm -r $HOME/.config/chromium
rm $HOME/.config/hexchat/logs
rm $HOME/.bash_history
rm $HOME/.lesshst
rm $HOME/.python_history
rm $HOME/.local/share/recently-used.xbel 
rm $HOME/.local/share/Trash
rm $HOME/.Trash
#mv $HOME/.xsession-errors $HOME/.desktop-session/xsession-errors-$(date +"%Y-%m-%d_%H-%M")
rm $HOME/.xsession-errors

Another thing to note (That I am not sure is common knowledge):
After you are happy with your startup / shutdown files you may wish to make them immutable.
Log in as root in the users ~.desktop-session directory and run

chmod 544 shutdown && chattr +i shutdown
chmod 544 startup && chattr +i startup

Then when you need to make an edit

chattr -i shutdown && chmod 744 shutdown
chattr -i startup && chmod 744 startup

Of course you can leave the permissions at 744 and only make it immutable instead.
This prevents someone pulling a prank on you and adding a nasty rm -r $HOME when you are not looking. Unless they know your root login in which case you have bigger problems (or your user password depending on sudo configuration).

• This reply was modified 1 year, 4 months ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Author]

Posts