SCIENTIFIC-LINUX-USERS Archives

November 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Sun, 20 Nov 2011 09:12:09 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (93 lines)
On 11/20/2011 06:56 AM, g wrote:
> On 11/20/2011 08:14 AM, Yasha Karant wrote:
> <>
>
>> If this is not typical, I suspect that one of the application RPMs that
>> I loaded from a repository or source other than SL6x may have altered a
>> system level icon search path.
>
> possible. or it is the specific program/s that you have loaded.
>
>
> from:
>
>    http://tldp.org/
>
> searching "/usr/local" for below.
>
> have a read of;
>
>    http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
>
> especially section "usr/local" for purpose of path.
>
>
> and;
>
>    http://tldp.org/LDP/sag/html/usr-fs.html
>
>
> hth you understand usage of "/usr/local".
>

Thank you for the URL; however, I was aware of that hierarchy that 
derived from a merger of the Sys V R4 and BSD hierarchies, both of which 
partially evolved through the crucible of direct experience.

Unfortunately, applications and application developers, including some 
proprietary commercial applications that have been ported to Linux 
(either from closed systems or from commercial Unix, BSD, or Mac OS X 
that internally is more or less BSD), do not properly recognize that 
hierarchy.  In the case of open systems applications for which full 
source code is available, it would be possible to rewrite the 
application to respect the hierarchy, but this is not always feasible 
and may cause an incompatible offshoot development tree (very hard to 
maintain, even with the various tools available).

Hence, I was attempting to find where (which files, which code lines 
within those files) the configuration information is kept for which 
icons to use with gnome. I note that a shell that forks and execs from a 
Xwindows window manager does not always reflect this in detail.  Thus, 
env from a default bash running within a gnome-terminal GUI under gnome 
shows no mention of any
"share" .

Note that a typical Desktop/ entry:

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=LyX
GenericName=Structured Word Processor
Comment=WYSIWYM (What You See Is What You Mean) word processor with 
LaTeX output
Exec=lyx
Icon=lyx
MimeType=application/x-lyx;text/x-lyx;
Type=Application
Encoding=UTF-8
Categories=Office;WordProcessor;

X-Desktop-File-Install-Version=0.10

End entry

shows Icon=lyx without showing an absolute path to that icon nor an 
extension (e.g., lyx.png).  Had there been an absolute path, one could 
modify the Desktop, etc., entry or considered a soft link from one path 
to another -- both approaches having issues with long term stability and 
compatibility.

(As an aside, to find and read the above file:

[ykarant@localhost ~]$ cd Desktop/
[ykarant@localhost Desktop]$ grep -i lyx *
eek-004f38e0f8.desktop:Name=LyX
eek-004f38e0f8.desktop:Exec=lyx
eek-004f38e0f8.desktop:Icon=lyx
eek-004f38e0f8.desktop:MimeType=application/x-lyx;text/x-lyx;
[ykarant@localhost Desktop]$ less eek-004f38e0f8.desktop

end aside)

Yasha Karant

ATOM RSS1 RSS2