Porting to JavaFX 8+

[lopho]

Hi there,

just here to give a heads up to xmage devs that I will give a shot at porting xmage from swing to javafx 8, piece by piece.
Ill dedicate the next week to it and see how it fares. If it goes somewhat smooth i'll keep at it, if not... maybe ill keep at it as well.
Im pretty new to javafx and this will be a learning project for me, so no promises.


Any pointers where to start or what to look out for from the devs would be appreciated. You can follow my progress on my xmage fork - javafx branch - on github (same username as here).

Greetings and stuff

[BetaSteward]

I would hold off for a few days before starting. I am in the process of updating the client/server communication framework and this will mean that some changes to the client are needed. I am hoping that the interface will be simpler for those working on UI pieces. Look for a new branch shortly.

As for a starting point I would look at the login dialog and then the tables pane along with it's associated chat pane. That is usually the first view that users have and it encompasses a lot of the necessary client/server communication.

BetaSteward

[lopho]

ok, ill not get into it seriously until then. I will have the next week all to myself, and i wanted to dedicate my time to this.
Do you think you will be done by the coming week (sat,sun,mon)?

[LevelX]

Maybe you don't know but there were already some effords to create such a JavaFX client.

North was also working on it and maybe he can tell about of the problems he run into (if I remember right there were some).

Here's the project link on github:
https://github.com/magefree/fx-client

And there was anothe try from JDub, but there is only a fork available from the project.
https://github.com/Noahsark/magefx-client
I guess this project was later included in the other JavaFX project from the previous post.


Here is the more relevant dialog about the JavaFX project, maybe it's of interest.

JavaFX.pdf

(876.39 KiB) Downloaded 2149 times

[lopho]

Interesting read.

Seems like they were trying to do a complete overhaul. I was planning to keep it simple at first, reproducing the current layout etc 1:1 more or less, and maybe cleaning up the view code on the way. I yet have to dig into the code base deeper before i can make an educated guess on the feasability though.

I'll take a look at the previous efforts.

Thx for the info.

[BetaSteward]

I've created a new branch and committed the first change. Right now it's got very limited functionality but it will give you an idea of how it should work going forward.

[lopho]

Making some progress. Decided to rewrite the client from scratch, too much stuff going on with swing threads, and i believe porting it component wise will make it a giant mess

I'm running the Network_Upgrade server branch, the changes seem straight forward and easy to adapt.

One thing that is giving me a hard time atm is the

Code: Select all

client.disconnect()

method as it never returns. It's stuck on

Code: Select all

channel.closeFuture().sync();

.

It's a problem that definetly is not a roadblocker, but it's inconvienient for testing, as I have to kill the client manually, and restart the server, as it will crash out when connecting again with this ... well damn I cannot paste the stack trace, forum is telling me that

Your post looks too spamy for a new user, please remove off-site URLs.

ok, pastebin then.... also too spammy? OK THEN. I gotta obfuscate the link... damn

http pastebin com W3AfNn1G

[LevelX]

ok, pastebin then.... also too spammy? OK THEN. I gotta obfuscate the link... damn

http pastebin com W3AfNn1G

Should be ok now, I guess it's only for your first 4 posts checks.

[lopho]

hey, im back
still progressing, although not as fast as i hoped (gotta wait for that fresh network stuff , no rush though).

Back to the disconnection issue.

Disconnecting now works more or less, but reconnecting after a disconnect does not work. This time it's not the server that gets foobared but the client. Seems like once the channel is closed it cannot be reopened or something, or maybe its that the chathandlers arent being removed upon disconnect.

Just a heads up to betasteward, maybe the stack trace will be helpful (the stacktrace is taken from the original MageClient, Network_Upgrade branch, more or less the same with my fx client sans FXThread stuff)

http://pastebin.com/eRyyFPxS


(nice)

[BetaSteward]

Great to hear that you're making progress. I'm going to have to step up my game to give you some more material to work with.

Check out my latest commit. I tried removing all pipeline handlers after disconnecting but that didn't work. So instead just destroy the existing client object and create a new one each time.

[fireshoes]

Maybe kind of a different topic, but regarding the reconnect after a disconnect... One problem that affects me is my modem will somewhat regularly lose connection to my ISP (it's a cellular signal), which causes my IP address to change, so I get booted from my match (because not connected to ISP for a moment) then I can't rejoin it because my IP address has changed. This forces me to change my username to log back in. I know if we get to a point where we have login+passwords that the problem will be solved, but perhaps in the meantime, the logic can be changed. It says "Hey you are logging in as fireshoes but your IP address is different so it's not you." but maybe would be better as "Hey fireshoes is not logged in now but he has a match going, so you are probably him." Maybe that doesn't work with how disconnects are currently, I don't know, but just throwing in my suggestion.

[BetaSteward]

That's an interesting use case. I'll see if there is anything that can be done to accommodate that scenario. Maybe we could have a short grace period during which an attempt to login using the same id would be allowed from any IP.

[LevelX]

To allow everybody to connect seems to me too easy to abuse.
I can already imagine people that wait until someone lost connection and reconnect with the name of the user that lost connection to annoy people.

But I have another idea.

What about simply using a server created UUID (we can simply use the internal userId) for each new sign on and saving this id (specific to the server URL) on the client (best in the java prefs so it's saved if the client crashes). And always if someone connects to the server with a username that is still active on the server the client can send this UUID to identify itself to be the correct user. This way there is no user profile or IP needed to identify and successful beeing able to reconnect.

The only drawback I see I can't reconnect from another system after connection lost, because it has not that saved UUID to identify. But I have to say that will be needed rarely I guess.

EDIT: We have to take into account to be able to sign on multiple times with different user names (and also different UUIDs).

[BetaSteward]

That's a good solution. Additionally we could persist the ID as long as the server is running (or even store it in a database for longer). This would provide a sort of account permanence.

[lopho]

Short progress update.

What works:

# HiDpi

# Connection dialog
- Serverlist from xmage.de or locally stored
- connect disconnect autoconnect
- ssl... kind of, think i gotta dig in a bit deeper, found a bug _maybe_

# Preferences
- Avatar selection
- load/save of preferences

# games view
- table list
- previous match list
- chat (using a web view, works very nice)
- userlist


Right now im working on:
- l10n (for EVERYTHING, resourcebundle injection ftw)
- list sorting and filters for matches,tables,users
- rest of the preferences dialog

Next up:
- match/tournament creation
- whisper
- deck builder

Of course i can only implement what is already available server side, but i still have enough work with the filters and preferences. But maybe match creation would be cool to tackle next on Network_Upgrade.

once everything except the actual game is in place ill clean up, document everything a commit the whole thing on github.

I probably will iterate over it a few more times to get everything right, but it is shaping up very nice and clean.

greets

p.s.: the id would be nice, i was planning on giving every player a unique color for the chat, for easier identification.