User Skins

[GoogleCodeExporter]

OK, I brought this idea up before as part of another topic, but having
thought about it for a few days I think it deserves its own issue/attempted
implementation.

Design goal: separate content from presentation; permit a user to have a
skin (say, LCARS) in their inventory and use it with the jobs system, even
if that game has chosen not to "install" the skin as part of the main system.

Assumptions:
User skin will not have wizard powers or be able to access jobs system
objects.  All text/information must be passed as parameters to the various
skin "pieces".  User skin will have ability to access a user's own
attributes (e.g., width() will work).  User code does not need to be
cross-platform, although contributed "user skins" on the site should
attempt to be.

Implementation can be via parentage.  DEFAULT will be the master object and
set PARENT_OK (MUX) or LINK_OK (Penn).  Other skins can be parented if
users wish to modify them (perhaps parent to the game's LCARS but change
user colors).  The game's skins should be set VISUAL.

All components will need to be rewritten to behave in a similar manner to
the way *_HEADER and *_FOOTER do:  they are passed all the text they need
(lookups from job objects, etc., are already done) and simply display it in
some pretty user specified manner.  For components such as the BANNER, a
standardized list structure should be passed so that parts chosen for
display can be pulled from a list using a key:value type of lookup, e.g.
stored as |opened_by #123|opened_on 12345| and retrieved with
rest(grab(%0,key *,|)) (a nice inheritable function, maybe).

And a +skins or +jobs/skins command which lists available skins.

Original issue reported on code.google.com by widdis@gmail.com on 28 Jan 2010 at 9:56

• Merged into: #107

[GoogleCodeExporter]

I think the concept behind this is intriguing, but I'm not sure if it can be 
implemented successfully across the board. The main problem is (as noted) 
passing all that datum due to the non-wiz status of the objects. 

Now, we could probably support a limited form of this (headers, breaks, footers)
without the need for inheritedness, but the functions for viewing a job, 
getting 
your list, all of that really needs to be wiz inherit as it makes decisions 
along 
the way. Being passed all that info would be pretty problematic (we couldn't 
read 
the job directly at all, we'd have to be fed the datum from every job, every
comment and every other associated flag/attribute/field). That's a lot of
information getting passed through. It might could be done without breach of
privacy or privileged information, but I don't know. 

There's also the case where non-coders want to 'fix' the way something appears
to them, and they end up screwing up their skin, and a code wiz has to fix it
(or worse) they come to us expecting us to fix it. 

I'd like a better idea of how we would accomplish this before I say 'let's go 
for
it', but as noted, the idea is intriguing.
we would go

Original comment by Fleety...@gmail.com on 3 Feb 2010 at 8:17

[GoogleCodeExporter]

we would go? Where the hell did that come from?

Original comment by Fleety...@gmail.com on 3 Feb 2010 at 8:19

[GoogleCodeExporter]

Agreed that passing all the data gets ugly fast.  It's why I'm holding off on 
doing
anything until post-6.0.

We might consider a +jobs/skins command, though, that lists valid skins.... 
right now
they're only documented in help.

Original comment by widdis@gmail.com on 3 Feb 2010 at 8:32

[GoogleCodeExporter]

We definitely need to include something in 6.1 to standardize what we're doing 
with
the user selectable colors.  I wrote the patch for default, but that format is
different than the selectable colors for LCARS. 

I still like the parentage idea, and think headers, footers, and colors could be
separated from content in the same manner as css style sheets.

Original comment by widdis@gmail.com on 5 Mar 2010 at 11:54

• Added labels: Type-Enhancement, Priority-Low, Milestone-Release6.1, Usability

[GoogleCodeExporter]

Original comment by widdis@gmail.com on 13 May 2010 at 2:54

• Changed state: Duplicate