1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
xdg-utils
---------
The xdg-utils package is a set of simple scripts that provide
basic desktop integration functions for any Free Desktop, such as Linux.
They are intended to provide a set of defacto standards. This
means that:
* Third party software developers can rely on these xdg-utils
for all of their simple integration needs.
* Developers of desktop environments can make sure that their
environments are well supported
If a desktop developer wants to be certain that their environment
functions with all third party software, then can simply
make sure that these utilities work properly in their environment.
This will hopefully mean that 'third tier' window managers
such as XFCE and Blackbox can reach full parity with Gnome and KDE
in terms of third party ISV support.
* Distribution vendors can provide custom versions of these utilities
If a distribution vendor wishes to have unusual systems,
they can provide custom scripts, and the third party software
should still continue to work.
OVERVIEW:
---------
The following scripts are provided at this time.
This is an early release of xdg-utils, and we hope to rapidly
add more utilities.
xdg-menu Place a menu into the users menu structure
xdg-mime Gather mime information about a file
xdg-open Open a URL in the user's preferred application that
handles the respective URL or file type
xdg-email Open the users preferred email client,
potentially with subject and other info filled in
xdg-copy Copy one URI to another
xdg-su Run a command as a different (usually root) user
xdg-screensaver Enable, disable, or suspend the screensaver
BUILD:
------
Building the xdg-utils should be very simple. First,
you need to obtain the source and extract it to a directory
on your system. Change directories to that directory and
run the following commands:
./configure
make
This will make all of the xdg-utils scripts; they
will be located in the scripts/ subdirectory and will
have names such as 'xdg-menu', or 'xdg-mime', and so on.
You can optionally choose to install the scripts
to a target directory. To do this, you could issue
the following commands:
./configure [--prefix=<your-place-here>]
make install
that would cause the scripts to be installed to
<your-place-here>/bin
USE:
----
Although we expect that these scripts will generally come as part
of the operating system, we recommend that you package the scripts
that your application needs along with your product as a fallback. For
this purpose please obtain the original version of the xdg-utils from
http://portland.freedesktop.org. The xdg-utils scripts that are
distributed by operating systems vendors may have been tuned for their
particular operating system and may not work on the same broad variety
of operating systems as the original version.
We recommend that you place these scripts in a directory, and
then add that directory to the end of the PATH. So, let's say that
you're writing your post installation script, and you want to create
a menu on any xdg-util compliant environment. Let's further assume
that you've just installed to $INSTALL_DIR, and that your menu
desktop file is in $INSTALL_DIR/desktop/icon.desktop. Finally, let's
say that you've included the xdg-utils package in your installation
in $INSTALL_DIR/xdg-utils.
Then a simple post install script could look like this:
export PATH=$PATH:$INSTALL_DIR/xdg-utils
xdg-menu --create $INSTALL_DIR/icon.desktop
And now your product has a menu on any XDG compliant desktop!
Note that we strongly recommend using this method - that is,
putting your copy of the xdg-utils at the end of the path,
and then invoking them without a specific path name.
That will allow your users and their system providers to
use custom versions of the xdg-utils which should work better
for them.
If you wish to absolutely force the issue and only use the versions
you shipped, you could instead hard code the path to the version
you bundle with your application. We strongly recommend against
this, as it will make your product obsolete more quickly than is
necessary.
|
