Your pgn viewer looks great, and I will certainly try it out when it is finished.

The nice thing about SCID is that it has a zillion and one features, can be used as a chess database (SCID stands for Shaun's Chess Internet Database, or something like that), can be used to play on FICS, is in active development (has a mailing list with comments every day) etc. The people writing it are Debian folk, I think. (Shaun disappeared a few years ago, but was tracked down and gave permission for the newer people to takeover the project, which they have been doing for a couple of years now.) And it is set up to work with chess computing engines too. Maybe you all would rather work from scratch instead of using more than a decade of development experience, though.

But something like a simple PGN viewer would make me personally pretty happy! Some of my favorite chess software is incredibly simple and has very few features.

Xboard, mentioned above, is one of the oldest fast chess interfaces out there. I think that it can't display more than one game at a time, though, which is one of the things I was hoping for beyond a pgn reader.

I have no experience with the python chess games mentioned in the thread; apparently they are not widely popular in the FICS/ICC world.

I suppose everyone in this thread knows about stuff like Timeseal and the necessity to correct for net lag? Just thought I'd mention it to make sure.

Well, I might not be able to think of everything at once. It would be great to have a lot of games loaded and be able to flip from one to another instantly. It would be nice to have some sort of screen showing the names of the opponents and if you clicked on Kasparov-Topolov you would see the current state of the game and could easily display the game score, and you could do that with a large number of the participants in the tournament.

Players might be watching the Chess Olympiads, with literally hundreds of players.

Something that is not done now that would be innovative would be to be able to display information from several chess sites at once, so you could see lots of commentary from all over. That might require too big a screen, however.

Webcams are common these days, and if they are available you would want to have that video somewhere.

What people like to do with chess databases is see the history of the opening, so you know that this variant of the Ruy was played a bunch of times in 1997 but not much since then, and that move 13 is a theoretical novelty. People like to see computer analysis as well.

If you are playing on FICS, you of course want to see the window showing graphically who is challenging under what time.

So, there's a lot you could wish for in a viewer.

I hear that ICC has "cheat detectors," increasingly important as players learn to integrate computers into their online play. My impression is that ICC has one technique that detects impossibly rapid moves.

I'm not exactly sure how that works, because I am a firm believer in the 'premove' feature, which means you can indicate beforehand the move you will make as soon as your opponent moves, and your interface makes the move instantly after the opponent moves. To me, this is essential in fast games.

These are some random ideas, of varying quality and in no order.

Thanks geneven for priceless feedback.

I suggested Knights only to see if we can save Qt code work. That is for andybehr to decide since I'm useless at that level.

And for sure we shouldn't reinvent what Scid and others have been providing for years. It was good news to know that there are active maintainers again! They even came up with a Pocket version: http://scid.sourceforge.net/scidpocket.html

Scid lacks finger UI and apparently also chat, so there is a possibility for nice combination. I have linked to the dependences at http://wiki.maemo.org/Miniature#Technology_selections , also for Crafty. I have no clue about how well separated they have engine and UI layers but hopefully someone will be able to see and decide.

I have also started to list priorities in the roadmap: http://wiki.maemo.org/Miniature#Features_and_roadmap

andybehr, where do you think we should aim for a first shot?

I have removed the link to the mailing list at http://wiki.maemo.org/Miniature#Project_status since there are no posts and at least yesterday I was the only one subscribed.

Let's add the link to the list when it's active. I guess at some point we will use that list for pure development discussion, using Talk for announcements and discussion of new features & user feedback.

The first thing we should do is get up a basic QT project... I am still wrestling with the SDK,

Phase 1

• Setup development environment
• Implementing the Board. The Board represents the current state of the game and is equivalent to a real physical chess board. It has no knowledge of legal or illegal moves. For now it will only accept chess pieces. The board does not know about the future or the past, any logic will be in the Game.
• Creating a basic GUI to display the Board and the pieces. A piece can be moved by tapping on it and then tapping on the destination.

Phase 2

• Implement a basic chess Game adapter. The basic Game adapter knows the starting position of every piece and can determine if a move was legal. The concept of alternating player moves is also implemented here. It also recognizes checkmate, stalemate and threefold repetition thus ending the game.

It hasn't been mentioned in this thread explicitly, but there are hundreds of chess engines available.

Usually these are distributed as binaries and the vast majority of those binaries have been compiled for Windows.

But there are still many engines whose source code is available, which can be compiled for Linux and used with Winboard- and/or UCI-compatible interfaces.

I hope that Miniature will be written in such a way that it's as easy to switch engines as it is on a desktop PC. And, for a very different experience than described by Quim initially, I hope it will take the extra step to allow two computer engines to play each other, thus enabling computer chess tournaments.

Also, unlike some of those who have posted earlier, I like to change the fonts used for the chess pieces and to alter the colors on the board with some regularity. It's fine by me if the first version has one set of colors and one design of chess pieces. But please don't omit the logic to be able to change these as the program is developed further.

After all, what's the satisfaction in refereeing a computer-chess tournament if every board looks the same?

Thanks,

Roger S

PS: Yes the Winboard link above is really to an improved-Winboard and not the original-Winboard information site. But the improvements described there ought to be considered for the Miniature requirements list I think.

Good plan, Andy.

Does it make sense for you to start targeting the Portrait mode? Do you agree on the specialization of modes portrait/landscape proposed some posts above?

Just in case it helps:

- Preview of Qt for Maemo Developers Guide
- The Qt 4.6 packages are about to land in extras-devel
- Official Qt 4.6 port for Maemo 5, including mailing list for developer feedback.

There is more Qt related documentation at http://forum.nokia.com/maemo but I don't know how relevant it is for your work e.g. QSolitaire Game Example and Noughts and Crosses Game Example.

RogerS, I have added your feedback to http://wiki.maemo.org/Miniature#Roadmap

- Customization
- Download and select different boards and pieces.
- Download and select different engines.

Do you really need this on a mobile device? I hope nobody has strong requirements on system responsiveness and power management with a CPU busy with 2 chess engines fighting each other...

I have started playing with the portrait mode: http://wiki.maemo.org/Image:Miniatur...e-portrait.png

- Keeping the status area because it's overall useful and doesn't each that much space.

- No borders in the board. You loose the coordinates and some beauty but this is how you get the maximum surface possible for the squares = better usability.

- The position of the board is very usable (I have tried viewing the image in full screen in the N900). Your thumb reaches all the squares.

- The area above the board: I still believe that seeing the players ratings next to the names is important. Bigger timers can't hurt. Should we put there the basic info of the game? "15 0 Rated Standard"

- What to put in the area below the board? We can't assume an engine in the first phases of development and all the info should come from FICS. Of course in the lack of better ideas we have the notation of the game.

And some operational details producing mockups:

- Please let's create 800 x 480 images of the pure screen. This way they can be checked easily in the real environment (in the N900 via Image Viewer) and it's easier to manipulate them to cut/paste elements from other mockups. There will be time for the marketing adding the N900 around.

- png better than jpeg to keep all the "real" flat colors of the screen.

I think portrait or landscape will not be that much different in the first iteration. I think the GUI that renders the actual board should not care about that. So yes we can start with portrait.
But I am not sure if the app should behave differently just because you turn the device. The mode of the app should not change because of orientation.

I agree, I like the coordinates, but I don't like they space the take up. Maybe we could superimpose them over the board on demand?


Yes, I forgotten to add that.

We can display the status messages the FICS server sends. In the beginning that might helpful for debuging.

I don't have my N900 yet. I just wanted to pretend a little. But yes, I agree, the screenshoots get to big with the N900 around it. I just looks cool...

I will not be able to work on this again before the weekend. But I don't have to be alone in programming. I think one or two more programmers would be a good idea. So anyone want to help?

Typing in portrait mode on the N900 is going to be a pain no matter how. In practice players willing to type (chat) are going to stay in landscape.

Chatting is less frequent in blitz / lightning chess for obvious reasons. There is where you need more real estate in the board to have less risk os mistakes in moves. Also you want to save as many unnecessary processes as possible to save CPU and bandwidth, improving the responsiveness of the system when every tenth of a second count.

So yes, I believe it makes sense to have specialized functions for portrait and landscape. I'm not sure at all about changing orintation during a game, but at least the difference should be clear before starting.

I wil keep promoting the project in order to find more developers. Most of the developers I know come from the GNOME side, though...