Is "/usr/local/lib/X11/pixmaps" std. in most Linuxes?

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Post Reply
Message
Author
User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

Is "/usr/local/lib/X11/pixmaps" std. in most Linuxes?

#1 Post by sunburnt »

I`m wondering if Puppy`s default misc. icon path is typical for Linux distros.

And "/usr/local/lib/X11/mini-icons" also?

I need to know if to include them as default paths for icons.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#2 Post by amigo »

No, no other distro includes _anything_ under /usr/local/anything!
/usr/local is supposed to be clean of files when a distro is 'delivered' and no package should install anything under /usr/local, as it is meant to be reserved for use by the local administrator for locally compiled software and 'uninstalled' scripts.

Most current distros will have such things under /usr/lib with links that point there from /usr/lib/X11 and (perhaps) /usr/X11. Modern X is meant to be compiled and installed for plain '/usr' as the prefix.

When dealing with paths under Puppy you can always assume that it is done differently than *any other* distro.

Further more, I think that 'mini-icons' is not a standard at all. What program(s) are accessing those icons?

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#3 Post by sunburnt »

Hi amigo; Long time no talk to...

I think Barry puts general system icons in there, and a few app. icons too.
In /usr/share/pixmaps and /usr/share/icons he puts app. icons,
but not necessarily apps. that Puppy has installed.

Like most things Linux, there seems to be no organization. ( Maybe just Puppy? )
I`d have icon dirs. for installed apps., added apps., and general icons.

Debian packages seem to put app. icons in /usr/share/pixmaps
# Does that seem like a good default place for apps. to look?

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#4 Post by amigo »

OK, /usr/share/pixmpas and /usr/share/icons are standard locations. pixmpas should really only have *.xpm images and no subdirectories.
/usr/share/icons should contain the subdir structure with 16x16, 24x24, 32x32, 64x64 and 128x128 directories, and any ison themes will install into a single subdirectory under /usr/share/icons for each theme.

The directory /usr/share/icons/default is the default theme(when user has not specified a theme). 'default' is usually just a link to one of the installed theme directories. When dealing with gtk programs, some of them will respect a themedir (specified in the users ~.gtkrc file).

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#5 Post by technosaurus »

Just to get an idea of how ridiculous it was, I did a little experiment to simplify the whole filesystem. All binaries in /bin (cut binary load times), all libraries in /lib (cut library load times), all modules in /lib/modules/<kernel_version> (this part required some patches that drastically sped up module load times and cut size of *mod* tools). Zero problems other than various module tools with hardcoded module paths (easily found by grepping source for /lib/modules ... ndiswrapper for 1) various other simplifications via symlinks.

I won't get into the insanity of using /usr/local/appname instead of /usr/share/appname ... Which would be $DATADIR/appname which is typically $PREFIX/share with --prefix=/usr being standard for "official" builds.

It does lack some capabilities that I use, but noone else seems to have caught on to, such as having a download script for each app (actually a symlink) in /usr/local/bin that installs that app ... That way we minimize errors due to missing apps... Easily fixed by changing the code to something like petget $0 -- call it a filesystem based installer ... If one wanted, the app icons could have been symlinks too.

It was a good learning exercise, but then again I would try to reduce the legal system to about roughly 5 laws and taxes to a flat rate "disposable income tax" where everyone pays the same rate on _all_ income above the poverty line, no vat or corporate tax, deductions or anything else.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#6 Post by sunburnt »

amigo; Well... Puppy doesn`t abide by any of the rules you speak of.
However it does have the sized icon dirs. in /usr/share/icons/hicolor
But no themes in /usr/share/icons, I assume they`d be theme icons.
Puppy has theme files in /usr/share/themes

I wonder about the scripting effort needed to rearrange things like this.
I would think this stuff would be pretty locked in place like other deps.

The pre-sized icons make sense as I use vovchik`s picscale to resize
in my poppyMenu app. Slow menu loading and higher cpu use.

### I guess I`ll settle on /usr/share/pixmaps as a default path.


technosaurus; Oddly that`s an experiment I`d thought of doing.
And your results are consistent with what I`d expect to find.

# And I`d add a 100% inheritance tax above 1 million for each heir.
# This negates greed, the reason for accumulating vast wealth.


I moved files and replaced the dirs. with links in Puppy`s main SFS file:
/usr/bin => /bin
/usr/sbin => /bin
/usr/local/bin => /bin
/usr/local/sbin => /bin
/usr/X11R7/bin => /bin
/etc => /root/my-applications/etc
/usr/etc => /root/my-applications/etc
/usr/local/etc => /root/my-applications/etc
/usr/lib => /lib
/usr/X11R7/lib => /lib

/root is the writable dir., the rest is the read-only SFS fixed base O.S.
This in keeping with my philosophy of read-only and read-write dirs.
The $PATH and $LD_LIBRARY_PATH only had 2 paths in each:
Read-Only: /bin and /lib
ReadWrite: /root/my-applications/bin and /root/my-applications/lib

There`s only 1 place for an app. to reference it`s unshared deps.:
/usr/share/(app. dep. dir.)
(Some dep. exec. files are in $PATH)

/bin and /lib have paths. NOW, if deps. had an external settable path...

And 2 places for the system menu to reference an app.:
/usr/share/applications
/usr/share/(std. icon dir.?)
(Exec. files are usually in $PATH or menu has path.)

It would be nice if apps. were compiled with relative paths.
Relative paths to app. deps. would make modules relocatable.
Compiling with -prefix (app. dir.) works, but not relocatable (links?).
It`s important that app. modules can be on HD, USB, LAN, web, etc.

Some dislike the Linux base O.S. file setup. So what? It`s not critical.
The Linux base O.S. works well (mostly), but apps. are incompatible.
Modules solve: non-std. apps., legacy loose file installs, lib. conflicts.
Relocatable no-install modules isolate each other and the base O.S.

And distros. built on Squash files are small, fast, and reliable. (Puppy)

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#7 Post by amigo »

'hicolor' *is* an icon theme.

By simply moving files and replacing them with links will actually slow things down since each link has to be resolved in the kernel.

Many efforts have been made over the years to 'simplify' the 'nix directory structure, but all of them have failed to become even nearly universal. The current move by most major distros to move the contents of /lib, /bin and /sbin into /usr/lib, /usr/bin and /usr/sbin is the exception. This move is being driven by the developemnt/uptake of 'systemd' as a replacement of 'init' and other 'early-boot' utilities which have always been under /lib, /bin and /sbin. The 'problem' with the traditional way arises in later versions of these tools which are compiled and linked against libraries which are installed under /usr/*. The traditional way assumed that a system could be begin booting without /usr being available. The developers of systemd are forcing distros to leave this assumption -and many other good ones... The load for the work gets shifted to all other devs -instead of simply fixing their own stuff!

Anyway, files and directory structures are simply high-level abstractions -no one is really seeing things as they are actually located on-disk. So, it really is easy to alter the abstract view of the structure for those users who think it should be different. The problem with all the re-naming schemes has been that the proposed new structures are just as complicated as the traditional way and require the continued patching of hundreds of program/library sources. And as I staed above, the schemes which use symlinks definetly make it all at least doubly confusing.

I say, why not just re-formulate the structure within the common tool used to view the filesystem? Alias the stucture inside the file-manager and use normal, un-patched sources. Every attempt to 'simplify' the underlying 'real' structure actually reduces the flexibility of the system.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#8 Post by sunburnt »

amigo; I agree that the "view" is all that really needs user beautification.
There`s little need to change the base Linux O.S., it gets you nothing.
technosaurus and I just felt a "screw with the O.S." urge to experiment.

And yes, it seems that newer directions in Linux dev. just "move things".
How about making it boot to other media types? Squash files, URLs, etc.

I still think that separating apps. from each other and the O.S. is good.
It does solve long standing problems in legacy and union type setups.
And makes install / uninstall much easier without the files intermixing.

If fact app. modules render a union moot, SFS files can work non-union.
A union satisfies the legacy all-in-one file layout blending Squash files.
The Squash file part is a good thing, but the union is just legacy dogma.

Knoppix kinda started the whole union thing a decade or so ago.
Dev. should have been app. modules instead. Effort and time wasted.

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#9 Post by vovchik »

Dear Terry,

You are on to something - but changing the *nix file structure is a monumental task. I am looking forward to your thoughts and proposals.....

Your good old friend,
vovchik

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#10 Post by technosaurus »

I have a ~1mb tarball that will boot you to Xvesa+jwm+rxvt+busybox ... enough to build a distro from. I have all the necessary symlinks in place so that no matter where a program looks for libs/resources it will find them in the first location it looks (if they exist). This is fine, but to be proper, new builds would need to set --bindir=/bin --sbindir=/bin --libdir=/lib --sysconfdir=/etc ...
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
darkcity
Posts: 2534
Joined: Sun 23 May 2010, 19:16
Location: near here
Contact:

#11 Post by darkcity »

I think there may be standards for Gnome, Kde and other desktop environments. Puppy seems to go more with Gnome paths than Kde.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#12 Post by sunburnt »

darkcity; There goes Flash`s "So many Linux standards" again. :lol:


technosaurus; Sounds very interesting, I`d like to see it...
My thoughts are boot to X, xOrg, GTK, etc.. But gotta start somewhere.

Boot image file not cpio, so ramdisk not initramfs = less overhead.
Ramdisk becomes / , and has fixed small content so no size change.

# P.S. Your thoughts on a 100% inheritance tax over $1 million per heir?


vovchik; My intent isn`t to change the base O.S. file layout.
Apps. are modules (AppPkg) separate from the O.S. file system.
Modules don`t install so the files don`t intermix with the base O.S.

Post Reply