bug in script desktop-menu? antiX 19.x 32bit/64bit

Forum Forums antiX-development Development bug in script desktop-menu? antiX 19.x 32bit/64bit

  • This topic has 55 replies, 6 voices, and was last updated May 13-10:53 pm by Robin.
Viewing 11 posts - 46 through 56 (of 56 total)
  • Author
    Posts
  • #82832
    Forum Admin
    Dave
    Helpful
    Up
    0
    ::

    OK the changes in the help file I missed should be added now. As well as the default category filter being set to names only. I had this set to no filter in case names was not a specified option. (desktop-menu –generic-names –comments –order=gc). I am not certain about specifying spaces for the –pattern option due to IFS including the space character. Will have to look at it more closely.

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

    #82847
    Member
    Robin
    Helpful
    Up
    0
    ::

    specifying spaces for the –pattern option due to IFS including the space character.

    Well, four individual numbered separator options (name them the way you like best, I used the abbreviations for faster typing only) work fine, I have checked the version 3.27a from my merge request. Everything (including blanks) enclosed by default quotation marks is transferred properly to the menu. No need to change IFS this way. So for me there is no pressing need to put it into a single option. And there are other representations for quotation marks, which look also fine in menu instead of the default ones needed to quote the separator sting: »« “” „”
    within separator string instead of ""
    so no problem here.

    Additional thought: Maybe putting it into a single option makes the syntax a bit difficult to read, please compare the examples from my comment to the merge request:

    --separator-2=" „"
    --separator-3="” ("
    --separator-4=")"

    would look like:
    --pattern "" " „" "” (" ")"
    (we need to explicitly give any empty separator string here also in case all is put in a single option, since the logic can’t guess for which position it is meant otherwise, while empty ones can be omited when using individual options for each separator)

    Please decide yourself which way you like it best.

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

    #82848
    Member
    Robin
    Helpful
    Up
    0
    ::

    (desktop-menu –generic-names –comments –order=gc)

    I believe we should think about simplifying the interdependency of the command line options, e.g. replacing them by an internal logic, deriving the needed entries directly from the order argument, where the information is present already. I’ll work on a logic function which will settle this automatically. Should be easy, since when there is e.g. a “n” in the order we know we need -​-names activated, same for the others. So we could replace the -​-names option by order=n, -​-generic-names by order=g and -​-comments by order=c

    Moreover the categories filter should probably work the same way as the progams submenus, so it is possible to have names-only (n) in categories, while e.g. generic-names-only (g) or generic-names+comments (gc) in the subdirectories, or vice versa. By now there are only names (n) defined in the categories files obviously, so it works fine even when filters are set to ngc. since the empty entries are not displayed. But once an additional entry (g or c) is present for a category, we’ll get in trouble.

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

    #82909
    Member
    Robin
    Helpful
    Up
    0
    ::

    New testing version ready (desktop-menu 3.27b)
    https://gitlab.com/Robin-antiX/desktop-menu-antix/-/raw/test-03/bin/desktop-menu?inline=false

    Removes now properly all non needed non embracing separators when a string is not present in a desktop file, while it doesn’t touch closing brackets anymore. So it’s error tolerant now when called using the command line options properly. (We’ll have a GUI to allow easy handling of the correct setting of these.)

    This version defaults to the same view as traditional antiX shows, Program Names only in Menu, no separators.

    Additionally filing -​-names -​-generic-names or -​-comment is no longer needed.
    For generic names only use -​-order=g instead (comments: -​-order=c), just like all the other possible orders.

    See help message for usage instructions of the new options. Please let me know if there is something not understandable in my added explanations for the new options in the help file.

    Update: Version 3.27b was tested by me and Marcelo extensively this evening. New options have proven to work flawlessly on antiX 19 32bit and antiX 21 64bit both, allowing highly flexible design of menu entries on IceWM, JWM and Fluxbox.

    Some restrictions for choice of separator characters (e.g. closing default bracket) and icon file type (e.g. svg) apply only when using fluxbox and need to get communicated to users. Since IceWM and JWM handle this properly, we shouldn’t filter these in the script itself.

    @Dave : Next we’ll check the category-filter, so please wait before working on this filter function again until we had time to perform the tests. I believe it works fine (but I’m not completely sure about it by now.)
    Have removed the outdated merge request and sent a new one for this most recent version.

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

    #83050
    Member
    Robin
    Helpful
    Up
    0
    ::

    New testing version desktop-menu 3.28 ready at gitlab (downloadlink)

    Turned out the menu design set by a user gets overwritten again and again when a program was installed or updated.
    So I’ve added functionality for reading options user specifically from a settings file. The menu won’t get reset to default any longer when desktop-menu is executed automatically by apt after installing programs.

    Backward compatibility is kept, the new functions need to be activated by user before being applied.

    To activate simply let create a config file by using the option
    --store-config
    storing all the other options given in command line to the file ~/.config/desktop-menu/settings

    The options in settings file will get read and applied either when running
    desktop-menu --write-out-global --read-config
    or if you set the additional option
    --autoread-config
    to the command line used to store the settings.
    From then on it is enough to call
    desktop-menu
    without any options or
    desktop-menu --write-out-global
    (depending on whether or not you have stored -​-write-out-global in your settrings file) to apply the stored options to the menu.

    To remove the autoread option you can either delete the respective line manually in the settings file, or call
    desktop-menu --show-config
    Then copy the displayed options, run the -​-store-config command with the pasted options line (remove the -​-read-config option from what you’ve pasted) again, which will create a new settings file without the autoread option.

    You may create or edit the settings file manually, I’ve kept it very easy: One command line option per line, just like you’d enter the option along with its arguments on command line, that’s all you need to know.

    Example settings file:

    --autoread-config
    --sep-3a=" "
    --sep-2b=")"
    --sep-2a=" ("
    --order="gnc"
    --write-out-global
    
    

    @Dave New merge request was sent (#4 at gitlab). It contains all modifications from merge request #3.
    I didn’t close #3 so you can still read what was changed in this one.

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

    #83059
    Member
    Robin
    Helpful
    Up
    0
    ::

    Again a new testing version of desktop menu (3.29) is present at gitlab (downloadlink)

    @translators :
    This time I’ve added gettext translation support to all the strings present in the script. Resurce is present at transifex (antiX-Contribs), developers notes displayed at the right side of the transifex editor between original string area and text enter field will give you an idea where to locate a string when running it. Please set the editor to display raw text, so you can see all the blanks present in the original strings. Otherwise they will get lost while translating. You need to keep them all, they make sure text is displayed in the correct location on console.
    There is no way to circumvent their presence in translation strings, since translations differ always in length from source string, and this can’t get fixed on a per-language-base when cutting the blanks off in the source strings (which would be possible easily). So you need to take care of them painstakingly.

    @Dave : Next merge request #5 is filed at gitlab, containing all commits from the merge requests #3 and #4 as well. Possibly we need to add an option like -​-silent or -​-quiet, suppressing all informational output displayed by the new options in order to restore the ability to pipe the processing output from stdout to a file. (maybe we could use different file descriptors for printing information and true output to avoid this without need of an additional option, so when piping stdout only the true processing output is caught.)

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

    #83071
    Member
    marcelocripe
    Helpful
    Up
    0
    ::

    There is no way to circumvent their presence in translation strings, since translations differ always in length from source string, and this can’t get fixed on a per-language-base when cutting the blanks off in the source strings (which would be possible easily). So you need to take care of them painstakingly.

    Should translators consider the maximum amount of 80 characters for each “desktop-menu” entry in Transifex?

    Thanks Robin for yet another program.

    – – – – –

    Os tradutores devem considerar a quantidade máxima de 80 caracteres para cada entrada do “desktop-menu” no Transifex?

    Obrigado Robin por mais este programa.

    #83084
    Member
    Robin
    Helpful
    Up
    0
    ::

    Thanks Robin for yet another program.

    This is Daves program, not mine. I’m merely contributing to it, best I can.

    Should translators consider the maximum amount of 80 characters for each “desktop-menu” entry in Transifex?

    This is probably a good idea. For the german translation I did.
    The procedure is quite easy (either manually in text editor, or on transifex, or using poedit or aCMSTS.), but you’ll need a good pint of perseverance to accomplish a proper result.

    1st step: start the desktop-menu (3.29 testing version which is the first version prepared for translation) on console window with the help option:

    desktop-menu --help

    You’ll see the complete help text (which is biggest part of the translatable strings present at transifex)
    This way you’ve got a visual cross reference between the individual original English strings on transifex, the developer notes will guide you to locate a specific string easily.

    Now copy the complete multiline entry text of an option description (either by picking them up string by string marked as “line 1 of entry”, “line 2 of entry”, “line 3 of entry”, … “line n of entry” from transifex, or simply by copying the complete set of consecutive lines belonging to the entry from console window.) to a text editor (I used geany, since it displays the Number of characters from start of line to recent cursor position in line in its footer.)

    It doesn’t count how many sentences you need to describe it concisely in your language, you could split up long sentences into shorter ones or combine short ones to a long sentence. Single thing of importance is to transport the idea of the paragraph, not the sentences 1:1.

    2nd step: Collate your translated text into the given number of entry lines, following the concept: start at the 1st line, copy the starting blanks string 1:1 from original English text to your translation, and add a chunk of your translated text not longer than the original has been. Apply this procedure on all followup lines of the entry, always copying the number of blanks from the original string first, and then filling up the line to the length approximately it originally had.

    Probably in the last line of the entry you’ll have still translated text to collate, since the English original is quite terse. No problem, just add an /n to the end of the string plus the very number of starting blanks from the line before. Then concatenate the next chunk of translated text just like you would have done in a next line entry if there would have been one. Repeat this procedure until your text for this entry is collated completely.

    (You can look into the german translation for reference, I made widely use of this method to append some lines)

    3rd step: Once you’ve translated all strings this way at transifex, download the .po file (“for use”) from transifex.
    rename it to desktop-menu.po (this is mandatory!) and apply the commands on console (having moved to the directory where the downloaded file resides):

    msgfmt -o desktop-menu.mo desktop-menu.po
    sudo cp desktop-menu.mo /usr/share/locale/<language_identifier>/LC_MESSAGES/desktop-menu.mo

    replace <language-identifier> (remove the embracement) by your actual language identifier in Unix style, e.g. fr for French, pt_BR for brasilian Portuguese, it for italian. These commands compile the .po translation source file to the .mo file type needed by gettext and copy it to the correct place in system to be found automatically when the respectively prepared script is started.

    Then maximise roxterm window and run again the script with help option

    desktop-menu --help

    The message should come up in your language now. You’ll notice it has probably some flaws in correct position of text elements displayed. This is easily fixable:

    4th step: Set the roxterm window to exactly 80 character width and run the last command again. Now check line for line of the output, and memorise the exact position (word) where the line gets wrapped automatically. Head back to transifex, look up the respective entry and put the excess length you’ve found into the following line.

    Walk through line by line this way, maybe you need to add some additional lines following the method described above.

    You also will notice some text lines wouldn’t line up correctly, swaying one or two characters to left or right.
    Fix this by adding or removing the respective number of leading blanks from their corresponding transifex entry.

    Make sure to re-download the updated .po file from transifex, compile it to .mo again, copy it to the system folder to see the results of your modifications when running the script one more time.

    Repeat this, alining line by line of the help text while repeatedly running updated versions of your translation .mo file, until you see the help text being displayed properly formatted.

    That’s all the secrets about how to manage the text positioning and line breaking in translation for console output properly.

    There is a shortcut, in case you are familiar with directly editing .po files within a text editor:
    Instead of applying the needed corrections to transifex, downloading the updated .po file again and again, you can simply apply the chancges to the entries found in the .po file. This way you can test the result immediately after saving the file, without closing the text editor, and re-using the commands for compiling and copying from before, stored in roxterm command cache, by ↑ and ↓ button. This will speed up your proceedings remarkably.

    Another way handle it locally could be to use poedit to edit the .po file. Also aCMSTS will provide assistance to repeat the testing and modifying procedure repeatedly and fast, until you are fine with the result.

    Decide yourself which way suits you best. Once you are content, upload the .po file back to transifex.

    To the English native speakers: Please correct any mistakes and strange-sounding expressions I may have used in the texts of options I’ve added to the script, directly in „en”, „en_GB” or „en_US” »translation« at transifex.

    I’m a bit in doubt about the meaning of two strings which where present already:

    #45: „Write the output to the applications file from the appropriate template”

    What applications file does this refer to? Does it actually mean the program file will get modified?
    (I still don’t understand the precise processing of the respective part of the script code, so I have no clue what it actually does when –write-out is filed as an option.)

    #55: „convert icon base names to icon absolute paths using specified icon theme”

    What is meant by “icon base name”? I translated it to „Symbolbild-Basisname”, which sounds pretty technical and is the correct translation but I actually have no clue what to make of it. So best would be here not to translate literally, once we have found out what actually is meant.

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

    #83089
    Forum Admin
    Dave
    Helpful
    Up
    0
    ::

    #45: „Write the output to the applications file from the appropriate template”

    What applications file does this refer to? Does it actually mean the program file will get modified?
    (I still don’t understand the precise processing of the respective part of the script code, so I have no clue what it actually does when –write-out is filed as an option.)

    #55: „convert icon base names to icon absolute paths using specified icon theme”

    What is meant by “icon base name”? I translated it to „Symbolbild-Basisname”, which sounds pretty technical and is the correct translation but I actually have no clue what to make of it. So best would be here not to translate literally, once we have found out what actually is meant.

    #45 means to take the output of desktop-menu and write it to the applications menu file (~/.icewm/menu-applications, ~/.fluxbox/menu-applications, ~/.jwm/menu-applications) using the template file (/usr/share/desktop-menu/templates/*) that matches the window manager you are using. (icewm, fluxbox, jwm, openbox)

    #55 means to convert the icon name used in the .desktop file (ex: roxterm) to be the absolute path of the icon using the default users theme or the theme specified with –theme (Ex: roxterm – > papirus-antix theme -> /usr/share/icons/papirus-antix/48×48/categories/utilities-system-monitor.png). In fact this is an outdated option and is pretty much the default now (fluxbox requires it) and likely does not work anymore so this option we can probably remove.

    As far as the merge requests… after having a brief look, help me to understand a few things.
    1) the help text menu to be translated using gettext. Why is it broken into so many print statements rather than changing the first and last lines to:

    print(_("""Usage: %s [options]
    .....*......
     """ % sys.argv[0]))

    2) the config file. This is obviously per user configuration, but why does it need the –write-out-global function? Is it because we are defaulting to reading the configuration file if no option is set? If so –write-out-global is run as root by apt, so which configuration file is it then using? Also are we still using the symlink if the configuration file is used or is there a separation between menu files per user that I am not seeing?

    3) One problem with the separator options I have been looking to resolve while you have been making these changes. When you use order=ngc and specify all separator options. One line will show expected results, but another would show unexpected results when there is information missing (like generic name). For example:

     | zzzfm | [ file manager ] { The is an application to manage your files }
      | zzzfm | [ This is an application to manage your files ]

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

    #83092
    Member
    Robin
    Helpful
    Up
    0
    ::

    1) the help text menu to be translated using gettext. Why is it broken into so many print statements rather than changing the first and last lines to:…

    To question 1)
    After some thinking about it I understand, it is not needed to break up the single print statement itself. Only the text string within needs to get split into separate concatenated strings, some of them translatable, some of them not. I’ll update the code, no problem, please await version update. (This modification will not change the msgids in pot file, so no translations get lost)
    → [update: done.]

    The reason for splitting this up is, it is mostly impossible to work on a text like this on transifex when it is not split up in separate strings (see screenshot, this is from a test upload following your proposal). We have seen entries, way shorter than this one, which turned out to be mostly uneditable at transifex. Have you ever tried to translate something? When the complete page is delivered in a single continuous string, linebreaks are displayed as /n only, and an insurveyable and unmanageable number of strings of blanks of different length need to be kept somewhere in between, you simply can’t keep track of position of the sentence you are working on, nor you can’t manage the formatting properly by adding or removing a blank in a specific position while constantly scrolling 20 pages up and down to search the next original sentence. Same goes when editing the msgid entry in po file locally e.g. using geany. Also here you get lost while constantly scrolling between supersized msgid and msgstr, searching for the next sentence to translate or a specific string of blanks in need of adaption. So we need to split up into individual strings for translation, one line or one sentence per msgid (see 3rd screenshot). But we actually don’t need more than one print command for this.

    To question 2.) We had still no time for testing how this acts when not run by user himself. We’ll probably face exactly the problem with root you point to. We need to find a way to overcome this, checking for the “true” user in case the script is run sudoed. By now it will not obey the autoread setting stored in users home then, since it simply probably won’t read the config file when running sudoed. Moreover the problem with the symbolic link needs to get treated, so we can run it truly user-specific. I’ll think about how all this can be helped.
    → [update: misbehaviour when sudoed is fixed. Will read true users config now. (More to come)]

    To issue 3.) Again, very well observed, many thanks! I can confirm this issue after some testing. I’ve checked, all variables are fine when entering the get_order function still, so the reason for this behavior is something different: When an entity is not present in desktop file or removed due to duplicat, it switches its position (e.g. gnc → nc if g is removed, n from 2→1 and c from 3→2). So the separators meant for second position are applied to what originally was at position 3, while the separators meant for first position are applied now to to the text originally at position 2.
    While this is expected behaviour when entering the separators from command line for a specific order, it is not when the order is changed automatically by the logic in lines 269-277 (Ver 3.29). The separators need to get swapped when removing an entity from the order variable for a specific menu entry. Will try to write a logic for this to work properly. Other solution would be to bind the separators not to the position, but to the item (gname, cname or name). This would not need any additional logic, just interchanging the separators within the dictionary code and updating the help file. Will check what suits better.
    But after thinking about it a second time, I’m sure we’ll run into another problem when replacing the separators this way (either by logic, or by binding them to the items instead of position): The menu might look a bit strange. Example:
    --order="gnc" --sep-2a=" (" --sep-2b=")" --sep-3a=" “" --sep-3b="”"
    will create a menu entry like
    Office (LibreOffice) “Some descriptive text about LibreOffice here”
    Since Office is found in LibreOffice, it will get removed, positions are changed (gnc → nc) so status quo it displays like
    LibreOffice (Some descriptive text here)
    while when changing the code to follow this swap of positions as sketched above it will look like
    (LibreOffice) “Some descriptive text here”
    Actually we would expect to see something like
    LibreOffice “Some descriptive text here”

    The embracement of first position looks a bit funny in menus (as long we are not used to read from right to left)
    No idea how to escape this double windmill, so I believe we should leave the code for now as it is. It will be solved also once we are done with the completion of desktop files in use, so there simply are mostly no empty entries anymore.
    Maybe we could create some sopisticated logic, allowing most decent display, like
    »if first position was swapped from gname to name (or vice versa), keep separators originally assigned to the first position.«
    »if second position was swapped from name or gname to cname (or vice versa), swap the separators the same way.«
    and so on…
    Do you believe this would be a solution, if elaborating on this path?

    To #45 string entry at transifex

    and write it to the applications menu file

    Many thanks for clarification. The way it is described in help text is pretty incomprehensible to non native speakers. I was completely confused by the expression »applications file« (= executable) instead of »applications menu file«. Now it is clear.

    To #55 string entry at transifex
    If this will be dropped, we don’t need to think about proper translation anymore. I knew the way this works from the script code, like you describe it, storing the complete paths to the icon file instead its gtk name only. But again, the description »icon base name« used in help text confused me, not knowing how to translate this. Probably all this isn’t a problem to understand to an English native speaker at all…

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

    #83109
    Member
    Robin
    Helpful
    Up
    0
    ::

    Again a new testing version of desktop menu (3.30) is present at gitlab (downloadlink)

    I’ve rethought the way the script behaves.
    objectives:
    – keep backward compatibility (apt-hook -​-write-out-global called by sudo/root) while allowing multiple user specific configurations at the same time.
    – store menus per user instead of one menu design for all.
    – make handling more convenient (removed confusing option conflicts)
    – clean separation of multiuser and singleuser processing mode.

    1.) So I removed the autoconfig option, and made this the default if a user has created his own config file. Otherwise an OS defult config file will be used.

    2.) Changed the behaviour of -​-write-out-global to only get accepted when called by sudo/root, since it will write menu globally (for all users). Hence it also rejects any additional command line options, so if this option is filed, merely the respective user specific configs or OS default will get applied, per user home.

    3.) Added the -​-write-out-single option, which allows user either to file additional options, or in case no additional options are filed to apply the stored configuration.

    4.) Excluded -​-write-out-global and -​-write-out-single from being stored in config file. (maybe some other options need to get excluded also)

    5.) Added chown and chmod to build-menu function in order to make sure files are still writable by user if script was run sudoed.

    6.) Expects an OS default settings file named “settings” in the /usr/share/desktop-menu folder.
    Example for antiX default menu design:

    --order=n
    --category-filter=n

    This was added to allow easy default menu design changes for upcoming antiX versions without need to rewrite the script code itself. If the file is not present a fallback will be added to use some script internal default values instead.

    Needed changes in system:
    The following symbolic links are to be changed to

    /home/<username>/.fluxbox/menu-applications -->  /usr/share/desktop-menu/<username>/.fluxbox/menu-applications
    /home/<username>/.icewm/menu-applications -->  /usr/share/desktop-menu/<username>/.icewm/menu-applications
    /home/<username>/.jwm/menu-applications -->  /usr/share/desktop-menu/<username>/.jwm/menu-applications

    for all users and in /etc/skel in order to make things work.

    @translators: Please wait with further translations until transifex resource is updated. Some translatable strings have had to be changed or removed, while most of them are untouched. Some new translatable strings were added.

    Here can you see another reason why it is more eligible to split a long text into many small translatable strings instead of keeping it in a single string: If the help text would have been in a single string, all its translations would get removed from transifex completely the moment the updated .pot file is uploaded. Having it split up in several translatable strings allows updating the resource without loosing all the other already translated strings which are part of the help file also and which have not been touched. Sure, we can discuss whether it is better to split into lines, or split into small paragraphs comprising of e.g. one option description. Since some of the individual descriptions are quite long already iteself, I decided to use the lines split method here.

    @Dave : New merge request #6 is filed, containing all commits from the #3, #4 and #5 also.

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

Viewing 11 posts - 46 through 56 (of 56 total)
  • You must be logged in to reply to this topic.