[Kde-games-devel] moved Kajongg from playground to kdereview

[Jeremy Wickersheimer]

For the kwin issue i am just guessing but it could be just an option
on the dialog (modal / non modal).

I was not thinking about space constraint on netbooks, but a dialog
would also be rather big and hide a good part of the board in that
case.
But i dont think the buttons have to be very big, and for example they
might fit over the bottom part of the wall. The timer progress bar
could be a digital countdown to be more compact.
Or if you make the board dimensions square, you would have more
horizontal space than vertical space, so a panel on the right could be
used.

Making the positioning configurable could be an option.

> will introduce an option "propose melds for tiles on hand", default
> True, because that is the better choice for beginners, I think.

Or one may think this would lead the beginners to believe that the
only good matches are with the same tiles.
I think the sorting makes it easy enough, but i am no beginner,
perhaps some user testing can tell :)

For the dependencies, i dont know what the policy is for introducing
them that's all :)

I'll try again next week, if get the error again i'll email it to you.
I'll maybe also try some UI adjusting (easy to do in python).
Then i'll probably have lots of ideas to share with you later, custom
rules etc .. :)

WICKERSHEIMER
Jérémy





On Fri, Feb 19, 2010 at 10:56 PM, Wolfgang Rohdewald
<wolfgang at rohdewald.de> wrote:
> On Friday 19 February 2010, Jeremy Wickersheimer wrote:
>> I think using a dialog for prompting the user actions is not a good
>> idea, kwin with compositing will darken and lock the other windows
>> so it is very hard to see the board (and is very distracting).
>
> I was not aware of that problem since I do not use compositing.
> Do you know how I could prevent darkening of the main window?
>
>> Also dialog placement is sort of unpredictable for the user.
>
> it was meant to save/restore its previous position but it does that
> only while kajongg is running. I will try two things:
>
> - save/restore its position relative to the main window, also
> surviving a program restart
>
> - but not move it when the main window is moved
>
> would that be better?
>
>> I think a big improvement would be to have those buttons on the
>> board next to the player hand (and always visible, just disabled
>> when not in the player turn).
>
> Absolutely. I tried that. Problems are:
>
> - if the main window is small, the dialog can cover a good part of
> it if it is to remain readable. I tried a resizing QGraphicsWidgetItem
> with the dialog but this is almost unreadable on a netbook
> screen. So I think the size of the dialog font should use the KDE
> defaults.
>
> - this will be even more problematic if / when I introduce an option
> to show the tiles without borders and shadows - that should make
> it more playable on a netbook. Borders/shadows do take a lot of room.
>
> - there really is no space anywhere for a constantly displayed dialog.
> The room between the concealed tiles and the wall is used for declared
> melds, and the room to the left is used for the bonus tiles of the
> lefthand player. I already have to do tricky things in placing the
> bonus tiles - if a player declares four kongs, there is no room
> for four bonus tiles - in that case I have to move them to the
> other line.
>
> so when I play, I normally place the dialog above my own wall side
> but only if the screen is large enough - not on the netbook.
>
> xmj (debian package xmahjongg) always places discarded tiles ordered
> and leaves space in the middle of the screen for the dialog such
> that the dialog never covers anything. But then the xmj main window
> cannot be resized...
>
> xmj has 3 options for the dialog placement:
> - as just described
> - as a popup like I do but without remembering the previous position
> - in an extension of the main window at the bottom
>
> so others had the same problem before...
>
>> Also i think it would be great to have simple (single key) keyboard
>> actions (space / P / C / etc .. ) by default for all the game
>> actions, instead of alt+x. This game is very suited for keyboard
>> only game
>
> Agree again. I will do that. Did you notice you can move between
> the choices with up/down arrow (or the j/k keys)? Unusual but
> the right/left arrows are used to select the tile to be discarded
> while the dialog is visible.
>
> BTW a big touch screen is quite nice for Kajongg. I have one since
> a few weeks and I love it. I wonder if it might be feasible to
> have a special mode where such a touch screen
> can be used with Kajongg as a fully automated Mah Jongg table -
> you would need to place something between your tiles and the wall
> such that only you can see your own tiles - without hindering the
> touch screen mechanism. And make the four sides of the main
> board symmetric, and rotate and place the dialog accordingly.
> Should be doable, I think. Even with a keyboard for every player
> if wanted.
>
>> I'd prefer that the tiles in the player hand not be spaced, right
>> now there is some horizontal spacing and grouping. That's just a
>> personal preference, but for example it wont group sequence so it
>> will display [X 33  4  5  X] which i found a little distracting.
>> Also on a real table top game you wont space your tiles so players
>> like me are used to view them like that :)
>
> I will introduce an option "propose melds for tiles on hand", default
> True, because that is the better choice for beginners, I think. Would
> that be OK with you? (btw that will mean I need a new tab in the
> config dialog - this will be the first option that is not part of
> the ruleset). If False, tiles will be ordered like now but without
> spaces between melds. This is what xmj does.
>
>> I had the game crash (actually the server returned an error) when i
>> captured a tile (Pung) so i did not play it a lot though.
>
> That should certainly not happen. Can you mail me the error message?
> Should be somewhere in /var/log. Also kajongg.py --help and
> kajonggserver.py --help show some debugging options.
>
>> I cannot comment on the python dependencies which should be
>> reviewed by the KDE games group (for example you need
>> zope-interface / twisted).
>
> You certainly know that but for others: zope-interface does not
> mean kajongg depends on the entire zope. It implements class
> interfaces in a different way than the usual OO inheritance,
> and twisted uses that extensively (kajongg does not). So if
> twisted is installed, zope-interface is also installed
> automatically. This is a twisted FAQ:
> http://twistedmatrix.com/trac/wiki/FrequentlyAskedQuestions#WhydoesTwisteddependonZope
>
> For the network I considered using ggz / kggz but decided against
> because its development seems to be rather stalled, it would make
> kajongg installation make more complicated (I believe, without
> being a ggz expert), and because I was very unsure whether ggz
> really lets me do all I need like defining gaming rules for a new
> table and letting the player compare the table rules with his
> locally defined rules. I did not want to start development and
> only later notice I would first have to extend ggz.
>
> But if anybody wants to add a ggz interface - you are definitively
> welcome. Ggz has the advantage that it already offers a central
> server which always runs for finding other players. Kajongg now
> needs somebody to act as a server, and it has no chat function -
> yet.
>
> python-twisted should be supported by all distributions - I am not
> so sure about ggz. Last year Josef told me I have to bug my
> distribution if they do not have ggz. And if you look at the
> twisted mailing list, you can see it is very active. twisted
> certainly made it rather easy to write network support (of course
> only after getting used to its unusual philosophy).
>
>> Anyway thanks for your great work, i was meaning to write this game
>> before but did not get the time to commit to it, i am sure it will
>> be an awesome addition to kshisen for mahjong players :)
>
> Thank you for your kind words!
>
> It might take a few days until I can do those changes, my weekend
> is going to be rather busy. I will also add support for calling hands
> especially initial calling in the next two weeks or so.
>
> --
> Wolfgang
>