Struct DesktopEntry

Source
pub struct DesktopEntry {
Show 24 fields pub xdg_type: DesktopType, pub version: String, pub name: Option<String>, pub generic_name: Option<String>, pub no_display: Option<bool>, pub comment: Option<String>, pub icon: Option<String>, pub hidden: Option<bool>, pub only_show_in: Option<Vec<DesktopEnvironment>>, pub not_show_in: Option<Vec<DesktopEnvironment>>, pub dbus_activatable: Option<bool>, pub try_exec: Option<String>, pub exec: Option<String>, pub path: Option<String>, pub terminal: Option<bool>, pub actions: Option<Vec<String>>, pub mime_type: Option<Vec<String>>, pub categories: Option<Vec<Categories>>, pub implements: Option<Vec<String>>, pub keywords: Option<Vec<String>>, pub startup_notify: Option<bool>, pub startup_wm_class: Option<String>, pub url: Option<String>, pub prefers_non_default_gpu: Option<bool>,
}
Expand description

§Desktop Entry Files

Option<String> will be used for all localeString/String

Option<Vec<String>> for all localeString(s)/String(s)

Option<bool> will be used for all boolean

f32 for version number

DesktopType enumerates known “Type” fields and the “Unknown” reserved “Type”

type is a reserved word in rust, so it is called ‘xdg_type’

I copied and pasted the website here and made things rustified

No camelcase inside structs, all lowercase/underscore version of CamelCase

The text following is from the XDG webpage:

§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.

Fields§

§xdg_type: DesktopType

This specification defines 3 types of desktop entries: Application (type 1), Link (type 2) and Directory (type 3). To allow the addition of new types in the future, implementations should ignore desktop entries with an unknown type.

§version: String

Version of the Desktop Entry Specification that the desktop entry conforms with. Entries that confirm with this version of the specification should use 1.5. Note that the version field is not required to be present.

§name: Option<String>

Specific name of the application, for example “Mozilla”.

§generic_name: Option<String>

Generic name of the application, for example “Web Browser”.

§no_display: Option<bool>

NoDisplay 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 (there are tons of good reasons for this, including e.g. the netscape -remote, or kfmclient openURL kind of stuff).

§comment: Option<String>

Tooltip for the entry, for example “View sites on the Internet”. The value should not be redundant with the values of Name and GenericName.

§icon: Option<String>

Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be used. If the name is not an absolute path, the algorithm described in the Icon Theme Specification will be used to locate the icon.

§hidden: Option<bool>

Hidden should have been called Deleted. It means the user deleted (at his level) something that was present (at an upper level, e.g. in the system dirs). It’s Stringictly equivalent to the .desktop file not existing at all, as far as that user is concerned. This can also be used to “uninstall” existing files (e.g. due to a renaming) - by letting make install install a file with Hidden=true in it.

§only_show_in: Option<Vec<DesktopEnvironment>>

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 Stringing 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.

§not_show_in: Option<Vec<DesktopEnvironment>>§dbus_activatable: Option<bool>

A boolean value specifying if D-Bus activation is supported for this application. If this key is missing, the default value is false. If the value is true then implementations should ignore the Exec key and send a D-Bus message to launch the application. See D-Bus Activation for more information on how this works. Applications should still include Exec= lines in their desktop files for compatibility with implementations that do not understand the DBusActivatable key.

§try_exec: Option<String>

Path to an executable file on disk used to determine if the program is actually installed. If the path is not an absolute path, the file is looked up in the $PATH environment variable. If the file is not present or if it is not executable, the entry may be ignored (not be used in menus, for example).

§exec: Option<String>

Program to execute, possibly with arguments. See the Exec key for details on how this key works. The Exec key is required if DBusActivatable is not set to true. Even if DBusActivatable is true, Exec should be specified for compatibility with implementations that do not understand DBusActivatable.

§path: Option<String>

If entry is of type Application, the working directory to run the program in.

§terminal: Option<bool>

Whether the program runs in a terminal window.

§actions: Option<Vec<String>>

Identifiers for application actions. This can be used to tell the application to make a specific action, different from the default behavior. The Application actions section describes how actions work.

§mime_type: Option<Vec<String>>

The MIME type(s) supported by this application.

§categories: Option<Vec<Categories>>

Categories in which the entry should be shown in a menu for possible values see the Desktop Menu Specification.

§implements: Option<Vec<String>>

A list of interfaces that this application implements. By default, a desktop file implements no interfaces. See Interface for more information on how this works.

§keywords: Option<Vec<String>>

A list of Strings which may be used in addition to other metadata to describe this entry. This can be useful e.g. to facilitate searching through entries. The values are not meant for display, and should not be redundant with the values of Name or GenericName.

§startup_notify: Option<bool>

If true, it is KNOWN that the application will send a “remove” message when started with the DESKTOP_STARTUP_ID environment variable set. If false, it is KNOWN that the application does not work with startup notification at all (does not shown any window, breaks even when using StartupWMClass, etc.). If absent, a reasonable handling is up to implementations (assuming false, using StartupWMClass, etc.). See the Startup Notification Protocol Specification for more details.

§startup_wm_class: Option<String>

If specified, it is known that the application will map at least one window with the given Stringing as its WM class or WM name hint see the Startup Notification Protocol Specification for more details.

§url: Option<String>

If entry is Link type, the URL to access.

§prefers_non_default_gpu: Option<bool>

If true, the application prefers to be run on a more powerful discrete GPU if available, which we describe as “a GPU other than the default one” in this spec to avoid the need to define what a discrete GPU is and in which cases it might be considered more powerful than the default GPU. This key is only a hint and support might not be present depending on the implementation.

Implementations§

Source§

impl DesktopEntry

Implementations

Source

pub fn empty(initial_type: DesktopType) -> Self
where Self: Sized,

Creates a blank entry with a specified type

Source

pub fn new(file_name: String) -> Self
where Self: Sized,

Creates a ‘new’ DesktopEntry from reading a file note: xdgkit does not check the file extention, you may want to This reads not only .desktop files but also .directory

Source

pub fn read(file_string: String) -> Self
where Self: Sized,

Creates a ‘new’ DesktopEntry from reading a file note: xdgkit does not check the file extention, you may want to This reads not only .desktop files but also .directory

Trait Implementations§

Source§

impl Clone for DesktopEntry

Source§

fn clone(&self) -> DesktopEntry

Returns a duplicate of the value. Read more
1.0.0 · Source§

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source. Read more
Source§

impl Debug for DesktopEntry

Source§

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter. Read more
Source§

impl Default for DesktopEntry

Source§

fn default() -> Self

Returns the “default value” for a type. Read more

Auto Trait Implementations§

Blanket Implementations§

Source§

impl<T> Any for T
where T: 'static + ?Sized,

Source§

fn type_id(&self) -> TypeId

Gets the TypeId of self. Read more
Source§

impl<T> Borrow<T> for T
where T: ?Sized,

Source§

fn borrow(&self) -> &T

Immutably borrows from an owned value. Read more
Source§

impl<T> BorrowMut<T> for T
where T: ?Sized,

Source§

fn borrow_mut(&mut self) -> &mut T

Mutably borrows from an owned value. Read more
Source§

impl<T> CloneToUninit for T
where T: Clone,

Source§

unsafe fn clone_to_uninit(&self, dest: *mut u8)

🔬This is a nightly-only experimental API. (clone_to_uninit)
Performs copy-assignment from self to dest. Read more
Source§

impl<T> From<T> for T

Source§

fn from(t: T) -> T

Returns the argument unchanged.

Source§

impl<T, U> Into<U> for T
where U: From<T>,

Source§

fn into(self) -> U

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

Source§

impl<T> ToOwned for T
where T: Clone,

Source§

type Owned = T

The resulting type after obtaining ownership.
Source§

fn to_owned(&self) -> T

Creates owned data from borrowed data, usually by cloning. Read more
Source§

fn clone_into(&self, target: &mut T)

Uses borrowed data to replace owned data, usually by cloning. Read more
Source§

impl<T, U> TryFrom<U> for T
where U: Into<T>,

Source§

type Error = Infallible

The type returned in the event of a conversion error.
Source§

fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>

Performs the conversion.
Source§

impl<T, U> TryInto<U> for T
where U: TryFrom<T>,

Source§

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.
Source§

fn try_into(self) -> Result<U, <U as TryFrom<T>>::Error>

Performs the conversion.