[Kde-games-devel] KPatience, select deck dialog idea and mockup.

[Parker Coates]

On Sat, Apr 25, 2009 at 4:47 PM, Luciano Montanaro wrote:
> On martedì 21 aprile 2009, Parker Coates wrote:
>> Personally, my vote is to remove it. It would simplify a lot of things
>> and also ease the introduction of GHNS. In fact if we added GHNS
>> support at the same time we remove separate backsides, then that might
>> mitigate some of the user outrage. Unfortunately, we're already past
>> the soft feature freeze, so I'm not sure if that can happen for 4.3.
>>
>
> I'd say let's get rid of it for next version; we can put it back in some other
> form if it's really needed.
>
> There is a way the back could be inserted in the right context within the deck
> I have been pondering since my experiment with the huncard deck [1].
>
> That is, we could reference a "pattern" paint server in the deck (which can be
> a color, a repating pattern but also an image) when defining the color of the
> card back.
>
> The back would thus need to be defined as a square image, with the important
> bits in the center, so decks of various shapes would most likely cut out not
> too important details.
>
> The deck would have a "back" element, with a sub-element containing the shape
> of the card, filled with a conventionally named pattern.
>
> it would look something like this:
>
> <g id="back">
> <rect width="116" height="189" x="6" y="6" rx="3"
>      style="fill:url(#back-pattern)"/>
> <use xlink:href="#back-shadow"/>
> </g>
>
> Here the <rect> element draws a rectangle with rounded corners, filled with
> the back pattern.
>
> The <use> element in this case draws a semitransparent overlay that ought to
> give some depth to the card graphics.
>
> The deck author could have some extra elements drawn when drawing the back,
> and some control on how to use the back graphics. For example, an extra
> border could be added.
>
> The drawback is that when loading the deck, the pattern would need to be read
> and inserted in the dom of the deck svg. There is a class in kdegames that
> should help with that, if I remember correctly. And probably the card cache
> would need to be changed to make this work.
>

That seems like a pretty elaborate setup for an in game card deck
selector. The following idea just popped into my head. It might not be
very good, but it would deal with some of our issues.

What if we simplified our card deck classes and UI to handle only
single SVG files with a single embedded "back" element and then create
a new little utility program for create new custom themes? It could
support loading front sides and backsides from existing installed
decks, or from external SVG files and could install the new themes,
save them to some other location, or upload them to a GHNS server.

Your fancy backside patterns could also be included, but when actually
saved to disk, the themes would be entirely static and self contained.
The main advantage would be that it would simplify much of our deck
handling code and UI. All the complex configurability that a small
subset of users desire would be offloaded to an external app.

Anyway, that's a lot of work that I don't have time to do, and it
certainly couldn't be done for 4.3, but I thought it was an
interesting idea. Comments welcome.

Parker