[SOLVED] Edit “manually” menu-applications file

Forum Forums Official Releases antiX-19 “Marielle Franco, Hannie Schaft, Manolis Glezos” [SOLVED] Edit “manually” menu-applications file

  • This topic has 8 replies, 4 voices, and was last updated Mar 21-10:50 am by Spartak77.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #55980
    Member
    Spartak77Spartak77

    Just a curiosity.
    I would like to understand which file controls the menu-applications file contained inside the home/user-name/.icewm folder (or menu-applications in home/user-name/.fluxbox, or in home/user-name/.jwm).
    I’m interested in understanding how to manually edit this file. Yes, I know I can use antiX graphical tools like Menu Manager, but I want to understand how it works.
    The file: home/user-name/.icewm/menu-applications is linked to the file: /usr/share/desktop-menu/.icewm/menu-applications
    If I want to delete an item from the menu-applications just put the # symbol in front of the line concerning the item in the file /usr/share/desktop-menu/.icewm/menu-applications and I will no longer see that item in the IceWM menu.
    But if I install another application, the change I made is overwritten.
    So what is the file that I need to edit to make the change permanent?
    I tried to look in menu_manager.sh but I couldn’t figure it out.

    • This topic was modified 1 month, 3 weeks ago by Spartak77.
    • This topic was modified 1 month, 3 weeks ago by Spartak77.
    #55986
    Member
    Avatarskidoo

    which file controls the menu-applications file contained inside the home/user-name/.icewm folder

    It’s a symlink, right?
    The symlink points to /usr/share/desktop-menu/.icewm/menu-applications

    dpkg -S /usr/share/desktop-menu/.icewm/menu-applications
    ^-v
    desktop-session-antix: /usr/share/desktop-menu/.icewm/menu-applications

    At this point, we can say that it is “provided by, installed by” the desktop-session-antix package. You asked “which file controls” so here I’m explaining that if you edit the /usr/share file, that edited file is subject to being overwritten during future apt upgrade desktop-session-antix package.

    You may, instead, delete the existing symlink and copy /usr/share/desktop-menu/.icewm/menu-applications into its place. After doing so, you can freely edit the file and it will remain undisturbed. However, it will not receive the benefit(?) of being dynamically updated each time new programs are installed//removed.

    I tried to look in menu_manager.sh but I couldn’t figure it out.

    here’s a good (IMO) “where to look” strategy:

    grep -inr desktop-menu –color=always /usr/local
    ^—> each line of the output will be perpended with filename:linenumber
    You can mouse select filename:linenumber
    and
    geany filename:linenumber
    will enable you to view each reference in context, toward gaining an understaning of “how the anklebone is connected to the shinbone…”

    #55988
    Forum Admin
    anticapitalistaanticapitalista

    You will need to edit /usr/share/applications/(antix)/x.desktop files by hand or use menu-manager.
    Basically you edit this line to false or true –

    NoDisplay=False (means it will show up in the menu).

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

    antiX with runit - leaner and meaner.

    #55989
    Member
    Avatarskidoo

    You will need to edit /usr/share/applications/(antix)/x.desktop files by hand

    I haven’t tested to confirm, but I would expect edits to files pathed there are equally subject to being overwritten during apt update operations.

    Instead, we should
    cp /usr/share/applications/(antix)/xxxxx.desktop ~/.share/applications/xxxxx.desktop
    then edit the local copy…
    and the menu-manager utility will consult the same-named, locally pathed, “xxxxx.desktop”, yes?

    #55990
    Forum Admin
    anticapitalistaanticapitalista

    I haven’t tested to confirm, but I would expect edits to files pathed there are equally subject to being overwritten during apt update operations.

    Instead, we should
    cp /usr/share/applications/(antix)/xxxxx.desktop ~/.share/applications/xxxxx.desktop
    and the menu-manager utility will consult the same-named, locally pathed, “xxxxx.desktop”, yes?

    Yes, that is better – but it should be ~/.local/share/applications/xxxxx.desktop

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

    antiX with runit - leaner and meaner.

    #56104
    Member
    Spartak77Spartak77

    @anticapitalista, @skidoo, Thanks guys.
    I had some time today and took a closer look at what you wrote to me.
    I realized that there is no single upstream file (in the system folders) where the menu is written.
    A single file where I could add entries, maybe as root, and be sure it doesn’t get overwritten.
    Ok, I could break the link between /usr/share/desktop-menu/.icewm (or .fluxbox .jwm)/menu-applications and ~/.icewm (or .fluxbox .jwm)/menu-applications or I could change the write-permissions of these files (I think, but I haven’t tried) and my changes wouldn’t be overwritten but then, as skidoo says, every time I download a new application (or update the menu) I would have to change the menu by hand and this isn’t a good solution.
    I think I understand from what you say, anti and skidoo, that when a new application is downloaded, the menu in /usr/share/desktop-menu/.icewm/menu-applications, is updated using the informations found in the xxx.desktop files contained in /usr/share/applications/ and in /usr/share/applications/antix/.
    I did a test, I deleted the xxx.desktop file of an application from /usr/share/applications/ and, after giving: Menu → Update menu, the application entry disappeared from /usr/share/desktop-menu/.icewm/menu-applications and consequently from the IceWM Menu.
    So everything revolves around the xxx.desktop files
    The Menu_Manager application makes items appear or disappear from the menu using the xxx.desktop files.
    As anti said,

    Basically you edit this line to false or true -.
    NoDisplay=False (means it will show up in the menu).

    This is what Menu_Manager does and what I could do “by hand”.
    I noticed that the line NoDisplay=
    doesn’t always exist, so if it doesn’t exist the Menu_Manager creates it, if it does exist it modifies false or true depending on what the user wants.
    The add-desktop application, that we can run to add a new menu entry, if it is not automatically created with the installation of that app (or script) acts, in turn, by creating a file xxx.desktop that it places in ~/.local/share/applications/, creating the folder custom, if this is not already present.
    Ultimately you can edit the menu of menu-applications by hand, without overwriting, by acting on the xxx.desktop files but it’s not convenient, much more practical to use the graphical tools Menu_Manager and Add-desktop.
    This is what I understood.

    • This reply was modified 1 month, 3 weeks ago by Spartak77.
    • This reply was modified 1 month, 3 weeks ago by Spartak77.
    #56121
    Member
    Avatarskidoo

    skimming / reading the desktop entry specification documentation is helpful toward understanding the details (bookmark, revisit and “search in page” when future questions arise).

    https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

    NoDisplay [aka “presence of a line declaring “NoDisplay=True”] means “this application exists, but don’t display it in the menus”. This can be useful to e.g. associate this application with MIME types, so that it gets launched from a file manager (or other apps), without having a menu entry for it

    related, optional, lines you will eventually encounter within some .desktop files:
    OnlyShowIn=
    NotShowIn=
    The only recognized values (case-sensitive!) for these are {GNOME,KDE,ROX,XFCE,Old}
    Per the “freedesktop.org menu spec”, a menumaker may(should) ignore any other values declared here
    https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#onlyshowin-registry

    #56142
    Forum Admin
    DaveDave

    IF you would like to maintain a manual copy of the menu-applications file, you can remove the symlink in ~/.wm/menu-applications. For example if running the IceWM desktop:
    rm ~/.icewm/menu-applications
    then run the following to rebuild the menu file
    desktop-menu --write-out --write-out-file menu-applications
    You can then make any changes you would like. The menu should no longer be automatically overwritten.

    As noted you will loose the automatic update “feature” when installing new applications or updating the system.
    This will need to be manually done. Perhaps the easiest way to do this would be to run
    diff -y ~/.icewm/menu-applications /usr/share/desktop-menu/.icewm/menu-applications
    or after installing meld
    meld ~/.icewm/menu-applications /usr/share/desktop-menu/.icewm/menu-applications

    Prior crossed out text left for reference on another method
    desktop-menu --write-out --write-out-file menu-applications-new
    then use diff or another program (meld is a good gui app) to view the difference and merge the two together.
    cd ~/.icewm/ && diff -y menu-applications menu-applications-new
    or after installing meld
    meld ~/.icewm/menu-applications ~/.icewm/menu-applications-new

    • This reply was modified 1 month, 3 weeks ago by Dave.
    • This reply was modified 1 month, 3 weeks ago by Dave.

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

    #56151
    Member
    Spartak77Spartak77

    Thank you anti, skidoo, dave, you have given me so much information.

    @dave
    I tried what you suggested and everything works.
    The only thing that doesn’t seem very functional to me is the use of diff at the terminal. I would have expected an output with only the different lines between the two files, instead it was not so,but maybe I don’t know how to use diff well and I didn’t pay attention to something important or I could have used other flags but I didn’t try.
    Instead meld is easily understandable for me, then I also tried diffuse which is the graphical version of diff and I can understand it well.
    I wondered if it was really important to compare the files with diff, diffuse or meld, considering that when I install a new application I know what it is called and I know in which category to look for it on the file /usr/share/desktop-menu/.icewm/menu-applications to be able to copy-paste it on on the file ~/.icewm/menu-applications
    In reality the comparison with these tools is useful because not always the changes are introduced by a new installation we decide to install but there can be changes we don’t know induced by a system update.

    Ultimately the solution of using the symlink breakage between the files /usr/share/desktop-menu/.icewm/menu-applications and ~/.icewm/menu-applications to get a customized applications-menu may be a way that someone can choose to take in certain cases.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.