- This topic has 62 replies, 12 voices, and was last updated Jan 29-5:52 pm by Wallon.
-
Posts
-
iznit
The new version the menu also does away with the “Help” sub-menu, making the menu a tiny bit simpler (for all those folks that complained antiX’s menu was “too bloated”).
Overall, I think the updated menu increases it’s usability, specially for people using antiX for the first timePlease rethink that proposal. No way does removing help increase its usability ((( especially for people using antix for the first time ! )))
Robin
@anticapitalista many thanks for your enlightening answer.
These users should answer No if they decide in the future to add new users (therefore keeping their chosen localisation)
For single user desktops (for want of a better word), it should not make any difference if user choose Y or N.Yes, I understand this, seeing the technical background of the /etc/skel concept. But I still think no user won’t expect the original language preset of a system will be touched by an update. So this concept does work properly only for English language systems, not on foreign languages systems and even worse on multilingual systems. All other languages need to copy manually the all files from /usr/share/antiX/localisation language subfolders to /etc/skel after the update in order not to change the original system behaviour when creating new user accounts later. Btw, all these localised files are actually updated by the packages, but people can’t know about this. They will only see coming up the language of a part of the antiX main menu in wrong (English) language on all future new accounts. No idea what is best strategy or how to prevent users from this confusion after system update. maybe /etc/skel should contain English content from the beginning, if an update in the main system language is not possible later. Then at least the behaviour would be consistent.
We need to find the cause of it where it has occurred. I’m not saying that it didn’t happen, but we can only fix this if we know how it happened.
Marcelo and me have yesterday used some time on checking and testing. To make it short: We were not able to locate the reason for the replacement. First we have made sure that not another package (e.g. updated icewm package) causes the language change of recent user’s menu by installing the single package using the command apt-get install desktop-defaults-icewm-antix only. This was enough to turn the menu of a recent antiX 22 system partly from pt_BR into English language.
Then, manually extracting all content from the three packages desktop-defaults-fluxbox-antix (0.6.0), desktop-defaults-icewm-antix (0.6.0), desktop-defaults-jwm-antix (0.8.0) and analysing it I can confirm these packages really only change the files present in /etc/skel to English language, while all the files in /usr/share/antiX/localisation are localised properly in the package. (Tiny issue: Folder name should probably read pt_BR instead of pt-br to keep consistency to debian locale). And you are right, I also don’t see any command in the control or preinst scripts which could cause the new untranslated English files from /etc/skel to reach user’s home folder. No way. But it still happens during this installation. Strange thing. Will need some further investigation.I tried el_GR, pt_BR, fr_BE with no loss of original localised menus.
Did you answer Y or N ? I also haven’t seen the language change myself of current user on an antiX 22 “de” system, but I answered N, which seems to make the difference. The N answer causes the files in /etc/skel not to be replaced by English ones, while they are replaced when choosing Y, so it is highly probably that the files are copied from there by some apt hook during installation process later. But I have not enough knowledge about all this packaging and installing stuff to trace it down finally, sorry. No idea where to look next. Checked the /usr/local/lib/desktop-session/desktop-session-update-wm-menus (which is obviously called by some apt-hook. for any hint whether it copies files from /etc/skel under some condition, but was not able to analyse it completely (would take me some weeks first to merely understand how the scripts of this scriptset interact and work in detail, so this issue needs to be checked by an aniX developer).
Here some significant lines from Marcelos install check of desktop-defaults-icewm-antix:
Available xsessions have changed Updating Slimski /etc/slimski.local.conf desktop-session-updating-wm-menus: Writing file: /usr/share/desktop-session/wm-menus/fluxbox-wm-menu desktop-session-updating-wm-menus: Writing file: /usr/share/desktop-session/wm-menus/icewm-wm-menu desktop-session-updating-wm-menus: Writing file: /usr/share/desktop-session/wm-menus/jwm-wm-menu desktop-session-updating-wm-menus: Writing file: /usr/share/desktop-session/wm-menus/RAW-wm-menuIn one of these might be hidden the answer.
Hope this helps to locate the reason for the language change in recent user by replaced files in /home from this package when Y is choosen to replace files in /etc/skel to an English-only update.
Windows is like a submarine. Open a window and serious problems will start.
PPC
Please rethink that proposal. No way does removing help increase its usability
I partly agree and partly desagree with that option:
– the default antix menu does look like it’s a bit too crowded, which can scare users that think it’s too complex- to it afects não usability per se, but regular, non techie User’s Experience (that’s some 95% of people).
– It’s handy having a kind of encyclopedia to search for help, even if 99% of users never take a look at it and end up asking very basic questions on the forum, or making strange assumptions (like: you can’t edit toolbar icons- yeah, I saw that on an Youtube “review”). My suggestion was moving the “help” submenu away from the first layer. Probably the best place for it would be it’s own entry on Applications?- but doing that implies some work, editing the default menus- and the Dev team may not be interested in that or consider it low priority)@anticapistalista:
I have a proposal for you, it does not solve this bug, but may make it simple for new users to correct it, when it strikes: Adapt the “Update menu” script so it offers 2 choices:
1- Update the menu (and, if this is not already solved, run the currently existing script with elevated privileges)
2- Fix localization of the menu- run a script that I propose to write, that finds out the user’s locale settings and copies the localized default menus to the window manager config files’s folders… I’m not sure when I can have that ready (or even if it would work, it would require some testing)- but it’s a simple and elegant way to solve this little but inconvinient bug.P.
The script I propose for the second part is something like this (untested):
#!/bin/bash #Script to automatically restore the first layer of the menu and the toolbar to the correctly localized, default versions -NOTE: this will reset any change you performed in the first layer of the menu or any icons you added to the toolbar #Get system language lang=$(locale | grep LANG | cut -d= -f2 | cut -d. -f1) #hack to fix languages that are identified by only 2 characters, and not 4 (or more) #comparing text that's before the "_" to the text that after that, converted to lower case, if it matches, use only the letters before the "_" l1=$(echo $lang |cut -d_ -f1) l2=$(echo $lang |cut -d_ -f2) l2_converted=$(echo "${l2,,}") if [ $l1 = $l2_converted ]; then lang=$l1; fi #Solve the problem caused by the Brasilian Portuguese not following the default way to refer to a locale if [ $l1 = pt_BR ]; then lang=pt-br; fi #TO DO: create a backup of all files that will be overwritten #copy the localized default versions of the menu and toolbar config files to the correct place in the user's home folder cp /usr/share/antiX/localisation/$lang/icewm/menu* ~/.icewm/ & cp /usr/share/antiX/localisation/$lang/icewm/toolbar* ~/.icewm/ cp /usr/share/antiX/localisation/$lang/jwm/menu* ~/.jwm/ & cp /usr/share/antiX/localisation/$lang/jwm/tray* ~/.jwm/ cp /usr/share/antiX/localisation/$lang/fluxbox/menu* ~/.fluxbox/- This reply was modified 3 months, 3 weeks ago by PPC.
anticapitalista
@PPC – quick reply to the second point.
It is our policy not to touch anything in the user directory.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
@anticapitalista- thanks for the quick response.
My proposed solution was meant to be a way to automatically “fix” the bug- and unfortunately, there are only 2 ways to stop to correct the damage the bug causes: figure out how it happens and fix the code (which I can’t do) or offer users an easy way to fix it (this can also be considered a “Reset Menu and toolbar” defaults Panic button, if the user crippled the menu by editing it and does not know how to restore it to a working condition). I won’t suggest it again!P.
anticapitalista
@PPC – if anyone wants to use your script that’s fine.
Packaging the script is also fine if all the deb does is install the script without running it.
What we don’t want is a case where installing a deb from our repo makes changes to the user home directory.Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Partly off-topic:
@anticapitalista – it just came to me – the script can (after completed and tested) be adapted to copy the localized config files to the skel folder – avoiding the situation where (even in cases where the bug does not “strike”, but after the user replies “yes” to changing the config files), when a new user is created, the menus are always in English. In this particular case, that adapted script should/could, in fact, be run automatically after updating the related packages.
I assume this suggestion works perfectly for systems that use only one locale. For systems where multiple users are created, with different locales for each one, it would not be ideal, since all users would get the menu and toolbar in the initial locale. To solve this (get the first layer of the menu and the toolbar in the local set for each new user), the only way I can think of (without heavy reworking the system) e using a variation of the script that would run automatically after creating a new user- not sure how to implement that, if that is even disable by the Dev team.
Sorry if I’m polluting the thread with this ideas, I’m just trying to think of a way both to mitigate this bug and avoid the problem with newly created users always getting menus/toolbars in English.P.
For systems where multiple users are created, with different locales for each one, it would not be ideal, since all users would get the menu and toolbar in the initial locale.
I believe this described behaviour is not that bad: Even a multilingual system is physically located in a destinct country, so it could be expected that it is set to this language on first system setup or at boot time in live mode as chosen by user (master language). So this behaviour can be considered as predictable, when new user accounts also on multilingual systems default to this very language. That would match precisely the desired (and obviously by now intended) behaviour for the /etc/skel mechanism: Before the update there is the master language of a system present in this folder. (Btw, your script will allow people on multilingual systems easily to switch to the language they need later, e.g. from within control center, which is great)
Only the update breaks this recent default behaviour, and replaces the content in /etc/skel by English versions of all files when saying Y, or gives opportunity not to update these files at all by saying N, which is an inacceptable choice both from users perspective. The selection should be made between file versions of same language, not between no update and switching to English.
So after some thinking about this issue I believe the best way to deal with it would be simply to make sure the proper language (as found at update time in /etc/skel on a system) is copied to the /etc/skel folder, instead of English. This would match the desired behaviour, the behaviour expected by most users: It would run seamlessly on English systems, also on single-language foreign language systems, and it would show acceptable, expected and predictable behaviour (from users point of view) on multilingual systems.
As said, we found the needed localised files are present in the packages. So what is missing is a logic within the package controlling scripts to take care to chose the proper system master language instead of English when copying files to /etc/skel.
So, something based on something like ppc’s script, modified to copy system master language to /etc/skel, instead of home, could be included to the package as a (post?-)install script possibly.
Another alternative would be not to put any translated files in /etc/skel from the beginning (read: original install or Live mode boot), so user must take care of translation by himself always when creating a new account, so the update from a package doesn’t break existing translation later unexpectedly while the needed localised files actually are hidden in the package updated. But I believe this is not what most users would welcome. (Ok, English language users excluded, they won’t even notice all the trouble…)
Windows is like a submarine. Open a window and serious problems will start.
marcelocripe
What we don’t want is a case where installing a deb from our repo makes changes to the user home directory.
As much as I consider this attitude to be a respect for the end user, it is still up to me to make some reflections.
If I answer “y” which is equivalent to “Yes” or “i” which is equivalent to “Install”, both in English, since it is not translated into pt_BR. So that’s why I want to install everything the package maintainer has to offer. If the most recent package was able to change the files of the first level menus and to change the files of the toolbars losing the pt_BR translation, then there must be some way to include a command that at the end of the installation process the copy is made from the files in the “/usr/share/antiX/localisation” folder to the “~/.icewm”, “~/.ijwm” and ~/.fluxbox folders.
But, if Debian’s policies don’t allow that, we can’t forget that it’s the same Debian that brings with it some of the problems we found in antiX, mainly those caused by SystemD and the other rubbish that ends with the letter “D” (Before from SystemD, the letter “D” in my language has never suffered so much from being associated with something bad). If antiX can fix this by making a copy without taking action from the end user, then this is still the best solution to the problem. And about “Debian policies”, these “policies” do not take into account Debian-based systems or what we want, which is nothing more than having antiX working well and with everything in its right place.
Thank you for correcting the folder name “pt-br” to “pt_BR” in the path “/usr/share/antiX/localisation”, I managed to notice this after the update on 01/22/2023.
– – – – –
What we don’t want is a case where installing a deb from our repo makes changes to the user home directory.
Por mais que eu considere esta atitude como sendo um respeito ao usuário final, ainda cabe a mim algumas reflexões.
Se eu respondo “y” que equivale ao “Yes” ou “i” que equivale ao “Install”, ambos em idioma Inglês, já que não está traduzido para pt_BR. Então é porque eu quero que seja instalado tudo que o mantenedor do pacote tem a oferecer. Se o pacote possui em seu nome “antix”, então eu confio e pode sim fazer as alterações necessárias na minha pasta do meu usuário. Além do mais, estas alterações são dos arquivos de configurações e precisam estar traduzidos. Se o pacote mais recente foi capaz de alterar os arquivos dos menus do primeiro nível e de alterar os arquivos das barras de ferramentas perdendo a tradução pt_BR, então deve haver alguma forma de incluir um comando que no final do processo de instalação seja feito a cópia dos arquivos da pasta “/usr/share/antiX/localisation” para as pastas “~/.icewm”, “~/.ijwm” e ~/.fluxbox.
Mas, se as políticas do Debian não permitem isso, não podemos nos esquecer que é o mesmo Debian que trás consigo alguns dos problemas que encontramos no antiX, principalmente os causados pelo SystemD e os outros lixos que terminam com a letra “D” (Antes do SystemD, a letra “D” em meu idioma nunca sofreu tanto sendo associada a algo ruim). Se o antiX pode corrigir isso fazendo uma cópia sem ter a ação do usuário final, então esta ainda é a melhor solução para o problema. E sobre as “políticas do Debian”, estas “políticas” não levam em consideração os sistemas baseados no Debian ou o que nós queremos, que nada mais é do que ter o antiX funcionando bem e com tudo no seu devido lugar.
Obrigado por fazer a correção do nome da pasta “pt-br” para “pt_BR” do caminho “/usr/share/antiX/localisation”, eu consegui perceber isso após a atualização do dia 22-01-2023.
Hi, @Marcelocripe
as far as I know, not overwriting user’s files in the /home folder is not a Debian policy, but an antiX policy.
I do not have anything against systemD – it seems to work for most Linux users out there, but made for light systems it’s not, so I’m glad that anticapitalista choose to stay away from systemD.The script I wrote to make available the new (localized) first layer of the menu has to be adapted, to work with the folder “pt_BR”.
There is a very good and valid reason for not using the new menu automatically – it would undo any change that the user made to the menu – for example: I did have a very customized icewm, with all Application Categories showing in the first layer of the menu, new applications pinned to the start of the menu, etc. I lost all that, when I choose to test the new menu. I suggest to anticapitalista that the “update” menu icon, on the first layer of the menu could summon a yad window, asking if the user wanted to update the “All Applications” sub-menu (that is what that current menu entry should now, currently) or reload the most up to date localized version of the first layer of the menu.
That way the user would not have to know how to copy the new config files to the right folder, nothing would be overwritten automatically when the system is updated but if the user wishes to use the new menu, it’s only 2 clicks away.P.
New version of the script to replace the current first level of the menus with the most up to date version of those menus:
#!/bin/bash #Script to automatically restore the first layer of the menu and the toolbar to the correctly localized, default versions -NOTE: this will reset any change you performed in the first layer of the menu or any icons you added to the toolbar #Get system language lang=$(locale | grep LANG | cut -d= -f2 | cut -d. -f1) #hack to fix languages that are identified by only 2 characters, and not 4 (or more) #comparing text that's before the "_" to the text that after that, converted to lower case, if it matches, use only the letters before the "_" l1=$(echo $lang |cut -d_ -f1) l2=$(echo $lang |cut -d_ -f2) l2_converted=$(echo "${l2,,}") if [ $l1 = $l2_converted ]; then lang=$l1; fi #TO DO: create a backup of all files that will be overwritten #copy the localized default versions of the menu and toolbar config files to the correct place in the user's home folder cp /usr/share/antiX/localisation/$lang/icewm/menu* ~/.icewm/ & cp /usr/share/antiX/localisation/$lang/icewm/toolbar* ~/.icewm/ cp /usr/share/antiX/localisation/$lang/jwm/menu* ~/.jwm/ & cp /usr/share/antiX/localisation/$lang/jwm/tray* ~/.jwm/ cp /usr/share/antiX/localisation/$lang/fluxbox/menu* ~/.fluxbox/I’ll try to write a slighter better version of this, to replace the current “Refresh/update” menu entry
- This reply was modified 3 months, 2 weeks ago by PPC.
Brian Masinick
Regarding any file changes in user directories, or anything other than system specific directories is something that is unusual, unexpected, and NOT typical of any Linux distribution that I am familiar with, and certainly NOT for either Debian or antiX.
As far as systemD goes, I tend to agree. On one hand, it’s a pretty intrusive design for a vital system utility that is typically designed only to manage the initial system startup process, “init”, and at most, a job scheduling process or “daemon”. SystemD goes well beyond this, ignoring typical UNIX and Linux design parameters to provide specific tools and library functions devoted to specific tasks and purposes. Instead, systemD includes a wide variety of system related functions. It works, but it is a major departure from the usual design. It was a big surprise when the Debian project decided to choose systemD to replace the original sysV scheduler. The intent was to choose a more modern scheduler to allow for parallel handling of initialization processes. SystemD does do this, but it brings along a lot of additional features. One of the init handlers that we offer in antiX, the runit init process, also starts the initial “init” process and starts parallel process management, but that’s it, and it has turned out to be a reliable, efficient successor to sysV. I’ve used it for quite a while now.
I’ve mentioned it before, but I’ll do it again: when Xecure was a contributor to antiX, he was a major contributor to the improvements to our runit configuration. Runit itself provides the scheduling tool and it has a framework available for administrators and integrators to design their own system start up procedures, but as far as I know, it does not provide an entire prepackaged configuration, at least I didn’t see one the last time I looked at it. Perhaps that is why Debian chose something else; they may not have had any available engineers to create a complete runit solution, though I do think that they offer the runit software in their repository.
Getting back to menu and user selections, using the standard conventions and accepting the default (press Enter) solutions to any questions that are asked is the safest (and therefore the default) method. Everyone is free to make their own decision; however each person should fully understand what they are doing before making a choice other than the default; otherwise they may be unprepared for unexpected and misunderstood changes. That is my personal recommendation as someone who has been using similar software for several decades. Even I generally take the defaults unless I’m doing functionality testing and expect to repeatedly replace and reinstall what I’m working with. My every day stuff is ordinary and conventional.
--
Brian Masinick
Dave
I have not read the last few pages.
Could someone who has experienced the issue please post the contents of
~/.desktop-session/desktop-session.conf and ~/.desktop-session/file_compare and /etc/desktop-session/file_compare?
I am thinking that the default file_compare files may have been changed from being blank (aside from an explanatory header and commented out examples) and the SESSION_PROTECT variable may have been changed to false instead of true (which does not matter as long as the file_compare file is blank or correctly configured).Normal update policy is to not touch the users home directory. This system was added as a way for the user to opt into automatic updates on files that they specify but I think the default configuration is likely changed and now incorrect. Hence why some may have the problem and others not depending on what configuration files were in /etc/skel when the user account was made.
- This reply was modified 3 months, 2 weeks ago by Dave.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
marcelocripe
Hello Dave.
Could someone who has experienced the issue please post the contents of
~/.desktop-session/desktop-session.conf and ~/.desktop-session/file_compare and /etc/desktop-session/file_compare?The attached file “desktop-session_pt_BR_01-25-2023.zip” is from the first antiX 21 full 64-bit SyVinit that was updated on 01/10/2023 and lost the translation of the files of the first level menus and the files of the bars of tool.
If you need these files that you requested from another antiX, I can send them tomorrow night after work.
– – – – –
Olá Dave.
Could someone who has experienced the issue please post the contents of
~/.desktop-session/desktop-session.conf and ~/.desktop-session/file_compare and /etc/desktop-session/file_compare?O arquivo anexo “desktop-session_pt_BR_01-25-2023.zip” é do primeiro antiX 21 full de 64 bits SyVinit que foi atualizado no dia 10/01/2023 e perdeu a tradução dos arquivos dos menus do primeiro nível e dos arquivos das barras de ferramenta.
Se for necessário estes arquivos que você solicitou de um outro antiX, eu poderei enviar amanhã à noite depois do trabalho.
Dave
Thanks Marcelo.
Indeed the default settings for the opt in automatic updates system within desktop-session is to blame for this.
If you do not want this system change SESSION_PROTECT to True in ~/.desktop-session/desktop-session.conf
If you want to automatically update the root menu with the latest root menu (and you do not modify the root menu) then I would say to change the lines for your window manager in ~/.desktop-session/file_compare from
icewm | /etc/skel/.icewm/menu | ~/.icewm/menu
to
icewm | /usr/share/antiX/localisation/YOUR_LANGUAGE/icewm/menu | ~/.icewm/menuComputers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
marcelocripe
Dave, should this have been done by the installation package at upgrade time?
If need be, I can do other tests if you can guide me in HexChat chat. For this to be possible, we will need to agree on a day and time that is appropriate for both of us.
– – – – –
Dave, isto deveria ter sido feito pelo pacote de instalação no momento da atualização?
Se for necessário, eu posso fazer outros testes se você puder me guiar no bate-papo do HexChat. Para isso ser possível, nós precisaremos combinar o dia e horário apropriado para nós dois.
- You must be logged in to reply to this topic.
