Re: Packaging WM themes - question
On Fri, May 25, 2001 at 08:37:14PM +0200, Marcelo E. Magallon wrote:
> The tricky part is getting the kids to understand that they have to
> download the backgrounds to the special directory, which shouldn't be
> hard as they already have to understand they have to put the
> backgrounds in some particular place.
The really tricky part is selling them on the idea that it is good to
share rather than hoard. The eldest sibs (both girls with similar
interests) won't have much of a problem with each other, I'm sure. The
youngest avid downloader likes to copy everything his older sibs do, much
to their irritation, leading me finally to chmod 700 each of their home
dirs to end the squabbling. (So much for idealism regarding information
sharing, huh?)
I'm contemplating merely symlinking every child's ~/GNUstep/Library ->
/usr/local/share/kids/GNUstep/Library but that too has problems (not the
least of which is "but where do I put *my* private stuff!", a legitimate
concern because they like designing their own backgrounds and icons
themselves. Plus the aforementioned "Daaad, he's copying me! Make him
stop!" issue).
> Same for themes.
>
> I'd be pleased to change stuff or provide hooks as needed.
I may take you up on that. Not only is there the need for a "group" vs.
private area, but also the current directory structure is just way too
unmanageable. In my eldest daughter's ~/GNUstep/Library/WindowMaker/Backgrounds
and subdirs off that (Scaled and ScaledAspect, mostly) she has 38M of
material, comprising over 350 background images. A single sub-menu may
contain nearly 200 images. Imagine, if you will, how long *that* takes to
go thru on a Mach32 ISA gfx card on a 486dx/66, just to display the durned
thing, let alone being able to actually see the image you're looking for
in a list as long as that.
So, we clearly have some data management issues here beyond merely
packaging of themes/backgrounds. They are as follows:
1. users should be able to download their own backgrounds/themes/icons without
assistance from a sys admin
- for a child, backgrounds/icons isn't a problem. themes may be,
however, without a tool to do the installation into the right place
- the only problem here is duplication of effort
2. users should be able to make use of & contribute to a shared repository
of backgrounds/themes/icons without assistance from a sys admin
- preventing overwrites of other users' contributions is one
possible side-issue
3. an ability to organize into arbitrary submenus is necessary to help
users manage their mountain of data
Behind the scenes, perhaps the menu structure should be imposed merely
by symlinking into the various sources of actual images/themes/icons. To
the user, this may appear as a tidy arrangement of folders, a la mozilla
"bookmark editor". I don't know what tool(s) (if any) wmaker may have for
this. However, a highly wm-specific solution may not be desired here in
any event (personally I use wmaker and the kids do too, but I don't
believe the whole world should :) Perhaps Debian "menu" made "personal".
Allow the users to "play sys admin" and organize their menus (not just
themes) in a wm-independent way, taking advantage of some sharing at the
group-level ... Hmm ... am I treading over into Gnome/KDE territory with
this line of thought? Because I really did want to keep this wm- (and
desktop-) independent.
Random other thoughts scattering off in tangents from these,
Ben
p.s. In a valiant effort to keep this on the original topic ...
don't all "data packets" potentially have these same problems:
user-installability, sharing within a group, organization of
large quantities of it so it's easy to access? It's not a "sys
admin" thing as I see it. So why should it be considered as part
of dpkg's job to manage it? That's sloppy thinking by sys admins
who are the sole users of their own systems and are confusing their
"user hat" with their "sys admin hat".
--
nSLUG http://www.nslug.ns.ca synrg@sanctuary.nslug.ns.ca
Debian http://www.debian.org synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
Reply to: