search

asdfjkl / jfxchess

JFXChess - Chess Program
https://asdfjkl.github.io/jfxchess
GNU General Public License v2.0
102 stars 21 forks source link

Enhancements #8

Closed sshivaji closed 8 years ago

sshivaji commented 8 years ago

Hi,

I have done a bunch of things to improve the UI look and feel along with misc things. I authored kivy-chess in the past (https://github.com/sshivaji/kivy-chess). However, after looking over your code, I much prefer PYQT4 and its widgets.

I have a bunch of things in my roadmap, mainly to bring up large database position search with custom search text (this works well in kivy chess and my web solution too). For example on Kivy chess, I support searches like what are the top games of Magnus carlsen after 1.e4 c5 2. Nf3 d6 3. Bb5+ where his opponent's rating is more than 2700.

I can also do DGT board support (from picochess, where I am also a co-author). DGT support also works in kivy-chess.

Anyway, take a look at my fork and merge as you please. Feel free to contact me anytime.

Thanks!, Shiv

sshivaji commented 8 years ago

One thing I realize, I removed coordinates display, this should probably be an option. However, for serious chess players, I think coordinates are annoying, I know coordinates by heart for a long time.. :)

asdfjkl commented 8 years ago

First of all, thanx! I'll look into this and will try to merge things as soon as possible. Note that I am currently rewriting version 3.0 in C++/Qt (due to various issues with python), so please have some patience :-)

sshivaji commented 8 years ago

I am making some small improvements as we speak.

I am concerned about moving to C++ as python is easier to develop than C++ at least for me, are you sure you want to do this? :)

On Sun, Jan 10, 2016 at 11:20 AM, Dominik Klein notifications@github.com wrote:

First of all, thanx! I'll look into this and will try to merge things as soon as possible. Note that I am currently rewriting version 3.0 in C++/Qt (due to various issues with python), so please have some patience :-)

— Reply to this email directly or view it on GitHub https://github.com/asdfjkl/jerry/pull/8#issuecomment-170383166.

asdfjkl commented 8 years ago

Yes, I see the future definitely in C++/Qt. This has to do mainly with deployment, but also other issues. I wrote about the reasons here https://buildingjerry.wordpress.com/2015/12/16/next-steps-c/ Note that I found that writing in Qt-flavored, modern C++ is actually not that hard compared to python, but you gain a lot by static typing, imho...

sshivaji commented 8 years ago

I see. I might help maintain the python fork then. I prefer python for my dev at least.

PYQT is def a step above Kivy (another framework I played with), at least QT's widgets are available.

Will observe how the C++ effort turns out as well.

sshivaji commented 8 years ago

One question to ask on your highlight. Rather than using offsets, it seems easier to make every move reachable via fen (to respond to click to move). With custom fonts and sizes like I am using, the offset calculation seems wrong for large games. Do you have more information on this?

I am tempted to re-write this layer to include a fen for every move, so that click on move can be done without offsets.

Shiv

On Sun, Jan 10, 2016 at 11:24 AM, Dominik Klein notifications@github.com wrote:

Yes, I see the future definitely in C++/Qt. This has to do mainly with deployment, but also other issues. I wrote about the reasons here https://buildingjerry.wordpress.com/2015/12/16/next-steps-c/ Note that I found that writing in Qt-flavored, modern C++ is actually not that hard compared to python, but you gain a lot by static typing, imho...

— Reply to this email directly or view it on GitHub https://github.com/asdfjkl/jerry/pull/8#issuecomment-170383535.

sshivaji commented 8 years ago

Also, what is your email address, it might be easier to touch base by email, mine is sshivaji at gmail.com

On Mon, Jan 11, 2016 at 12:41 PM, Shivkumar Shivaji sshivaji@gmail.com wrote:

One question to ask on your highlight. Rather than using offsets, it seems easier to make every move reachable via fen (to respond to click to move). With custom fonts and sizes like I am using, the offset calculation seems wrong for large games. Do you have more information on this?

I am tempted to re-write this layer to include a fen for every move, so that click on move can be done without offsets.

Shiv

On Sun, Jan 10, 2016 at 11:24 AM, Dominik Klein notifications@github.com wrote:

Yes, I see the future definitely in C++/Qt. This has to do mainly with deployment, but also other issues. I wrote about the reasons here https://buildingjerry.wordpress.com/2015/12/16/next-steps-c/ Note that I found that writing in Qt-flavored, modern C++ is actually not that hard compared to python, but you gain a lot by static typing, imho...

— Reply to this email directly or view it on GitHub https://github.com/asdfjkl/jerry/pull/8#issuecomment-170383535.

asdfjkl commented 8 years ago

sorry about not replying. currently quite busy. will come back to you asap. if you have more stuff coming, please consider separate pull request. way easier for me to check what has been changed...

From a first quick look I'll not accept everything to the main branch (hope you don't take this the wrong way, since I appreciate the contribution) 1.) Updates to look etc. I will reject these changes for now. I tweaked a lot until I found the current setting and I like the clean and simple look and would rather like to leave this the default look of Jerry. On the other hand, I can understand that you (and others) have different preferences, and we should have an options dialog for that (maybe Edit -> Options or something). I imagine a bunch of carefully selected board styles and piece styles (but we should check that no ugly combinations are possible). Btw.: are all fonts and images you used available under a free, gpl2 compatible license?! 2.) Font: Same for font size. Notice how the current implementation breaks jumping to positions. Check how I do this in the current development version (c++), there I use QTextbrowser and anchors, works much much better and faster. 3.) Text Encoding: I was about to write that fixing western european extended ascii breaks unicode and that we need a rough text encoding algorithm... and then you already fixed it - nice :-) I'll merge that asap. 4.) Board coordinates: I really think we need this. Notice default settings of (commercial) competitors. Could be an option to turn them off though... uh and, dominik dot klein at outlook dot com.

sshivaji commented 8 years ago

After playing with pyqt a bit, I am disappointed that anchor support is not as good as expected. You cannot easily go to anchor for example. I fixed the jumping to positions but I notice that even in your initial python version, jumping to positions does not work well (I tried with large and messy files).

At this point, I think I will call it quits and get back to https://github.com/sshivaji/kivy-chess. PyQT is not bad, but somehow I run into problems with anchors and jumping that I should not run into, QTextEdit should provide more api such as jump to anchor.. I will look at your C++ implementation and might contribute back on a later date. Feel free to withdraw/close this pull request.

asdfjkl commented 8 years ago

I am closing this. I am focusing my work on version 3. There, I have implemented your GUI patches (cf https://buildingjerry.wordpress.com/2016/01/30/colors/ ). I will also add the encoding detection in future version. Again, thanks very much for your input & patches.

As for anchors, indeed, QTextEdit is not enough. In the C++ version, I use QTextBrowser, which supports anchors...