Ina wrote:
Hi Mark,
Please excuse me writing to you directly, but my last message on
kde-devel seems to have been caught in some spaminator somewhere.
You wrote:
Where is the stalled svg file for Kmines? *I may be interested in doing
the artwork for that, but I'd like to poke around it a bit before I commit.
Mauricio Piacentini is the current maintainer for KMines. *He is also
an artist and so is his wife. *So the draft file is probably with him. *You
can contact him either via the KDE Games list kde-games-devel (AT) kde (DOT) org
or personally at mauricio (AT) tabuleiro (DOT) com. *Either way, I am sure he
would be very glad to hear from you.
All the best, Ian W. (maintainer of KGoldrunner)
Think I'll try the list first, since it archived (?) for posterity
Mauricio, do you have the stalled SVG file for KMines?
Thanks,
Mark A. Taff
kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

I've been doing some hacking on KMines SVG.

In the KDE3 Kmines:
1) the smily faces are 29px sq *.xpm files;
2) the mine, flag, and number of adjacent mines are pixmaps drawn in code
from QPainter; *
3) the playing area is a KGrid2D object, not pixmaps;

Given this, I am unsure of how to procede with making the svg images, because
I don't know what images an SVG based KMines would need. Making the smiley
faces is a no brainer, but will KDE4 KMines abandon KGrid2D, and thus need
images for the grid? Do we need svg images for the numbers, or should this
be kept as QPainter objects?

My C++ is really weak, so I don't have any firm idea of how KMines would
function in KDE4 as opposed to KDE3.

I would appreciate some direction from one (or more!) of you kde-games coders
out there.

I have attached a svgz of work thus far for reference; really just grappling
with what already exists in KDE3.

Thanks,

Mark

*See:

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Thu, 8 Feb 2007 06:41 pm, Mark A. Taff wrote:
I've been doing some hacking on KMines SVG.
<snip
I have attached a svgz of work thus far for reference; really just
grappling with what already exists in KDE3.

Couldn't open the .svgz file properly (broken image), but it looks
as if you are getting somewhere, judging from your notes. It really
is vital that you make contact with Mauricio before going much
further, if you have not already done so. He is both an artist and
a programmer and will already have some ideas I am sure.

You don't want to be working at cross-purposes with him and
it is part of our etiquette that you should always check with the
maintainer or author. That's why we have our maintainers' list.
Integrating graphics with a game needs to be a co-operative
effort between artist and programmer, I believe.

topic - you and Branan Riley have been working in parallel
with me all day. Are either of you in my timezone by any chance?
maybe neither of you ever sleeps ;-)

All the best, Ian W.
Melbourne, Australia

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

i'm a little bit annoyed by kmine, because the 2D widget doesn"t look like
the others game we a doing.
What do you think about something like that (made in few minutes, just to
see)?
kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Hi,

I like it, but I think in case of KMines it's important to keep
something "classic". Although different themes may be overhead.

Cheers,
Dirk

Am Donnerstag 08 Februar 2007 15:37 schrieb Johann Lapeyre:
i'm a little bit annoyed by kmine, because the 2D widget doesn"t look like
the others game we a doing.

What do you think about something like that (made in few minutes, just to
see)?

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Hi, guys. Due to peer pressure :), I have just committed the initial
implementation of SVG theme loading in KMines.

Dirk wrote:
I like it, but I think in case of KMines it's important to keep
something "classic". Although different themes may be overhead.

I agree with Dirk here. The initial theme I checked in is just the SVG
version of the current KDE3 implementation, see a ref (PNG) showing
current elements (including those drawn by code) and the SVG elements
that will replace them at

the main components are currently customizable. I am still
undecided about text and fonts, as the current code uses the system
default, which appears to be the right thing to do. The status/score
widgets are not customizable right now.

The SVG is available in KDE SVN if people want to start playing with it.
Some more elements will be required (outer field frame, background,
score areas) and I will add them when the code is ready for it.

Johann wrote:
>What do you think about something like that (made in few minutes, just to
>see)?
>>
>

It looks nice, specially the smiley. However, I believe the clickable
areas need to have some depth, in order to differentiate between clicked
(cleared) and non-explored areas.
Also, the smiley is currently a button that also restarts the game. This
needs to be considered, or we can think about changing this behavior.
Regarding the timer, I am all for removing the current KGameLCD
implementations, but this needs to be worked in code before I can
implement it in art.
I am not certain about the background. It looks great on this particular
mockup and proportions, but KMines can have different board sizes and
dimensions, so we would need to find something that works always.

Also, I (or someone) need to implement the code for displaying the
background. And not only for displaying, but specially for configuring
it, loading a theme, etc. Code hacking is also needed in order for the
current status/score widgets and central field frame to be customizable.

I am raising these points because I believe we are getting slightly
ahead of the current state of the game code. Do not read me wrong, I am
all for prototyping, but someone needs to actually implement the design,
make sure nothing breaks ,and emulation of the classic look is possible.
I am planning to do this, but with no pressure. :)

Ian wrote:
>Couldn't open the .svgz file properly (broken image), but it looks
>as if you are getting somewhere, judging from your notes. It really
>is vital that you make contact with Mauricio before going much
>further, if you have not already done so.

I could not view the SVG file posted by Matt. Inkscape does not include
the referenced local PNGs when you save the file, this has bitten me
before as well. That is why I posted a screenshot of the SVG file
previously in this message.

But Matt, you can now get the kmines_classic.svgz file from KDE SVN, and
maybe develop an alternative version for KDE4. As I mentioned before,
some interface elements are not (yet) customizable, but the basic ones
are there, smileys, bombs, cells. Feel free to experiment with it. And
as an added bonus you can simply save over your installed KDE4 copy of
the theme file and preview the results in-game, as the code commited
today is already using it.

Ian wrote:
>You don't want to be working at cross-purposes with him and
>it is part of our etiquette that you should always check with the
>maintainer or author. That's why we have our maintainers' list.
>Integrating graphics with a game needs to be a co-operative
>effort between artist and programmer, I believe.

Don't worry, I was really needing a push in order to commit the partial
stuff I had. But I agree that we need artists, and we need to make sure
the programs can accomodate to the needs of the theme designer. But
currently there are limits to this, as some code is at almost 10 years
old, and not designed for it. Hopefully we will be able to use very
flexible theming in the near future, so something like Johann's proposal
should be possible with only a SVG file and some metadata in a .desktop
file. We are not there yet, though :)

Regards,
Mauricio Piacentini

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Thursday 08 February 2007 10:21:10 Mauricio Piacentini wrote:
Hi, guys. Due to peer pressure :), I have just committed the initial
implementation of SVG theme loading in KMines.

You flatter me by calling me a peer. ;-)

Dirk wrote:
I like it, but I think in case of KMines it's important to keep
something "classic". Although different themes may be overhead.

I agree with Dirk here. The initial theme I checked in is just the SVG
version of the current KDE3 implementation, see a ref (PNG) showing
current elements (including those drawn by code) and the SVG elements
that will replace them at

Cool. I like the "classic" svg implementation you made. I have some ideas
for an "oxygen" version as well that I'll hack on.

the main components are currently customizable. I am still
undecided about text and fonts, as the current code uses the system
default, which appears to be the right thing to do. The status/score
widgets are not customizable right now.

The SVG is available in KDE SVN if people want to start playing with it.
Some more elements will be required (outer field frame, background,
score areas) and I will add them when the code is ready for it.

Johann wrote:
>What do you think about something like that (made in few minutes, just
>to see)?
>>
>

Since we will have an svg version of the classic look of kmines, I think we
have some creative flexibility in making other themes, such as Johann
proposes (and hopefully the code will support that in the near term).

It looks nice, specially the smiley. However, I believe the clickable
areas need to have some depth, in order to differentiate between clicked
(cleared) and non-explored areas.
Also, the smiley is currently a button that also restarts the game. This
needs to be considered, or we can think about changing this behavior.
Regarding the timer, I am all for removing the current KGameLCD
implementations, but this needs to be worked in code before I can
implement it in art.
I am not certain about the background. It looks great on this particular
mockup and proportions, but KMines can have different board sizes and
dimensions, so we would need to find something that works always.

Also, I (or someone) need to implement the code for displaying the
background. And not only for displaying, but specially for configuring
it, loading a theme, etc. Code hacking is also needed in order for the
current status/score widgets and central field frame to be customizable.

I am raising these points because I believe we are getting slightly
ahead of the current state of the game code. Do not read me wrong, I am
all for prototyping, but someone needs to actually implement the design,
make sure nothing breaks ,and emulation of the classic look is possible.
I am planning to do this, but with no pressure. :)

I will keep an eye on the code. There are some things I feel competent
coding.

Ian wrote:
>Couldn't open the .svgz file properly (broken image), but it looks
>as if you are getting somewhere, judging from your notes. It really
>is vital that you make contact with Mauricio before going much
>further, if you have not already done so.
>
I could not view the SVG file posted by Matt. Inkscape does not include
the referenced local PNGs when you save the file, this has bitten me
before as well. That is why I posted a screenshot of the SVG file
previously in this message.

Lesson learned. From now on I'll link to screenshots.

But Matt, you can now get the kmines_classic.svgz file from KDE SVN, and
maybe develop an alternative version for KDE4. As I mentioned before,
some interface elements are not (yet) customizable, but the basic ones
are there, smileys, bombs, cells. Feel free to experiment with it. And
as an added bonus you can simply save over your installed KDE4 copy of
the theme file and preview the results in-game, as the code commited
today is already using it.

Will do.

For the record, I live in Seattle, and am a night owl.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Fri, 9 Feb 2007 07:03 am, Mark A. Taff wrote:
Thursday 08 February 2007 10:21:10 Mauricio Piacentini wrote:
Hi, guys. Due to peer pressure :), I have just committed the initial
implementation of SVG theme loading in KMines.

You flatter me by calling me a peer. ;-)

NW we're cooking with gas! :-) Saying that always makes my
daughter cringe, so I couldn't resist it ;-)

--
Nice stuff, Johann and Mauricio. Never thought KMines could look
so lively. Been playing the Windows version for years.

Since we will have an svg version of the classic look of kmines, I think we
have some creative flexibility in making other themes, such as Johann
proposes (and hopefully the code will support that in the near term).

I think you could even *ask* for code to support graphics ideas.
No guarantees on Mauricio's part, of course. Don't want to subject
him to *too* much peer pressure ;-)

I will keep an eye on the code. There are some things I feel
competent coding.

That would be good. Mauricio is working at flat chat all the time on
so many KDE Games things and he does have a company to run

For the record, I live in Seattle, and am a night owl.

Ah yes, West Coast USA. They are so far behind Australia they
are actually just a few hours ahead yesterday :-)

All the best, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

2/8/07, Mauricio Piacentini <mauricio (AT) tabuleiro (DOT) comwrote:

It looks nice, specially the smiley.

Also, the smiley is currently a button that also restarts the game. This
needs to be considered, or we can think about changing this behavior.

Hello all,

Maybe I'm alone on this, and if I am then we can pretend I never
mentioned it, but can't we get rid of the smiley face? It strikes me
as out of place and very tacky, even when beautifully rendered in
vector graphics.

it's a carry-over from the classic Windows version and most
of us have been seeing it for years, so it no longer strikes us as
being that odd, but really I can't come up with a single logical
reason for it being there. Happy faces have no logical connection to
the act of uncovering hidden mines. Most of the information it
(vaguely) conveys should be readily available elsewhere. There are
also serious usability issues with an unlabeled button that can
restart the game at anytime without even asking for a confirmation.

And does it really need to act so surprised/scared/singing every time
I uncover a cell or mark a mine? I know what I'm doing! I've been
playing minesweeper for years! It'll be okay. :)

Microsoft probably added the smiley face because for a game,
minesweeper isn't very visually appealing. Maybe they thought a
sometimes sunglasses wearing smiley face would really up the fun
factor of the game. But now it just seems dated. Heck, even Microsoft
decided to get rid of it in Vista.
()

Parker

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Thursday 08 February 2007 19:08:35 Parker Coates wrote:
Maybe I'm alone on this, and if I am then we can pretend I never
mentioned it, but can't we get rid of the smiley face? It strikes me
as out of place and very tacky, even when beautifully rendered in
vector graphics.

it's a carry-over from the classic Windows version and most
of us have been seeing it for years, so it no longer strikes us as
being that odd, but really I can't come up with a single logical
reason for it being there.

I think the smiley should remain, so we can maintain the legacy theme. Though
I'm certainly not opposed to giving players the option to replace the smiley.
Then again, now that it will be an svg file, each user could just replace
each smiley with a transparent image, if they wanted to.

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Thursday 08 February 2007 10:21:10 Mauricio Piacentini wrote:
Hi, guys. Due to peer pressure :), I have just committed the initial
implementation of SVG theme loading in KMines.

Dirk wrote:
I like it, but I think in case of KMines it's important to keep
something "classic". Although different themes may be overhead.

I agree with Dirk here. The initial theme I checked in is just the SVG
version of the current KDE3 implementation, see a ref (PNG) showing
current elements (including those drawn by code) and the SVG elements
that will replace them at

I have uploaded a screenie of a work in progress oxygen theme for KMines, just
to keep you guys abreast of where I'm at. Everything in the screenie is in
svg, save for the ocean background.

370KiB

I realize the code is nowhere close to using this yet (or maybe ever), but you
get an idea of what KMines could be like. The tiles I use have transparent
middles to facilitate various backgrounds. I also did a quick outline of a
landmine in addition to the usual sea mine.

I am planning on adding tiles for borders as well.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Mark A. Taff wrote:
I have uploaded a screenie of a work in progress oxygen theme for KMines, just
to keep you guys abreast of where I'm at. Everything in the screenie is in
svg, save for the ocean background.

370KiB

I like it, Mark. It is nice that you have re-used the existing flag in
the theme, for example.

I realize the code is nowhere close to using this yet (or maybe ever), but you
get an idea of what KMines could be like. The tiles I use have transparent
middles to facilitate various backgrounds. I also did a quick outline of a
landmine in addition to the usual sea mine.

The only restriction I have with this general approach of having
backgrounds is the lack of clear visualization of board state, something
that affects classic KMines as well to a certain degree, but for a
different reason. To understand what I am talking about, see

characteristic of this type of game is that time is important. That
is the reason for the different colors in the numbers, so players can
quickly recognize patterns and solve the board as quickly as possible.
But more important than this imo is the ability to quickly recognize the
areas of the board that have been cleared, and the ones left to explore.

If you look at the screenshot above, you will see that even the classic
Windows version is a bit better than KMines KDE3 in this particular
aspect, as it is easier to identify which portions of the board have
been explored. The Vista version is also good (in this aspect.) If you
look at KMines SVN, a simple darkening of the depressed cell graphic
(already in SVN) makes reading the board state much easier. I am not
sure what is happening with Gnome Mines, but at least the version I have
does not fare very well on this aspect. The SVG graphics are very nice,
but look at the screen capture: there is no difference between the cells
that have been clicked and cleared, and the ones that were not yet
explored. This makes the game very difficult to play, at least for me.
Maybe it was done like this on purpose, as I agree it requires more
attention from the player. But I personally prefer to visualize the
board state more clearly, and this is even more important with larger
board sizes.

But I am not against having a background in KMines, I believe it would
be nice to have one designed to fill the outside of the playing field
area, like it is done in the Vista version. maybe a very dim one that
just shows partially in the cleared cells. It all depends on the
implementation, really.

Regards,
Mauricio

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Parker Coates wrote:
Maybe I'm alone on this, and if I am then we can pretend I never
mentioned it, but can't we get rid of the smiley face? It strikes me
as out of place and very tacky, even when beautifully rendered in
vector graphics.

I must say I thought about this as well. Glad you raised this topic for
discussion.

it's a carry-over from the classic Windows version and most
of us have been seeing it for years, so it no longer strikes us as
being that odd, but really I can't come up with a single logical
reason for it being there. Happy faces have no logical connection to
the act of uncovering hidden mines. Most of the information it
(vaguely) conveys should be readily available elsewhere. There are
also serious usability issues with an unlabeled button that can
restart the game at anytime without even asking for a confirmation.

Well, maybe the smiley should not be mandatory, but there could be hooks
in the theme so it could be implemented, mostly for the classic theme
and variations of it, if the theme author really likes the idea?
The main issue for me is really the usability problem with the smiley
being a button. I would like to solve this in a consistent way AND still
keep the classic behavior. Maybe this smiley-behaves-as-a-button
behavior could be a theme option as well. In this case the button
graphic could be supplied by the theme author and the engine would be
coded to assemble this button and connect it if present.

And does it really need to act so surprised/scared/singing every time
I uncover a cell or mark a mine? I know what I'm doing! I've been
playing minesweeper for years! It'll be okay. :)

LL. I usually click fast, so there is not really time to see the face
change, it just looks like a flicker in the button most of the time.

Regards,
Mauricio Piacentini

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

2007/2/8, Mauricio Piacentini <mauricio (AT) tabuleiro (DOT) com>:

It looks nice, specially the smiley. However, I believe the clickable
areas need to have some depth, in order to differentiate between clicked
(cleared) and non-explored areas.

It was just a "quick & dirty" mockup. I fact, i'm agree with you, clicked
and not clicked area must be show, with both depth and color, like vista. It
wasn't on the mockup.

I am not certain about the background. It looks great on this particular
mockup and proportions, but KMines can have different board sizes and
dimensions, so we would need to find something that works always.

I don't think this is really an issue. but in my mockup, the wasted space
was too big, i'm agree.

Also, I (or someone) need to implement the code for displaying the
background. And not only for displaying, but specially for configuring
it, loading a theme, etc.

Why? other games have a background too (katomic, knetwalk, ). And the
background is just in the SVG itself.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Johann Lapeyre wrote:
Why? other games have a background too (katomic, knetwalk). And the
background is just in the SVG itself.

In KMahjongg users can configure backgrounds and tilesets separately,
and the same is (or was?) possible in other apps for the KDE3 series,
like Kpat.

But you have a point, it might be better to consider the background an
integrated part of the theme, at least for some applications. So the
question turns into theme selection and switching, which is easier to
plan. For KMines I will add additional elements, then:
-Background
-Playfield delimiters - frame (corners, top, left, right, bottom)
-Score and Timer areas
-Smiley button states

The metadata theme file (.desktop) would contain localizable data and
metrics for the elements, much like the current ones used for KMahjongg
tilesets,

Theme authors will then be more or less free to implement these elements
with transparency or not, or simply not include some elements if they do
not fit their overall goal. With something like this I guess you would
be able to implement a design based on the mockup you posted, right?

Regards,
Mauricio

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Friday 09 February 2007 09:15:47 Mauricio Piacentini wrote:
But you have a point, it might be better to consider the background an
integrated part of the theme, at least for some applications. So the
question turns into theme selection and switching, which is easier to
plan. For KMines I will add additional elements, then:

-Background
-Playfield delimiters - frame (corners, top, left, right, bottom)
-Score and Timer areas
-Smiley button states

I will add these to my theme, likely today/tonight. Also, non-gamespace tiles
to permit KMines to have rectilinear shapes other than a square or rectangle,
like a cross (as per the KMines TD).

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Friday 09 February 2007 04:48:32 Mauricio Piacentini wrote:
I like it, Mark. It is nice that you have re-used the existing flag in
the theme, for example.

Thanks. I think it looks sharp. Deriving from existing oxygen icons saved a
bunch of work as well, all I had to do in some case was re-implement the
icons so that it is easier to change the colors at runtime. For example,
replacing a colored linear gradient shape with two identical shapes, one with
a solid base color fill, the other with a grey to transparent fill gradient.

The only restriction I have with this general approach of having
backgrounds is the lack of clear visualization of board state, something
that affects classic KMines as well to a certain degree, but for a
different reason. To understand what I am talking about, see

characteristic of this type of game is that time is important. That
is the reason for the different colors in the numbers, so players can
quickly recognize patterns and solve the board as quickly as possible.
But more important than this imo is the ability to quickly recognize the
areas of the board that have been cleared, and the ones left to explore.

I see what you mean. I will work up two different options so we can visualize
the potential for each. The first is the use of opacity and gradients on the
tiles to more clearly show the difference between cleared and uncleared
space.

The second would be to use discinct colors for uncleared vs cleared, ala
vista.

I am also considering a thin (1px) black border to help illustrate the grid
even more.

In an earlier mail you said we should use the default font for the numbers.
Until we get a svg graphical version of i18n(), I agree that we *must* do
that so those who use non-arabic numbers can play the game with their native
symbols.

Perhaps this could be added to the svg library? This seems possible to me.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Thanks. I think it looks sharp. Deriving from existing oxygen icons saved a
bunch of work as well, all I had to do in some case was re-implement the
icons so that it is easier to change the colors at runtime. For example,
replacing a colored linear gradient shape with two identical shapes, one with
a solid base color fill, the other with a grey to transparent fill gradient.

This is something I am still unsure of how to handle in code. While it
is definately possible to style a SVG using an external .css file and
QSVGRenderer, I did not get an answer yet (on IRC) on how to do this
programatically, without the external style file. course, the program
could parse and re-write the .css included with the theme, but this has
several issues, like lack of privileges, etc. Does anyone here know how
if it is possible to style the CSS from code without too much hacking?
Maybe we will have to load the SVG as XML, add elements to it, and feed
the result to KSVGRenderer. It looks cumbersome. Suggestions?

A complementary question: do we really want to expose this level of
customization in the configuration options? Does anyone actually
configure the color types for each numeral in the current KMines?
simply having the option to switch themes is enough, as we can include
one for accessibility, another with a classic look, etc. ?

In an earlier mail you said we should use the default font for the numbers.
Until we get a svg graphical version of i18n(), I agree that we *must* do
that so those who use non-arabic numbers can play the game with their native
symbols.

Yes, that is my initial feeling. But on the other hand, the default font
sometimes looks ugly, and it is a bit more difficult to get perfect
alignment for all face types, depending on the metrics. So it is
something we need to consider as well. Ultimately I am not against
including number shapes in the theme, as this can lead to very
interesting themes imo. Think about a medieval theme, or a Japanese one,
where the numerals would match the current style. The oxygen theme could
have its typical shading in the numbers as well. Having always the same
system font for all of the themes start to look non-optimal if you
consider these scenarios. hum

Lots of options to choose from, it is nice to have this conversation so
we can consider all of them.

Regards,
Mauricio

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Friday 09 February 2007 11:36:22 Mauricio Piacentini wrote:
This is something I am still unsure of how to handle in code. While it
is definately possible to style a SVG using an external .css file and
QSVGRenderer, I did not get an answer yet (on IRC) on how to do this
programatically, without the external style file. course, the program
could parse and re-write the .css included with the theme, but this has
several issues, like lack of privileges, etc. Does anyone here know how
if it is possible to style the CSS from code without too much hacking?
Maybe we will have to load the SVG as XML, add elements to it, and feed
the result to KSVGRenderer. It looks cumbersome. Suggestions?

In the case of KMines, transforming the svg in memory using DM and then
feeding it to KSVGRenderer doesn't sound too bad, as it only needs to happen
on game load, or on setting change, as opposed to other games where it might
be required on every redraw.

Perhaps KSVGRenderer needs to be modified to permit developers to modify the
svg tree before it gets rendered? That seens the most elegant solution
(without even having read the code ;-) ) to me. Certainly now is the right
time to make sure we have a KSVGRenderer that we can live with for the next
five years.

For that matter, using KProccess and a sh/perl/python/ruby/sed regex to change
the flag and number colors wouldn't be that hard either, though I think not
as elegant, and maybe less portable.

A complementary question: do we really want to expose this level of
customization in the configuration options? Does anyone actually
configure the color types for each numeral in the current KMines?
simply having the option to switch themes is enough, as we can include
one for accessibility, another with a classic look, etc. ?

Since it will all be svg (and perhaps some CSS), I'm not sure if there is much
value in exposing that level of configurability in the gui, expescially if we
provide, a "classic", "oxygen", and "hi-contrast" themes. If we give people
good base themes to start hacking from, the kde-look crowd will be able to
innovate new themes that are required/desired. This implies potentially
adding KGetNewStuff to KMines in the future, if themeing KMines becomes
popular.

Yes, that is my initial feeling. But on the other hand, the default font
sometimes looks ugly, and it is a bit more difficult to get perfect
alignment for all face types, depending on the metrics. So it is
something we need to consider as well. Ultimately I am not against
including number shapes in the theme, as this can lead to very
interesting themes imo. Think about a medieval theme, or a Japanese one,
where the numerals would match the current style. The oxygen theme could
have its typical shading in the numbers as well. Having always the same
system font for all of the themes start to look non-optimal if you
consider these scenarios. hum

Again, you make good points. I like the creative freedom and precision that
using svg for the numbers brings. I wonder how we could do that yet still
use the default font as an option to cover those cases where language-glyph
specific theme variations don't exist?

Perhaps each theme could have internal variations, so chinese or cryillic
numbers could be in the same file? So we use #nine or #nine.chinese or
#nine.cryillic? So we try to use the number according to KDE's localization
setting, and if not found we default to arabic?

Lots of options to choose from, it is nice to have this conversation so
we can consider all of them.

It is indeed nice.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Sat, 10 Feb 2007 08:32 am, Mark A. Taff wrote:
Friday 09 February 2007 11:36:22 Mauricio Piacentini wrote:
A complementary question: do we really want to expose this level of
customization in the configuration options? Does anyone actually
configure the color types for each numeral in the current KMines?
simply having the option to switch themes is enough, as we can include
one for accessibility, another with a classic look, etc. ?

Since it will all be svg (and perhaps some CSS), I'm not sure if there is
much value in exposing that level of configurability in the gui,
expescially if we provide, a "classic", "oxygen", and "hi-contrast" themes.
If we give people good base themes to start hacking from, the kde-look
crowd will be able to innovate new themes that are required/desired. This
implies potentially adding KGetNewStuff to KMines in the future, if
themeing KMines becomes popular.

Speaking as a player (end-user) I agree that good themes and good
defaults, including the cleaner looking "classic" theme in KMines, are
significantly more important than having lots of (possibly confusing)
configuration choices. in games where the defaults were bad
have I felt a real need to re-configure, such as if the default gave you
black foreground on dark red and dark blue backgrounds, making the
foreground rather hard to see.

But none of that is going to happen in KDE Games 4, is it? The new
classic theme in KMines makes it easy to read the position and make
moves - and that is what counts. It's a ripper, mate! KMines is not so
easy to use in KDE 3, so I rarely play it there. In Windows I play it a lot,
but then there are not so many other choices of games in Windows ;-)

That said, and putting my programmer's hat back on, SVG/Inkscape does
seem to "hard wire" colours (as hex constants in XML and as embeddings
in drawn objects). Perhaps it would be nice if the format had a section for
colours named by the artist (e.g. FlagColor), as well as named elements.

Some games might be able to benefit by using colour changes to generate
variations on themes, provide an aid to play or execute interesting scene
changes. So, if there could be a simple solution to manipulating colours
in an SVG-based scene, it must be worth searching for

BTW, I found the following gem in Qt's documentation of class QColor::
setNamedColor(): #ColorKeywords
Apparently these are standard SVG names for colours and you can use
them, with a bit of juggling, in Qt4 code, and there is a SVG type called
"color". But I expect you guys knew this. CSS2 is mentioned further up
the same page.

All the best, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Friday 09 February 2007 11:36:22 Mauricio Piacentini wrote:
Yes, that is my initial feeling. But on the other hand, the default font
sometimes looks ugly, and it is a bit more difficult to get perfect
alignment for all face types, depending on the metrics. So it is
something we need to consider as well. Ultimately I am not against
including number shapes in the theme, as this can lead to very
interesting themes imo. Think about a medieval theme, or a Japanese one,
where the numerals would match the current style. The oxygen theme could
have its typical shading in the numbers as well. Having always the same
system font for all of the themes start to look non-optimal if you
consider these scenarios. hum

I have uploaded my KMines work-in-progress svg. See:
171KiB*

I think I pretty much have the tiles licked. I've added numbers as well, and
have begun work on laying out basic shapes for the border.

There are many mini-boards to illustrate the pieces in action.

Still TD:

Finish borders.
Implement Multi-Segment display (probably 11 segment) for score and timer.
Create wallpaper(s) for background of main widget.

Comments?

Regards,

Mark

*no linked graphics, so should work K.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Mark A. Taff wrote:
I think I pretty much have the tiles licked. I've added numbers as well, and
have begun work on laying out basic shapes for the border.

There are many mini-boards to illustrate the pieces in action.

Still TD:

Finish borders.
Implement Multi-Segment display (probably 11 segment) for score and timer.
Create wallpaper(s) for background of main widget.

Comments?

Looking great as far as I am concerned. I am going to comment on a two
points that could be improved/changed imho.

a) Shadows in all elements/numbers/smiley. I see that you used the
shadow for these elements, It is more visible at closer
inspection and larger board sizes. To me, this is not really necessary,
I believe we have discussed this already in IRC (talking about Katomic,
where you can see the same issue in the arrows when you click on an atom
to move it.)
The shadows are perfect for the icon theme. For game elements
they do not look as good or necessary (to me), specially under the
numerals. I believe you could/should keep the shadow in the flag and
mine elements perhaps, but it could probably be removed from the
numerals and the smiley.

b) Mine icon. I am not sure about which one to use, it is nice that you
have included two. But to be honest I like the one in classic better,
with spikes on all sides, even if it does not look like a real one. I
think I prefer the classic one mostly because it kind of matches the
look we are used to on most Mine sweeper games (Vista, Gnome, KDE3)
But this is just my opinion, the spiked one you added looks ok as well,
and we only see the mines when everything is over anyway! What do you
think of this?

I will probably use your .svgz soon in the SVN version, and then we will
start to explore the configuration options and how to best expose these
to the user. But I liked your approach of setting a background tint
value, and we should probably find a way to expose this as an in-game
configuration option.

Regards,
Mauricio Piacentini

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Mark A. Taff wrote:
>Comments?

And btw, I just realized (by re-reading my message) that on these
discussions we always tend to comment on one or two points that we did
not like 100%, the points we feel that could be improved. And while we
do this we usually forget to congratulate you and say thanks for all the
other 98 things that are nailed right.
So thanks!

Regards,
Mauricio Piacentini

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Saturday 10 February 2007 06:07:37 Mauricio Piacentini wrote:
a) Shadows in all elements/numbers/smiley. I see that you used the
shadow for these elements, It is more visible at closer
inspection and larger board sizes. To me, this is not really necessary,
I believe we have discussed this already in IRC (talking about Katomic,
where you can see the same issue in the arrows when you click on an atom
to move it.)
The shadows are perfect for the icon theme. For game elements
they do not look as good or necessary (to me), specially under the
numerals. I believe you could/should keep the shadow in the flag and
mine elements perhaps, but it could probably be removed from the
numerals and the smiley.

I agree that the oxygen style shadows on the numerals at small sizes, like
22x22, are a bit hard to see. I wil work up an alternet set of numerals
without the shadow so we can see how they look. But this brings up another
question.

When KMines was made, screen resolution was small, so we had to use small
tiles to be able to use it at 640x480px. Since we are now using scalable
graphics, I would suggest a default/design sprite size of 32px, which would
then scale down to 22px nicely or up to 128px nicely. This default size
ought to be, imo, a config setting, either with or without a gui. At
1680x1050, 22px tiles are pretty small, and they are only going to get
smaller in relation as screen sizes increase. Plus, a slightly larger
default sprite size lets use show off more of the detail and beauty of the
svg images.

Comments on this?

b) Mine icon. I am not sure about which one to use, it is nice that you
have included two. But to be honest I like the one in classic better,
with spikes on all sides, even if it does not look like a real one. I
think I prefer the classic one mostly because it kind of matches the
look we are used to on most Mine sweeper games (Vista, Gnome, KDE3)
But this is just my opinion, the spiked one you added looks ok as well,
and we only see the mines when everything is over anyway! What do you
think of this?

There will always be people who prefer to spikes (aka contactors) on all sides
mine, so it is important we keep a classic version. For me, I was a soldier
in the 1991 Persian Gulf War, so a landmine is more my speed than if I was in
the Navy. ;-) Note that my landmine is still only a wire-frame, far from
complete.

I see a potential for a beige-tinted tile with the landmine, and perhaps a
blue-tinted tile with a sea mine. So a land version and an ocean version
perhaps.

While I like my sea mine much better than the new classic sea mine, it is
still not quite right. It really needs to be made in blender, perhaps making
a top-contactors only one and a all-over contactors one. My skills aren't
good enough to make the mine totally right in inkscape, and definetly not in
blender. What I like about my mine is:

1) The weld seam around the middle of the sphere;
2) The nomemclature and national stock number written below the weld seam;
3) The highlights and shadows to give it a 3D appearance;
4) The varying lengths/angles of the contactors so that it looks 3D

The top-only contactors vs all-over contactors is really an issue of
perspective, now that I think about it. If you look at my mine from directly
above, you see an image like the classic all-around contactor mine. In
oxygen, all elements are seen from a side view (I think that is one of their
formal guidelines).

Is there an artist here who could make a sea mine in blender and give us a top
perspective and a side perpective to compare? Perhaps even a 45 degree angle
perspective as well? I opened blender once and was so totally overwhelmed I
shut it down in short order. :-(

I will probably use your .svgz soon in the SVN version, and then we will
start to explore the configuration options and how to best expose these
to the user. But I liked your approach of setting a background tint
value, and we should probably find a way to expose this as an in-game
configuration option.

Thanks. I'm flattered. course, all my work is under gpl. I'm not sure of
the official KDE way of noting that in graphics files. I have that in the
document properties, but I leave that to you. ;-)

Please let me know when you commit my version, and I will start using that
version as my master and send you diffs to commit as appropriate.

I will continue working on numbers, borders, multi-segmented display, and
perhaps the mine. I won't get much done today belong to my
fiance. But I'll get some more work done on Sunday.

As for your other email, the critiques on this list thus far have been quite
postive and helpful. I understand the list practise of not responding to
things you agree with, but instead discussing things that actually need to be
discussed. ;-)

I appeciate the reception I have been give, as well as the postive and
constructive critiques.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

The latest version is at
120KiB

I have numbers and smileys without the shadows, a corrected error x, tile
color now *really* set in individual tile instead of tmp hack of a single
background object, and three versions of an initial svg background to the
main widget.

No borders or multi-segment displays yet.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Sun, 11 Feb 2007 01:13 am, Mauricio Piacentini wrote:
And btw, I just realized (by re-reading my message) that on these
discussions we always tend to comment on one or two points that we did
not like 100%, the points we feel that could be improved. And while we
do this we usually forget to congratulate you and say thanks for all the
other 98 things that are nailed right.

Hear, hear! Mauricio! I think I was similarly forgetful regarding
your running figure and I am feeling rather embarrassed about it.

Producing graphics for a running figure must be extremely
difficult, especially since there are not too many precedents
to go on. Plenty of walkers, even dinosaurs walking. And
some sports medicine specialists spend a lifetime studying
running! I don't think I can ever thank you enough, Mauricio,
for all the work you have put into this.

All the best, Ian W.

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

The latest version is at
136KiB

I have the borders made, along with numerous other fixes. I think I am almost
ready to have this committed to SVN. Before that happens, I would like some
feedback on whether to use:

Smileys with or without oxygen shadows;
Numbers with or without oxygen shadows; ( I vote without shadows)
Which border to use? I like the "cubes" border;

After I get some consensus about those points, I can prepare a version for
svn. ;-)

I will work on multi-segment displays in a separate file.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Hi,

2007/2/12, Mark A. Taff <marktaff (AT) comcast (DOT) net>:

The latest version is at
136KiB

Nice looking.

Small comments (i'm at work a my coffee break):
- the cube could be rounded (like the katomic's wall ). This could be later
- the defaut one is nice looking. I've an issue with the other too, the 2
colors doesn't fit well together, and i don't think they follow the oxygen's
color palette.
- I never talked about that, but it could be fine to have (to improve
usabillity and harmony), an common "action" color between games (at least,
as much as possible). I putted already a nice green on katomic's arrow,
knetwalk's turn-left-arrow, and kwin4 will have too. Maybe the square should
be with this green, and surrounded with grey or blue. Could you test that?

Smileys with or without oxygen shadows;

if is it an action bouton, with shaddow (defined for kde)

Numbers with or without oxygen shadows; ( I vote without shadows)

i vote without

I will work on multi-segment displays in a separate file.

I'm not sure about multi-segment, it 's looking "dated" / "old fashion"

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Monday 12 February 2007 10:42:35 Nicolas Roffet wrote:
(Something similar: Do someone ever played Tetris on Game Boy with 2 human
players (on 2 different Game Boy) with the linking cable? There was
something like this. At the end of the game, you had a jumping happy Mario
or a sad crying Luigi, depending of the game issue It was a nice player
experience)

I can see Konqi doing doing a little happy dance. ;-) Not that I am able to
produce such an animation, but it would be cool.

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org

Monday 12 February 2007 01:19:44 Johann Lapeyre wrote:
Nice looking.

Thanks.

Small comments (i'm at work a my coffee break):
- the cube could be rounded (like the katomic's wall ). This could be later

I thought about that as well, but decided to keep it square, for purely
personal asthetic reasons. If the corners were slightly rounded in the
future, I don't think it would be any big deal.
- the defaut one is nice looking. I've an issue with the other too, the 2
colors doesn't fit well together, and i don't think they follow the
oxygen's color palette.

I changed the text "default" to "traditional", which was more what I meant. I
would rather the blue minefield with the beige or silver background be the
default for this theme, with the others either as variations, or set manually
in a color dialog/css sheet/however it gets implemented.

I oxygen-ified the colors. The only one that isn't in the oxygen palette is
the beige gives short shrift to browns. How do you create a palette
without biege? ;-( I could create the proper beige using only the oxygen
colors, through torturous use of colored gradients and transparency (can you
say "ugly hack"). Also, I like my blue better than the closest oxygen
equivelent.

IM, I think we should use the oxygen colors as much as possible, but should
allow ourselves the license to deviate from them when an oxygen color just
doesn't do the trick. I submit that my use of beige, and maybe the blue, is
one of these cases. ;-)
- I never talked about that, but it could be fine to have (to improve
usabillity and harmony), an common "action" color between games (at least,
as much as possible). I putted already a nice green on katomic's arrow,
knetwalk's turn-left-arrow, and kwin4 will have too. Maybe the square
should be with this green, and surrounded with grey or blue. Could you test
that?

I'm not quite sure what you mean by this. I made green squares for the
minefield works, but it leans to the ugly side of the tracks, imo.

Do you mean a green border in the "cubes" style?

I will work on multi-segment displays in a separate file.
--
I'm not sure about multi-segment, it 's looking "dated" / "old fashion"

They have certainly been around for a long time, though they are still being
used in *new* devices. Every digital watch, timer, digital alarm clock.
Pinball machines. Most VCR/DVD/stereos. Many telephones.

I am also planning to do an LCD monochrome grid display, say 10px x 15px per
character? This is the type of display my brand-new telephone has.

While using these may not be right tfor any particular application, having the
artwork available give the developer the choice.

Regards,

Mark

kde-games-devel mailing list
kde-games-devel (AT) kde (DOT) org