Thread: [eboard-devel] Eboard Update
Brought to you by:
bergo
From: Sebastian W. <seb...@ss...> - 2005-03-08 23:42:31
|
Hi there! I agree with Paulo Schreiner that it is important to discuss about everything, before we can start coding. First, we should start with agreeing on the goals: Lakin Wecker wrote: > The solution should allow extension of eboard to new > rendering methods, with minimal extra code. My goal: For Bughouse play, Eboard should do almost as good as Thief does. In more detail: If partner tells 'ok' then play soundfile 'ok.wav'. If partner tells 'hard' then play soundfile 'hard to get.wav' and so on... So one can really hear the partner tells during a game. The current 'beep' notification isn't enough. About 30 different partner tells should be recognized (just the same Thief behaviour, so Eboard should be compatible with Thief here). If one observes a bughouse game, Eboard should automatically observe the partner game. These two games should be visible at the same time. Currently this works in playing mode only, not in observing mode. Moving the chessboards and the partner communication buttuns to separate windows. The current notebook behaviour is too restricting to the user. At least my layout wishes are not realisable with the current Eboard. I want Eboard to display my playing board and the partner board side by side, not one upon the other. So moving the two 'notebook-widgets' to separate windows would almost be enough. How else has goals? Are all these goals compatible? Next question is how we want to reach our goals. Which tools are going to be used? I would like to use gtkmm, and I'm willing to rework all the necessary code parts. Once I did this, I would start to implement my desired bughouse features. In the next days, I will have a closer look to the Eboard code. I want to get a short overview about how Eboard works, before I'm starting to discuss desired interfaces and so on. @Felipe: At first glance I didn't find much comments in the code. So if you have some more documentation about anything, please let us know. cu, Sebastian |
From: Paulo S. <pa...@be...> - 2005-03-09 00:37:17
|
My goals: * Depend on up-to date libraries (that is, Gtk2 family. if its pure c or c++ is not that important, although i prefer pure c. ) * Be as stable and easy to use as current eboard. * The multiple games appearing at the same time thing is quite important to me. When i'm watching, say, the Linares relay, i like to just lay down on my bed, tune in on chess.fm and relax. Having to get up to change the game that is showing whenever new moves occur is quite irritating. Lesser goals, but very interesting and i might work on them: * Better suport for databases (pgn), the current interface is not very good IMHO, and if possible open ChessBase type files. * Don't know if it's possible or legal but: the chessbase famly of programs are, afaik, distributed as .dlls that the interface (Fritz) uses. So, i'd like to make it possible to use engines such as Hiarcs and Junior under linux. Off course, one would still have to aquire this dlls in a legal way. Also: i think babachess is really cluttered and we shouldn't let eboard get so, BUT i think it is possible to add new features without letting that happen. -- Paulo Schreiner <pa...@be...> |
From: Sebastian W. <seb...@ss...> - 2005-03-17 11:34:08
|
Hi again! On Wed, 9 Mar 2005 00:47:13 +0100 I wrote: > I would like to use gtkmm, and I'm willing to rework all the > necessary code parts. Once I did this, I would start to > implement my desired bughouse features. > > In the next days, I will have a closer look to the Eboard code. > I want to get a short overview about how Eboard works, before > I'm starting to discuss desired interfaces and so on. Eventually I decided it would be to hard for me, to port Eboard to GTK+2.x/gtkmm. As I have no experience with GTK+1, GTK+2 or gtkmm it will be very hard for me to rework all of the GTK+ related code parts. As soon as I start the rework, everything will stop functioning. And in gtkmm there the gdata* are no longer necessary in most callback functions. So, a rework of all the friend-methods is necessary as well. I think the porting to GTK+2.x will simply overwhelm me. Sorry for that, but i'm not going to work on eboard in the near future. Perhaps I will start a 'new' eboard from scratch with GTK+2.x/gtkmm. As it is quite important to me to have something working all the time for testing purposes. Of course, I will reuse big codeparts of the current eboard whereever possible. With a friend of mine I'm going to rework the eboard classes a bit, to better fit the c++ style of gtkmm. When I have time to start this, I will sent comments to this list. cu, Sebastian |
From: Lakin W. <ni...@nu...> - 2005-03-18 03:05:53
|
On Thu, 2005-03-17 at 12:38 +0100, Sebastian Wassmuth wrote: > Hi again! > > On Wed, 9 Mar 2005 00:47:13 +0100 > I wrote: > > > I would like to use gtkmm, and I'm willing to rework all the > > necessary code parts. Once I did this, I would start to > > implement my desired bughouse features. > > > > In the next days, I will have a closer look to the Eboard code. > > I want to get a short overview about how Eboard works, before > > I'm starting to discuss desired interfaces and so on. > > Eventually I decided it would be to hard for me, to port Eboard to GTK+2.x/gtkmm. As I have no experience with GTK+1, GTK+2 or gtkmm it will be very hard for me to rework all of the GTK+ related code parts. As soon as I start the rework, everything will stop functioning. And in gtkmm there the gdata* are no longer necessary in most callback functions. So, a rework of all the friend-methods is necessary as well. I think the porting to GTK+2.x will simply overwhelm me. To try and get it all done at once, or even to plan it all out is quite overwhelming. > Sorry for that, but i'm not going to work on eboard in the near future. Perhaps I will start a 'new' eboard from scratch with GTK+2.x/gtkmm. As it is quite important to me to have something working all the time for testing purposes. Of course, I will reuse big codeparts of the current eboard whereever possible. With a friend of mine I'm going to rework the eboard classes a bit, to better fit the c++ style of gtkmm. I seriously doubt that a rewrite to Gtkmm would be possible without losing functionality along the way. As such I would recommend the following (which is similar to your idea of starting a "new" one.) What I would do is start by making a list of all of the functionality that Eboard contains. To start with a rough list would be as follows: 1) Play against the computer using GNU Chess/Crafty 2) Play online against other players. (You would need to expand this.) This list would give you a very nice roadmap which would help you avoid being overwhelmed. Then pick an attainable starting point, possibly a single board, a single game engine (GNU Chess/Crafty), and the ability to pick whether you're white or black, and play a game. Something like this would make a very easy starting point. Then order the list, publish the list, and starting implementing each item one by one. It would be easy to ask for help, if the tasks were small enough, anyone with a weekend to spare could help implement each task. You could put the code in CVS in a different branch than the gtk 1.x version. > When I have time to start this, I will sent comments to this list. Glad to hear it. I've used Gtkmm for a few months now, so I could answer questions and give advice. Lakin |
From: Lakin W. <ni...@nu...> - 2005-03-18 03:12:28
|
On Thu, 2005-03-17 at 20:05 -0700, Lakin Wecker wrote: > On Thu, 2005-03-17 at 12:38 +0100, Sebastian Wassmuth wrote: > > Hi again! > > > > On Wed, 9 Mar 2005 00:47:13 +0100 > > I wrote: > > > > > I would like to use gtkmm, and I'm willing to rework all the > > > necessary code parts. Once I did this, I would start to > > > implement my desired bughouse features. > > > > > > In the next days, I will have a closer look to the Eboard code. > > > I want to get a short overview about how Eboard works, before > > > I'm starting to discuss desired interfaces and so on. > > > > Eventually I decided it would be to hard for me, to port Eboard to GTK+2.x/gtkmm. As I have no experience with GTK+1, GTK+2 or gtkmm it will be very hard for me to rework all of the GTK+ related code parts. As soon as I start the rework, everything will stop functioning. And in gtkmm there the gdata* are no longer necessary in most callback functions. So, a rework of all the friend-methods is necessary as well. I think the porting to GTK+2.x will simply overwhelm me. > > To try and get it all done at once, or even to plan it all out is quite > overwhelming. > > > Sorry for that, but i'm not going to work on eboard in the near future. Perhaps I will start a 'new' eboard from scratch with GTK+2.x/gtkmm. As it is quite important to me to have something working all the time for testing purposes. Of course, I will reuse big codeparts of the current eboard whereever possible. With a friend of mine I'm going to rework the eboard classes a bit, to better fit the c++ style of gtkmm. > > I seriously doubt that a rewrite to Gtkmm would be possible without > losing functionality along the way. I wanted to clarify this previous statement. I seriously doubt that a rewrite to Gtkmm would be possible without losing functionality during the process. The final goal would be to reproduce a version of Eboard using gtkmm that has all of the functionality of the Gtk 1.x version. > What I would do is start by making a list of all of the functionality > that Eboard contains. To start with a rough list would be as follows: > > 1) Play against the computer using GNU Chess/Crafty > 2) Play online against other players. > > (You would need to expand this.) > > This list would give you a very nice roadmap which would help you avoid > being overwhelmed. Then pick an attainable starting point, possibly a > single board, a single game engine (GNU Chess/Crafty), and the ability > to pick whether you're white or black, and play a game. Something like > this would make a very easy starting point. > > Then order the list, publish the list, and starting implementing each > item one by one. It would be easy to ask for help, if the tasks were > small enough, anyone with a weekend to spare could help implement each > task. > > You could put the code in CVS in a different branch than the gtk 1.x > version. > > > > When I have time to start this, I will sent comments to this list. > > Glad to hear it. I've used Gtkmm for a few months now, so I could > answer questions and give advice. > > Lakin > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Eboard-devel mailing list > Ebo...@li... > https://lists.sourceforge.net/lists/listinfo/eboard-devel |