IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд

Linux desktop file

Ubuntu Documentation


Unity Launchers are actually files stored in your computer, with a ‘.desktop’ extension. In earlier Ubuntu versions, these files were simply used so as to launch a specific application, but in Unity they are also used so as to create right-click menus for each application, which you can access from the Unity Launcher.

This article describes how to create a working .desktop file for general use, but also how to add it to the Unity Launcher and/or how to edit a Unity Launcher itself, by editing its fields or by adding a right-click menu to it.

Creating a working .desktop file

There are currently 2 ways of creating a desktop file. The 1st one is using a text editor, like Gedit, and the 2nd one is installing a program (gnome-panel) or using ‘alacarte’ that both do the job for you. The former lets you «control» your launcher more than the latter, but the latter way is easier. Please note that this section will cover only the basics, not how to add shortcuts to your launcher. For this, please head to Adding shortcuts to a launcher.

Using a text editor

Open your favourite text editor, like Gedit or nano, and type in (copy and paste):

These lines are enough for describing a simple launcher. Each launcher (.desktop file) consists of some basic fields.

    Version is the version of this .desktop file.

    Name is the name of the application, like ‘VLC media player’.

    Comment is a phrase or two describing what this program does, like ‘Plays your music and videos files’.

    Exec is the path to the executable file. The full path to the executable file must be used only in case it isn’t in any of the paths specified in the $PATH variable. For example, any files that are inside the path /usr/bin don’t need to have their full path specified in the Exec field, but only their filename. To see all the paths in the $PATH variable you can open a terminal using Ctrl+Alt+T and type in

    Icon field is the icon that should be used by the launcher and represents the application. All icons that are under the directory /usr/share/pixmaps don’t need to have their full path specified, but their filename without the extension. For example, if the icon file is /usr/share/pixmaps/wallch.png, then the Icon field should be just ‘wallch’. All other icons should have their full path specified.

    Terminal field specifies whether the application should run in a terminal window or not.

    Type field specifies the type of the launcher file. The type can be Application, Link or Directory, but this article covers the ‘Application’ type.

    Categories field specifies the category of the application. It is used by the Dash so as to categorize the applications. A launcher being a ‘Utility;Application;’ should be under the ‘Accessories’ section etc.

    A realistic example of how a .desktop file looks like is the following:

    One last thing to add is that by setting executable rights to your .desktop file, it automatically takes the specified Icon and Name (specified in the corresponding fields), as it should be. Be careful though, the filename doesn’t really change, it still remains ‘launcher_name_here.desktop’ and not ‘Name_field_here’, the system chooses to display it like ‘Name_field_here’ because it’s nicer without the .desktop extension.

    Example .desktop file without executable permissions:

    Same file with executable permissions:

    Using gnome-panel/alacarte

    It is important to install gnome-panel using the following command, so as not to install the recommended not-needed packets along with it. So open a terminal using Ctrl+Alt+T and give the following command:

    It will ask you for your login password, which you have to fill (nothing will be shown, not even asterisks (*)) and press enter.

    Without closing the terminal window, after the installation process is over, you have to type the following command:

    /Desktop/’ is any directory you want your launcher to appear, after its creation process is over. After running this command, a familiar window will pop-up, which lets you fill the Name, the Command and the Comment for your launcher. Also, you can specify an icon for your launcher by clicking on the big icon of the window on the top left of it.

    You can also use ‘alacarte’, which you can execute by searching in the Dash for ‘Main Menu’ and once the application launches, then you click on «New Item» on the section you want your application to be. Then a window similar to the one being shown using the gnome-panel method will be shown.

    Adding a .desktop file to the Unity Launcher

    In order to add your launcher to the Unity Launcher on the left, you select and drag it onto the Launcher panel. Alternatively, you can place your .desktop file at /usr/share/applications/ or at

    /.local/share/applications/. After moving your file there, search for it in the Dash (Windows key -> type the name of the application) and drag and drop it to the Unity Launcher. Now your launcher (.desktop file) is locked on the Unity Launcher! If your desktop file cannot be found by doing a search from the Dash, you may need to read on.

    To be more certain that your .desktop file will work properly, use the desktop file validator, which will notify you of any errors or omissions. If there are no errors, desktop-file-validate will exit silently.

    Once the file validates correctly, install it to the default location (probably /usr/share/applications) using the desktop-file-install program. This step may require superuser privileges. The desktop-file-install program may add some lines of its own to your .desktop file. There is no need to have the .desktop file be executable by anyone.

    Please note that desktop-file-validate tends to be oversensitive at times, which means that it can output error messages on perfectly working .desktop files. Those error messages should be better seen as warnings rather than anything else. For more information on desktop entry specification please refer to http://standards.freedesktop.org/desktop-entry-spec/latest/

    Editing an entry of the Unity Launcher

    Editing its main characteristics

    If you’ve added a .desktop file to the Unity Launcher, but you don’t like something on it, like its icon, or probably it doesn’t execute, then you may need to edit the launcher so as to change what you don’t like or to fix any errors.

    First of all, you have to know the exact name of the .desktop file you will need to edit, and it isn’t the same with the application’s name (they are usually similar, but still not the same).

    So as to find the exact filename of the .desktop file you are interested in, open a terminal using Ctrl+Alt+T and give the following command:

    This will output a list of all the .desktop files you already have in your launcher, from top to bottom, like this:

    So, by comparing this output to the row of the launchers in your Unity Launcher, you can easily find the name of the .desktop file. For example, if you want to edit the launcher before the last one, in this case it would be ‘audacious.desktop’. Copy the name of this launcher by selecting it and giving Ctrl+Shift+C for later use. Now you have in your clipboard the filename of your file, but not its path. Your file can be either under

    /.local/share/applications/ or under /usr/share/applications/. Usually, if you have made a desktop launcher, it is under

    /.local/share/applications, but any other application launcher that belongs to an application you have installed to your computer should be under /usr/share/applications. So, in order to edit this launcher, open a terminal using Ctrl+Alt+T and give the following:

    where ‘gedit’ you can use your favourite text editor. The following command will ask you for password. Type in your login password and gedit (or any other text editor) will open with the launcher file you wish to edit. To edit the launcher go to ‘Using a text editor’ where it says it clearly on how to create a launcher and the same applies on editing it.

    Adding shortcuts to a launcher

    Some applications become much more usable with a right-click menu. This is an example of shortcuts, being used by the application ‘Wallch’:

    In this example, the program ‘audacious’, which is a music player available in the Ubuntu Software Center, will be used as an example of adding shortcuts.

    After adding the main characteristics of a launcher, such as filling its ‘Name’ and ‘Exec’ fields, then you can add to it one or more shortcuts.

    After the ‘main body’ of the .desktop file, you have to specify the ‘actions’ you want to add in the ‘Actions’ field and specify each one of them below. Here’s a completely working example of the application ‘audacious’, providing 3 shortcuts, the Play/Pause, Next and Previous. This is a simplified version of the file:

    The part that has to do with the shortcuts is everything after ‘Actions=’ including this. Everything specified on the ‘Actions’ field has its own name, specified on the ‘Name’ field of each one. For example, action PlayPause has name Play-Pause, and thus Play-Pause will be displayed on the shortcut in the Unity Launcher once you right click the icon of ‘audacious’. Clicking on a shortcut will result on the corresponding action, which means it will execute anything specified in the corresponding ‘Exec’ field. Each action has its own ‘Exec’ field, aside from the ‘Exec’ field specified at the beginning of the file which refers to the action that will take place when you click on the launcher.

    Making such shortcuts for applications is generally very easy, unless the application itself doesn’t provide enough command line arguments so as to do a corresponding action you would like to. The arguments and what each one does for every application are available through their man page. For example, the arguments ‘-t’, ‘-f’ and ‘-r’ of ‘audacious’, used on the above example were found though its manual page, using the command

    Читать еще:  Visual c ошибка 0x80240017

    , the arrows so as to browse the manual page and the key ‘Q’ so as to exit. Please, also notice the %U used in the .desktop file above. It is used so as the application to be able to accept an argument when dragging and dropping a file inside the Unity bar on the left. Without it, the program will launch itself, but the argument will not be passed to it and it will be just the same as clicking the application so as to launch.

    A thread for discussion of this wiki can be found on the forum at http://ubuntuforums.org/showthread.php?t=2012385

    UnityLaunchersAndDesktopFiles (последним исправлял пользователь vperetokin 2013-06-19 02:10:14)

    The material on this wiki is available under a free license, see Copyright / License for details
    You can contribute to this wiki, see Wiki Guide for details

    Linux desktop file

    Both the KDE and GNOME desktop environments have adopted a similar format for «desktop entries», or configuration files describing how a particular program is to be launched, how it appears in menus, etc. It is to the larger community’s benefit that a unified standard be agreed upon by all parties such that interoperation between the two environments, and indeed any additional environments that implement the specification, becomes simpler.

    File naming

    Desktop entry files should have the .desktop extension, except for files of Type Directory which should have the .directory extension. Determining file type on basis of extension makes determining the file type very easy and quick. When no file extension is present, the desktop system should fall back to recognition via «magic detection».

    For applications, the part of the name of the desktop file before the .desktop extension should be a valid D-Bus well-known name. This means that it is a sequence of non-empty elements separated by dots (U+002E FULL STOP), none of which starts with a digit, and each of which contains only characters from the set [A-Za-z0-9-_] : ASCII letters, digits, dash (U+002D HYPHEN-MINUS) and underscore (U+005F LOW LINE).

    The name of the desktop entry should follow the «reverse DNS» convention: it should start with a reversed DNS domain name controlled by the author of the application, in lower case. The domain name should be followed by the name of the application, which is conventionally written with words run together and initial capital letters (CamelCase). For example, if the owner of example.org writes «Foo Viewer», they might choose the name org.example.FooViewer , resulting in a file named org.example.FooViewer.desktop .

    Well-known names containing the dash are allowed but not recommended, because the dash is not allowed in some related uses of reversed DNS names, such as D-Bus object paths and interface names, and Flatpak app IDs. If the author’s domain name contains a dash, replacing it with an underscore is recommended: this cannot cause ambiguity, because underscores are not allowed in DNS domain names.

    If the author’s domain name contains a label starting with a digit, (which is not allowed in D-Bus well-known names), prepending an underscore to that element of the desktop entry name is recommended. For example, 7-zip.org might release an application named org._7_zip.Archiver .

    Desktop File ID

    Each desktop entry representing an application is identified by its desktop file ID, which is based on its filename.

    To determine the ID of a desktop file, make its full path relative to the $XDG_DATA_DIRS component in which the desktop file is installed, remove the «applications/» prefix, and turn ‘/’ into ‘-‘.

    For example /usr/share/applications/foo/bar.desktop has the desktop file ID foo-bar.desktop .

    If multiple files have the same desktop file ID, the first one in the $XDG_DATA_DIRS precedence order is used.

    For example, if $XDG_DATA_DIRS contains the default paths /usr/local/share:/usr/share, then /usr/local/share/applications/org.foo.bar.desktop and /usr/share/applications/org.foo.bar.desktop both have the same desktop file ID org.foo.bar.desktop , but only the first one will be used.

    If both foo-bar.desktop and foo/bar.desktop exist, it is undefined which is selected.

    If the desktop file is not installed in an applications subdirectory of one of the $XDG_DATA_DIRS components, it does not have an ID.

    Basic format of the file

    Desktop entry files are encoded in UTF-8. A file is interpreted as a series of lines that are separated by linefeed characters. Case is significant everywhere in the file.

    Compliant implementations MUST not remove any fields from the file, even if they don’t support them. Such fields must be maintained in a list somewhere, and if the file is «rewritten», they will be included. This ensures that any desktop-specific extensions will be preserved even if another system accesses and changes the file.


    Lines beginning with a # and blank lines are considered comments and will be ignored, however they should be preserved across reads and writes of the desktop entry file.

    Comment lines are uninterpreted and may contain any character (except for LF). However, using UTF-8 for comment lines that contain characters not in ASCII is encouraged.

    Group headers

    A group header with name groupname is a line in the format:

    Group names may contain all ASCII characters except for [ and ] and control characters.

    Multiple groups may not have the same name.

    All pairs following a group header until a new group header belong to the group.

    The basic format of the desktop entry file requires that there be a group header named Desktop Entry . There may be other groups present in the file, but this is the most important group which explicitly needs to be supported. This group should also be used as the «magic key» for automatic MIME type detection. There should be nothing preceding this group in the desktop entry file but possibly one or more comments.


    Entries in the file are pairs in the format:

    Space before and after the equals sign should be ignored; the = sign is the actual delimiter.

    Only the characters A-Za-z0-9- may be used in key names.

    As the case is significant, the keys Name and NAME are not equivalent.

    Multiple keys in the same group may not have the same name. Keys in different groups may have the same name.

    Possible value types

    The value types recognized are string , localestring , iconstring , boolean , and numeric .

    Values of type string may contain all ASCII characters except for control characters.

    Values of type localestring are user displayable, and are encoded in UTF-8.

    Values of type iconstring are the names of icons; these may be absolute paths, or symbolic names for icons located using the algorithm described in the Icon Theme Specification. Such values are not user-displayable, and are encoded in UTF-8.

    Values of type boolean must either be the string true or false .

    Values of type numeric must be a valid floating point number as recognized by the %f specifier for scanf in the C locale.

    The escape sequences s , n , t , r , and \ are supported for values of type string , localestring and iconstring , meaning ASCII space, newline, tab, carriage return, and backslash, respectively.

    Some keys can have multiple values. In such a case, the value of the key is specified as a plural: for example, string(s) . The multiple values should be separated by a semicolon and the value of the key may be optionally terminated by a semicolon. Trailing empty strings must always be terminated with a semicolon. Semicolons in these values need to be escaped using ; .

    Localized values for keys

    Keys with type localestring and iconstring may be postfixed by [ LOCALE ], where LOCALE is the locale type of the entry. LOCALE must be of the form lang _ COUNTRY . ENCODING @ MODIFIER , where _ COUNTRY , . ENCODING , and @ MODIFIER may be omitted. If a postfixed key occurs, the same key must be also present without the postfix.

    When reading in the desktop entry file, the value of the key is selected by matching the current POSIX locale for the LC_MESSAGES category against the LOCALE postfixes of all occurrences of the key, with the . ENCODING part stripped.

    The matching is done as follows. If LC_MESSAGES is of the form lang _ COUNTRY . ENCODING @ MODIFIER , then it will match a key of the form lang _ COUNTRY @ MODIFIER . If such a key does not exist, it will attempt to match lang _ COUNTRY followed by lang @ MODIFIER . Then, a match against lang by itself will be attempted. Finally, if no matching key is found the required key without a locale specified is used. The encoding from the LC_MESSAGES value is ignored when matching.

    If LC_MESSAGES does not have a MODIFIER field, then no key with a modifier will be matched. Similarly, if LC_MESSAGES does not have a COUNTRY field, then no key with a country specified will be matched. If LC_MESSAGES just has a lang field, then it will do a straight match to a key with a similar value. The following table lists possible matches of various LC_MESSAGES values in the order in which they are matched. Note that the ENCODING field isn’t shown.

    Table 1. Locale Matching

    For example, if the current value of the LC_MESSAGES category is sr_YU@Latn and the desktop file includes:

    then the value of the Name keyed by sr_YU is used.

    Although icon names of type iconstring are localizable, they are not human-readable strings, so should typically not be handled by translation tools. Most applications are not expected to localize their icons; exceptions might include icons containing text or culture-specific symbology.

    Читать еще:  Mkfifo linux пример

    Recognized desktop entry keys

    Keys are either OPTIONAL or REQUIRED. If a key is OPTIONAL it may or may not be present in the file. However, if it isn’t, the implementation of the standard should not blow up, it must provide some sane defaults.

    Some keys only make sense in the context when another particular key is also present and set to a specific value. Those keys should not be used if the particular key is not present or not set to the specific value. For example, the Terminal key can only be used when the value of the Type key is Application .

    If a REQUIRED key is only valid in the context of another key set to a specific value, then it has to be present only if the other key is set to the specific value. For example, the URL key has to be present when and only when when the value of the Type key is Link .

    Some example keys: Name[C] , Comment[it] .

    Table 2. Standard Keys

    A list of strings identifying the desktop environments that should display/not display a given desktop entry.

    By default, a desktop file should be shown, unless an OnlyShowIn key is present, in which case, the default is for the file not to be shown.

    If $XDG_CURRENT_DESKTOP is set then it contains a colon-separated list of strings. In order, each string is considered. If a matching entry is found in OnlyShowIn then the desktop file is shown. If an entry is found in NotShowIn then the desktop file is not shown. If none of the strings match then the default action is taken (as above).

    $XDG_CURRENT_DESKTOP should have been set by the login manager, according to the value of the DesktopNames found in the session file. The entry in the session file has multiple values separated in the usual way: with a semicolon.

    The same desktop name may not appear in both OnlyShowIn and NotShowIn of a group.

    The Exec key

    The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment. The name or path of the executable program may not contain the equal sign («=»). Arguments are separated by a space.

    Arguments may be quoted in whole. If an argument contains a reserved character the argument must be quoted. The rules for quoting of arguments is also applicable to the executable name or path of the executable program as provided.

    Quoting must be done by enclosing the argument between double quotes and escaping the double quote character, backtick character («`»), dollar sign («$») and backslash character («») by preceding it with an additional backslash character. Implementations must undo quoting before expanding field codes and before passing the argument to the executable program. Reserved characters are space (» «), tab, newline, double quote, single quote («‘»), backslash character («»), greater-than sign («>»), less-than sign (» %% . Deprecated field codes should be removed from the command line and ignored. Field codes are expanded only once, the string that is used to replace the field code should not be checked for field codes itself.

    Command lines that contain a field code that is not listed in this specification are invalid and must not be processed, in particular implementations may not introduce support for field codes not listed in this specification. Extensions, if any, should be introduced by means of a new key.

    Implementations must take care not to expand field codes into multiple arguments unless explicitly instructed by this specification. This means that name fields, filenames and other replacements that can contain spaces must be passed as a single argument to the executable program after expansion.

    Although the Exec key is defined to have a value of the type string, which is limited to ASCII characters, field code expansion may introduce non-ASCII characters in arguments. Implementations must take care that all characters in arguments passed to the executable program are properly encoded according to the applicable locale setting.

    The Linux Critic

    Set your computer free

    Anatomy of a .desktop File

    One of the beautiful things about Linux is that developers tend to be conscientious about the use of technical standards. Freedesktop.org maintains a wide series of standards for X Window System desktops, which apply to Gnome, KDE, LXDE and XFCE (I’m not sure whether Fluxbox implements these standards.) The standard for “desktop entries” is still technically a draft, but is generally accepted by the larger X community.

    The .desktop file fills two primary functions: first, it informs the desktop environment how the file is to be handled by the desktop environment with regard to menu placement, display, environmental variables, and similar. In this function, it resides globally in /usr/share/applications/ and for specific users in $HOME/.local/applications . The second function is the direct shortcut on the desktop itself. In this function, it resides in $HOME/Desktop . The same file fills both functions, so if you want to have an application both in the menu and on your desktop, you’ll need to put the .desktop file in two places. Let’s take a closer look, shall we?

    The .desktop file is generally in a key,value pair format. This means that, generally speaking, each line will look like this:

    Required Elements

    Type – specifies the type of desktop entry. Currently, there are three valid types: Application , Link and Directory .
    Name – The name of the specific application or directory. This determines the actual display name for the menu/desktop entry.
    Exec – provides the actual command to execute, with associated arguments (if necessary.)

    Optional Elements

    Version – specifies the version of the Desktop Entry Specification to which the .desktop file conforms (currently 1.0).
    Encoding – The encoding for the .desktop file. The standard calls for UTF-8.
    GenericName – specifies the generic name of the application.
    NoDisplay – This is a boolean (i.e. true/false) element. If set to “true”, it means “this application exists but should not appear in menus.” This is most frequently used to associate an application with MIME types so file managers know how to handle things.
    Comment – specifies tooltip entries for the file.
    Icon – specifies the icon to be used. This entry supports both icons supported under the FreeDesktop Icon Theme Specification (which I haven’t yet fully grokked) as well as absolute paths.
    Hidden – another boolean entry which, if true, essentially treats the application as having been deleted.
    OnlyShowIn – If you use multiple desktop environments (say, for instance, you use both Gnome and LXDE) and only want the .desktop entry to apply to a few of the environments, this line specifies the environments in which the entry should apply. This entry is mutually exclusive with NotShowIn .
    NotShowIn – As above, but instead of specifying where to display the entry, it displays where NOT to display the entry. This is more useful if you have numerous environments but only want to exclude one or two.
    Path – specifies the working directory for an application to run in.
    Terminal – a boolean entry which specifies whether or not the application requires a terminal to run.
    MimeType – specifies any associated MIME types with this application.
    Categories – Categories in which this application should appear in menus. Supported categories vary from system to system, but there is an emerging standard for categories.

    Finally, any line beginning with an octothorpe (“#”) is considered a comment.

    Putting It All Together

    Now that we have all the elements, we can open up any text editor and create a .desktop entry. Here’s a very simple sample:

    [Desktop Entry]
    Name=My Application

    Save your entry (as filename.desktop), then put a copy in $HOME/.local/applications and (if you want) another in $HOME/Desktop . If you did it right (and if you’re running Gnome, KDE or LXDE), your new application should show up in your menu and (possibly) on your desktop.

    How to Add Application Shortcuts on Ubuntu Desktop

    Last updated October 13, 2019 By Abhishek Prakash 18 Comments

    In this quick tutorial, you’ll learn how to add application shortcuts on desktop in Ubuntu and other distributions that use GNOME desktop.

    A classic desktop operating systems always have icons on the ‘desktop screen’. These desktop icons could include the file manager, the trash bin and the shortcut to applications.

    While installing applications in Windows, some of the programs ask if you want to create a shortcut on the desktop. That’s not the case in Linux though.

    But if you are a fan of this feature, let me show you how you can add desktop shortcuts to your favorite applications in Ubuntu and other Linux distributions.

    In case you are wondering about the looks of my desktop, I am using Ant theme with Tela icons. You can also get some GTK themes and icons for Ubuntu and change them as you like.

    Adding desktop shortcut in Ubuntu

    Personally I prefer the Ubuntu launcher for application shortcuts. If I use a program frequently, I add it to the launcher. But I know not everyone has the same preference and a few people prefer the shortcuts on the desktop.

    Let’s see the simplest way of creating an application shortcut on the desktop.

    This tutorial has been tested on Ubuntu 18.04 LTS with GNOME desktop. It may work in other distributions and desktop environments but you have to try it on your own. Some GNOME specific steps may change so please pay attention while trying it on other desktop environments.

    Читать еще:  Ошибка 324 net err empty response


    First and foremost thing is to make sure that you have icons allowed on the GNOME desktop.

    If you followed the Ubuntu 18.04 customization tips, you know how to install GNOME Tweak tool. In this tool, make sure that you have ‘Show Icons’ option enabled.

    Once you have made sure of that, it’s time to add some application shortcuts on the desktop.

    Step 1: Locate the .desktop files of applications

    Go to Files -> Other Location -> Computer.

    From here, go to the directory usr -> share -> applications. You’ll see icons of several Ubuntu applications you have installed here. Even if you don’t see the icons, you should see the .desktop files that are named as application.desktop.

    Step 2: Copy the .desktop file to desktop

    Now all you have to do here is to look for the application icon (or its desktop file). When you find it, either drag-drop the file to the desktop or copy the file (using Ctrl+C shortcut) and paste it on the desktop (using Ctrl+V shortcut).

    Step 3: Run the desktop file

    When you do that, you should see a text file kind of icon on the desktop instead of the logo of the application. Don’t worry, things will be different in a moment.

    What you have to do is to double click on that file on the desktop. It will warn you that it’s an ‘untrusted application launcher’ so click on Trust and Launch.

    The application will launch as usual but the good thing that you’ll notice that the .desktop file has now turned into the application icon. I believe you like the application shortcuts this way, don’t you?

    Troubleshoot for Ubuntu 19.04 or GNOME 3.32 users

    If you use Ubuntu 19.04 or GNOME 3.32, you the .desktop file may not launch at all. You should right click on the .desktop file and select “Allow Launching”.

    After this, you should be able to launch the application and the application shortcut should be displayed properly on the desktop.


    If you don’t like a certain application launcher on the desktop, just select it and delete it. It will delete the shortcut but the application will remain safely in your system.

    I hope you found this quick tip helpful and now you can enjoy the application shortcuts on Ubuntu desktop.

    If you have questions or suggestions, please let me know in the comments below.

    Like what you read? Please share it with others.

    About Abhishek Prakash

    I am a professional software developer, and founder of It’s FOSS. I am an avid Linux lover and open source enthusiast. I use Ubuntu and believe in sharing knowledge. Apart from Linux, I love classic detective mysteries. I’m a huge fan of Agatha Christie’s work.

    I am really wondering if the goal with Ubuntu 18 was to totally go backwards with the UI design usability? If so they have done an outstanding job. it is a major pain in the ass to install apps not listed in the ubuntu software center. And no matter what it is purely impossible to find apps after you install them. WHAT A POS this version is. I AM SERIOUSLY NOT IMPRESSED. Wasting hours and hours of my god damn time having to google and google and search and try and google. GTFO seriously a millennial has to be to blame for this level of stupid. I made a major mistake upgrading from ubuntu 16 to this POS pain in the ass

    You can also right click and select “Allow Launching”.

    So how do you move the Desktop icon to the favorites bar? Some items are just desktop shortcuts and not on the “Applications” screens, so there is no option to right-click and “Add to Favorites”

    I am still trying to figure out where the hell ubuntu is putting my apps after they install and how do I find them to open them, much less making short cuts. WHAT A POS

    What should we do if the app is not appearing the prescribed location?

    This is my 2nd evening struggling with Zorin OS 15 (yes, struggling with Zorin – don’t laugh, I’m fresh from Windows 7). I thought I’d add that in Zorin you can right-click launcher shortcuts (the program names that appear under the categories like Accessories and Office) and simply select “Add to Desktop”.

    I’ve seen your name on a few of the guides I’ve found helpful, Abhishek, so thanks to you and to everyone else who takes the time to write clear guidance for us noobs.

    8 Most Awesome Quick File Searching Tools for Linux Desktop

    Over the years we have covered some of the best file searching tools for the Linux desktop and till date, the titles that we covered remain the most sought out for by users.

    Today, we bring you a compiled list of the 8 most awesome so that you don’t have to do all that work yourself any longer.

    1. Cerebro

    Cerebro is a cross-platform, system-wide search tool for any Linux distro that enables users to quickly search for and navigate to any file anywhere in their system.

    Cerebro features a modern minimalist UI with plugin support and the ability to display accurate previews of the files in the search results.

    Cerebro – Desktop Filesystem Search App

    2. Synapse

    Synapse is a smart launcher with extensive searching capabilities. It is powered by the Zeitgeist engine which enables users to search for anything logged by the Zeitgeist.

    Apart from just searching for desktop files, you can use it to search for documentation, find word definitions, play music files in Banshee, and comes out of the box with 4 themes to choose from.

    Its abilities can also be extended using plugins and it can be summoned universally by pressing Ctrl+Space .

    Synapse Application Launcher for Ubuntu

    3. FSearch

    Fsearch is an advanced searching tool for Unix and all Unix-like platforms with a plethora of features including the ability to filter file and folder search results, use wildcards, Regular Expressions, and work with keyboard shortcuts.

    FSearch is popular for its speed, which coupled with a nice UI, is bound to provide you with an enjoyable use.

    FSearch – Search Tool for Desktop

    4. ULauncher

    Ulauncher is a smart app launcher that you can also use to efficiently search for any files and settings on your system.

    You can use it to instantly search for apps, settings, and files, and you can perform searches by using location paths as a filter. It also features integration with Google and Wikipedia so you can perform online searches directly from your desktop. You should definitely check ULauncher out.

    Ulauncher for Ubuntu

    5. ANGRYsearch

    ANGRYsearch is a performance-focused file searching tool that instantly populates its search result fields as you type. Just like FSearch, it offers quick file indexing, RegEx support, a clean UI, and support for all Linux distros.

    It also features 3 search modes with different search results properties – slow, fast, and regex; and 2 use modes – Lite and Full. You should definitely check ANGRYsearch out.

    AngrySearch File Search Tools

    6. Catfish

    Catfish is a speedy search tool especially because it takes advantage of the presence of files already in your machine to handle your search queries.

    You can use it to search for hidden files and work with it via the terminal. Catfish, among other tools, is a Linux productivity tool worth your time.

    Catfish File Searching Tool

    7. Krunner

    Krunner is the open-source launcher (Alt + F2 or Alt + SPACE) built into the popular Plasma desktop environment with the ability to have its functions extended using plugins referred to as “runners”.

    It is available to install as a stand-alone app launcher provided you install the dependencies listed on its website where you will also find an inexhaustive list of what you can use it for and that includes opening apps, making calculations, accessing bookmarks, opening web pages, etc.

    8. Recoll

    Recoll is an open-source full-text search system created for Unix/Linux users to make a full-text search using a GUI. It is capable of finding documents based on their file names, content, attachment, etc. For example, Recoll can index the content of word documents in a zip file in Thunderbird – awesome stuff.

    Recoll – Desktop Search Tool

    You can extend Recoll’s functionality using external applications for text attraction and it also has versions for Windows and macOS platforms.

    All the listed tools here are excellent at searching and launching files among other capabilities like looking up word definitions and launching applications. And despite their similar features, they all have their unique qualities so it is left to you to make your choice.

    Have you got any experience with these tools? Or maybe I have left out some cool titles. Drop your comments in the section below.

    Your Unwavering Support Matters a Lot:

    The cost of maintenance is skyrocketing as more readers are coming on board and the ad service that we employ in order to generate revenue is unfortunately no longer sufficient and this is especially due to the increased use of ad-blockers.

    We humbly request that you consider disabling your ad-blockers to support us financially or please consider buying us a coffee ( or 2 ) as a token of appreciation. Your donation(s) will go a long way in supporting FossMint and sister site, TecMint, in running efficiently. Thank you.

    Ссылка на основную публикацию