antiX-23.1 released

Forum Forums News Announcements antiX-23.1 released

  • This topic has 218 replies, 25 voices, and was last updated Mar 13-5:33 pm by Stéphane Ascoët.
Viewing 15 posts - 181 through 195 (of 219 total)
  • Author
    Posts
  • #135536
    Member
    Stéphane Ascoët

      … And hey, Fluxbox users lived without toolbar buttons and even without a toolbar “Menu button” until antiX 23 came out! Software keeps evolving, even old style window manager like Fluxbox, that seems stuck in a permanent beta for about a decade!

      P.

      What do you call “Menu button” ? I’ve always seen an equivalent to m$ “start” in AntiX…

      #135538
      Member
      PPC

        What do you call “Menu button” ? I’ve always seen an equivalent to m$ “start” in AntiX…

        Not in “Fluxbox” window manager you didn’t… The window manager I was talking about is literally in the sentence you quoted!

        P.

        • This reply was modified 2 months, 3 weeks ago by PPC.
        #135540
        Member
        PPC

          Thanks to the recent discussion, here in the forum, I reworked Fluxbox’s “init” configuration file, so it usualy processes better the clicks in the “Menu” button. The “show desktop” button works as it should (many thanks for the code!!)! I also added most of the default buttons antiX has in IceWM: skippy-xd, antiX-Updater; Package Installer; Web Browser; File Manager… and near the system tray, where god intended it to be, the “eject USB device” button, and after the clock, a “power off button”.
          If this configuration works for everyone (tested only on antiX 23.1 64bits FULL Live), most people would be able to live comfortably in Fluxbox, without the need to use the menu that often.
          The configuration file includes, on the end, examples of glyphs that can be used and those that can’t be used. There are perfectly good glyphs that can serve as “buttons” for a search app, such as Finder or Searchmonkey, etc… The “@” character can be used for e-mail clients, “$_” can be used for the terminal, etc…

          Any Fluxbox user can test this proposed init file. Please do back up your initial init configuration!!!

          P.

          • This reply was modified 2 months, 3 weeks ago by PPC.
          • This reply was modified 2 months, 3 weeks ago by PPC.
          • This reply was modified 2 months, 3 weeks ago by PPC.
          Attachments:
          #135546
          Member
          PPC

            During my coffee break (or, as anticapitalista would put it, during my tea time), I played a bit more with fluxbox configuration file.
            I found the initial “menu button” settings more reliable, so I’m using the original values.
            I also changed the browser button and added 2 new ones: finder and (next to the system tray) a button to launch Connman Conection Manager. This buttons, of course, don’t have to be included in any Fluxbox default configuration. But the fact that their code is present on the init file makes it much easier for users that want to add those buttons: they just have to insert then in the “session.screen0.toolbar.tools:” line, right where they should be displayed.
            This is the first time I use glyphs in Fluxbox, without installing extra fonts. Not having real quicklaunch icons can be a drawback for most modern window manager users. At least the 2 (usually) most used apps: Web browser and File Manager, now have (a somewhat) familiar icons on the toolbar. I do like the “exit button” on the right of the toolbar. It’s something I miss on IceWM… It’s logically placed, right on top of my screen’s “Power button”.

            I also changed the default size of entries in the taskmanager section of the toolbar, so the window titles don’t take all the available space, and made it look a bit more familiar, to users of other OSes or Window Managers (like IceWM).

            I think I’m done playing with Fluxbox… Back to work…

            P.

            • This reply was modified 2 months, 3 weeks ago by PPC.
            #135578
            Member
            marcelocripe

              anticapitalista wrote:

              I have the latest control centre mo from @marcelocripe , but it does not solve the localisation issue of the control centre.

              and

              Robin wrote:
              @anticapitalista Will try to find out what’s causing it. Nothing happens ever without a reason. I’m going to fetch the latest pt_BR .po file from transifex and start aCC in pt_BR language then.

              I would like to thank all of you who took the time to try to understand why the Control Center has an empty space to the left of all the options for each category in the “pt_BR” language.
              I may include some line breaks to try to minimize the problem. But as I don’t know which sentences would need to include some line breaks, it’s difficult to guess where to add or not add the line breaks.

              – – – – –

              anticapitalista wrote:

              I have the latest control centre mo from @marcelocripe , but it does not solve the localisation issue of the control centre.

              e

              Robin wrote:
              @anticapitalista Will try to find out what’s causing it. Nothing happens ever without a reason. I’m going to fetch the latest pt_BR .po file from transifex and start aCC in pt_BR language then.

              Eu agradeço a todos vocês que se importaram em tentar compreender o motivo do Centro de Controle ter um espaço vazio a esquerda de todas as opções de cada categoria em idioma “pt_BR”.
              Eu posso incluir algumas quebras de linhas para tentar minimizar o problema. Mas como eu não sei em quais frases seriam necessárias incluir algumas quebras de linhas, fica difícil adivinhar onde adicionar ou não as quebras de linhas.

              #135593
              Member
              Robin

                But as I don’t know which sentences would need to include some line breaks, it’s difficult to guess where to add or not add the line breaks.

                Hello Marcelo @marcelocripe
                It’s explained already in my above analysis of the issue, if you read between the lines: First check all the tab entries (see dev notes to identify them). Make them half the length of what the longest of them currently is. I’m not sure whether the tab entries accept formatting codes like line breaks. You’ll have to check this out.

                Then check the Button engraving entries. (Also here see dev notes for identification; they are all marked). And also here I’m not sure whether linebreakes actually do work. Just check it out. Simply start with the longest ones of them. Then the next shorter one, and so on.

                Tooltips entries are not critical, these neither accept nor need line breaks or shortened text. On the contrary, you can write into these as much text the screen can take. So, I’d suggest to move all the pieces of information not fitting into the Buttons simply into the tooltips, then everything will be fine.

                You know how to speedy make .mo files for testing the layout from the .po file you are working on, so you can easily check after each next change, whether this change bestowes the desired result on you already or not.

                Windows is like a submarine. Open a window and serious problems will start.

                #135611
                Member
                PPC

                  And also here I’m not sure whether linebreakes actually do work

                  I’m not 100% sure, but when I was adapting IceWM Control Centre to gtk-dialog, I think I tested line breaks in, at least button’s text and it failed to work. I think that probably also will not work for tab’s text, but yes, try it out.
                  The advise of trying to cut down the biggest text and then checking if CC looks as it should, and if not do the same to the next biggest text string is the best way to locate the problematic text strings.
                  In what concerts tab’s titles- the german first entry has 18 characters (and no space) and CC looks perfect. @Marcelocripe – please check out just removing the space in the tab title in “Área de Trabalho” (I think it’s the name of the first tab)… In pt, it’s simply called “Ambiente” (oh, and yes, portuguese speaking people do understand that means “Ambiente de Trabalho”, without having the complete expression on the tab’s title. Unfortunatly, the pt-br expression “área de trabalho” can’t be shortned that way, saying just “Área” would make no sense at all.

                  In what concerns button titles, the biggest one I could find (and that does not mess with the way CC is supposed to look) is in pt-pt : “Ajustar as Camadas do Misturador do Servidor de Áudio Pipewire”… that’s quite a lot of text, and still, in pt-pt, it does not affect the window’s layout…

                  I hope this tips can help Marcelo save some time…

                  P.

                  #135614
                  Member
                  PPC

                    On Control Centre – I have one possible proposal:

                    Currently CC is extremely complete. In particular in IceWM and in the Runit antiX version, it allows for completely GUI ways to manage just about all important setting of the OS (well, ds-mouse is currently being adapted to work perfectly once again), except for one, that already has a GUI that is not included in Control Centre: Editing antiX’s startup file. Yes, users can manually edit it from inside CC, but they already have the (I hope) much simper way to add (or remove) apps to the startup file: edit_antix_startup_file
                    So my proposal to anticapitalista and Robin is adding a button for it on CC “session” tab (icon, name and description can be obtained from it’s .desktop file).

                    EDIT: I also have another proposal: improving the Arandr tool-tip in CC, so it warns that if users want to keep the selected resolution/screen configuration, they should save it, summing up how to do that using the GUI… Also, if the wallpaper gets miss-configured, after changing the resolution, remind users to restart the desktop)… Not all people read the tool-tips, but at least that those 2 important pieces of information would be easily available. Ideally, the GUI should take care of that… I tried to improve that, a while ago, without much success…

                    P.

                    • This reply was modified 2 months, 3 weeks ago by PPC.
                    #135668
                    Member
                    PPC

                      I’m getting old. I wracked by brains searching for the most simple way to automatically implement the full zzzfm localization that is included in a recent update (and that was missing in the original antiX 23.1 iso).
                      Only one simple command is required:

                      rm ~/.config/zzzfm/zzzfm_already_localized

                      After logging off and logging back on, zzzfm will be fully localized (unless the user changed the startup files, that check for that file, and, if it’s missing, run the script that localizes zzzfm).

                      @anticapitalista: is there a way to implement that command so it’s automatically run when the package that contains the zzzfm localizations is updated (i.e, run it as an post-install command)?
                      I created this “flag” file just for this kinds of cases… All users have to do is update the system. Once they log back on, the new localizations will be instantly applied. This *should” work universally!

                      P.

                      • This reply was modified 2 months, 3 weeks ago by PPC.
                      • This reply was modified 2 months, 3 weeks ago by PPC.
                      #135670
                      Forum Admin
                      anticapitalista

                        @PPC – It can be done via preinst/postinst scripts in the deb package. However, our policy is not to touch anything in user’s home directory.

                        Philosophers have interpreted the world in many ways; the point is to change it.

                        antiX with runit - leaner and meaner.

                        #135672
                        Member
                        PPC

                          our policy is not to touch anything in user’s home directory.

                          @anticapitalista – that is a mere “flag file” meant to let antiX know if it should, or shouldn’t run the script that localizes zzzfm. If you won’t open an exception for it, then we’ll have to do the hard work of changing the way zzzfm is localized, so that “flag file” is saved somewhere else, with all the problems that bring in… like possibly requiring sudo to simply localize zzzfm… But I won’t argue with you on that. You decide what is best. The simplest solution, even for the least experienced users, was what I proposed. All other “automatic” solutions will mean a lot of work…

                          EDIT: we can even make the post install script check, if the file exists and it’s content is just “localized”, then the user did not save any info in that file, and it can be safely deleted… No user data will be touched, that way.

                          P.

                          • This reply was modified 2 months, 3 weeks ago by PPC.
                          • This reply was modified 2 months, 3 weeks ago by PPC.
                          #135676
                          Member
                          Robin

                            If you won’t open an exception for it …

                            No exception needed.

                            @PPC: Just move the flag file to a private folder in the /usr/local/lib twig of file system and let the script check for it in this place rather than in users’ homes. You may copy the method from antiXradio, where it is implemented this way. Then this flag file can be removed by a postinstall script on package update without touching user’s homes.

                            Windows is like a submarine. Open a window and serious problems will start.

                            #135693
                            Member
                            PPC

                              just move the flag file to a private folder in the /usr/local/lib

                              There’s a reason that flag file is hidden away in the user’s folder: the way zzzfm gets localized is that the localization is performed “on the fly”, during startup, if the flag file, informing the script that there’s no need to do that is not detected. Using the /usr folder would require the localization script to run with elevated privileges… We are turning something that is veyr simple into something very complex, when we have more important stuff to deal with.
                              In this matter, I’ll leave everything to anticapitalista.

                              My complete proposed post install script would be something similar to this:

                              #!/bin/bash
                              file="$HOME/.config/zzzfm/zzzfm_already_localized"
                              content=$(cat $file)
                              if [ -e "$file" ]; then
                                  if [ "$content" == "localized" ]; then
                                      echo "The file $file contains only the content 'localized'. Deleting it so zzzfmlocalize can run on the next time antiX starts a session."
                                      rm $file
                                  else
                                      echo "WARNING: The file $file_path exists and its content is not 'localized', so it won't be deleted. Please localize zzzfm manually running zzzfmlocalize, after making sure zzzfm is not running"
                                  fi
                              fi

                              I will not, for now, try to edit zzzfmlocalize, @Robin. Of course, you are free to do that and implement any solution you find, that allows to solve this tiny localization “bug”.

                              P.

                              • This reply was modified 2 months, 3 weeks ago by PPC.
                              #135699
                              Forum Admin
                              Dave

                                In general the program / user should alter the user home files; package installation should not.

                                There are times, as you are seeing, where the user files will need to be updated to accommodate the updated program. It is tempting to think that apt should update these as well but it is a bad practice.

                                In general a decent way I have found to update the user files is for the program to check if there is a flag file and also check if the flag file is newer than the program installed by the package. If the flag/config file is older than the program. Ignore / rebuild it. If it is newer, respect it as up to date.

                                Another option. I did write a comparison check in desktop-session where the user can pick to ignore updates, always except them, or have a prompt for each file that differs and is in the update list via Yad. No idea if this still functions or is used at all.

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

                                #135701
                                Member
                                Robin

                                  Using the /usr folder would require the localization script to run with elevated privileges

                                  @PPC No. Just make the flag file in /usr/local/lib/zzzfmlocalise rw for ugo on install time (chmod). Please check how this was done in antiXradio which also hasn’t to be run with sudo in order to write the current user name into its flag file for managing the update detection. You can simply copy the full processing of this flag file over to your script, then no access of user homes is needed any longer when package is updated, and you’ll not have to ask the user for permission. zzzFM itelf (or whatever triggers your updater on zzzFM startup) will care then, by means of the localisation script included, for checking and updating the language in its session file. Nothing must be changed for this, besides the location where the flag file resides, and it must be taken care for multiple user names then, like antiXradio does, simply by writing the current name into the flag file.

                                  ——————
                                  P.S.: I should probably have mentioned, that package updates, which come with a locale update, then have to clear the flag file from all names in it (postinstall), simply by overwriting the file with an empty one rather than removing it, and the script/program whose language resource in /etc/skel is updated by the package will have to write the username again into this file after the update of the session file for a specific user was done. So at startup it has to check whether current username is already in the file or not, instead of checking for the presence of the file, and from that finding deriving the decision whether to start up straightaway or first run the zzzfmlocalize translator routine on the user’s session file. Think it as a huge loop over the update cycle. That’s what makes it work, even on multi-user systems.

                                  Windows is like a submarine. Open a window and serious problems will start.

                                Viewing 15 posts - 181 through 195 (of 219 total)
                                • You must be logged in to reply to this topic.