Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 27 Aug 2014, 11:25
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Is "/usr/local/lib/X11/pixmaps" std. in most Linuxes?
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [12 Posts]  
Author Message
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Sat 15 Sep 2012, 16:44    Post subject:  Is "/usr/local/lib/X11/pixmaps" std. in most Linuxes?  

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.
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2236

PostPosted: Sun 16 Sep 2012, 05:02    Post subject:  

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?
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Sun 16 Sep 2012, 10:21    Post subject:  

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?
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2236

PostPosted: Sun 16 Sep 2012, 12:44    Post subject:  

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).
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4340

PostPosted: Sun 16 Sep 2012, 21:12    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Mon 17 Sep 2012, 02:39    Post subject:  

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)
Back to top
View user's profile Send private message 
amigo

Joined: 02 Apr 2007
Posts: 2236

PostPosted: Mon 17 Sep 2012, 03:58    Post subject:  

'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.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Mon 17 Sep 2012, 14:14    Post subject:  

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.
Back to top
View user's profile Send private message 
vovchik


Joined: 23 Oct 2006
Posts: 1285
Location: Ukraine

PostPosted: Wed 19 Sep 2012, 06:22    Post subject:  

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
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4340

PostPosted: Wed 19 Sep 2012, 14:05    Post subject:  

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 ...
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
darkcity


Joined: 23 May 2010
Posts: 2439
Location: near here

PostPosted: Thu 20 Sep 2012, 11:05    Post subject:  

I think there may be standards for Gnome, Kde and other desktop environments. Puppy seems to go more with Gnome paths than Kde.
_________________
helping Wiki for help | IF SendSpace link = "dead" THEN PM me ("up file to http://meownplanet.net/")
Back to top
View user's profile Send private message Visit poster's website 
sunburnt


Joined: 08 Jun 2005
Posts: 5016
Location: Arizona, U.S.A.

PostPosted: Thu 20 Sep 2012, 20:37    Post subject:  

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


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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [12 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0806s ][ Queries: 12 (0.0041s) ][ GZIP on ]