GNOME Bugzilla – Bug 664946
Add Telepathy networking support
Last modified: 2018-05-22 12:21:49 UTC
I was thinking about this since a few days and here I found it! Will be working on this now. Hi Robert, need your support in how to go about this.
Alright, I see Telepathy tubes are the deal for it but I'll need someone for testing etc. Checking out glchess meanwhile. This sure will rock!
Great! Please post status/patches in this bug report.
I created bug#666330 for making it possible to initiate networked games with empathy. As of now, only telepathy-gabble is capable for supporting stream tubes (http://telepathy.freedesktop.org/doc/book/sect.tubes.compatibility.html) and we'll use it for establishing a chess-tube connection with our jabber contacts.
The UI is being handled as a part of Glchess game screen (bug#664972). It involves contact-chooser UI and loading of contacts and will continue with eventually fixing this bug. WIP- https://gitorious.org/glassrose-gnome/gnome-games/commits/glchess-new-game-screen-664972
Hi! I have a question regarding placement of the game-contact-manager, tube-channel-handler and tube-channel-approver classes. Ideally we should have just one in libgames-support so that all games can use single copy but I am afraid glchess (which doesn't use any of the components from libgames-support presently) will not remain an independently install-able module with it's networking depending on libgames-support. How should I approach such problems? What's the preference here? I would also like to make networking support for games an optional feature (if that sounds nice) so again --enable-networking will be a single option for all gnome-games to be installed in one go. A single copy of common classes will aid clarity and maintainability.
Hmm, seems to me, apt-get fetches glchess for me from the non-gnome version found here: https://glchess.svn.sourceforge.net/svnroot/glchess/trunk/glchess-python/ and our vala glchess is not this one included as a submodule, so going by the correct approach for gnome-games, I proceed adding stuff to libgames-support. :)
Hi Chandni, Using libgames-support is fine for now, we can always split it out later if necessary.
ok, libgames-support was in C so I did the low-level bit in C(and also renamed the branch) https://gitorious.org/glassrose-gnome/gnome-games/commits/glchess-new-game-screen-and-remote-players-664972 I like to have contacts with images so worked fetching of the avatars too. I have done some tests on this but loading in final UI is still not complete. Saving incomplete games is going to be a tricky part. Let's see how to go about it!
Design points: Folks IndividualAggregator is prepared as soon as glchess is launched. This is done in a thoughtful way in order to utilize user idle time by caching user-presence and capabilities details in the background while the user proceeds through game configuration so by the time he reaches the point where he would select a remote player, the list of players capable of playing glchess will be already prepared. Next steps are planned as this now: To make glchess a telepathy client, and thus an application which can be invoked by the Channel Dispatcher of telepathy-mission-control daemon, I am splitting glchess into 2 parts. One will be the initial option screens to configure and initiate a game from user side which will be registered as "org.gnome.glchess" on the dbus. The other will be registered with the well known name "org.freedesktop.Telepathy.Client.glchess" and will be launched when user approves a glchess channel request using the "games-approver" or himself asks it to handle a new channel created by clicking "Start game" with a selected capable remote player.
Some heuristics for obvious convenience:- Chat will be performed with the most available persona(or login or point of contact) of an individual (among all available which are aggregated to form a conceptual individual). Games will be initiated with the most available persona that supports the particular gaming capability. Note that the two can be distinct (for good)!
or better, I'll create a user-defined gsetting out of it since it won't be good once connection has been accepted
https://gitorious.org/glassrose-gnome/gnome-games/commits/games-networking-contacts-API This contains the API support for fetching and displaying Folks contacts from Telepathy backend. Usable but I might make additions if they seem necessary.
Handwritten GnomeGamesSupport-1.0.vapi is not yet updated with this API and having to manually edit it everytime the library changes is making me sick. Sincerely thinking of taking an easier, more maintainable path.
Created attachment 221676 [details] rough idea of window showing the contacts and open chess channels
I automated the above task and abstracted it as a tool (bug #680409) which assuredly will be very useful as it was for me. The chess channels will be handled by a common UI supporting contact-lists, presence changing combo-box, a list of open channels, a game-playing frame and a chatting frame which could be opened with the contact on selected gaming channel. Not completely implemented. See the attached png above for rough idea. #IANAUID --------- Since the probability of users opening channels for a single kind of networked game with many contacts at a time would be less, while I was designing the UI frame solely for glchess, I struck this idea of having a single UI frame which would be able to load different kind of games as desired by the user with the desired contacts in a single window. Since gnome-games are not a centrally controlled, this would be a good exercise on dbus messaging where this UI would be a dbus-service (acting as view; which could be launched by any networked game) with individual games acting as real controllers. I have not given much thought to it since I am not sure if a single controlled UI for multiple networked games is desired or not but I can say it would be a big overhaul wherein games would have to be clearly divided into separate MVC design pattern sections. --------- Not a requirement for the primetime, the above can come of use if future requests arise as games evolve in number and include more dual and multi-player games. Will come with a working implementation supporting glchess channels next (which will definitely look better than the attachment above).
As per discussion, gaming with a real person will not have "undo" option since that would be inappropriate.
The user experience is defined as follows: Self-requested- 1. User launches glchess. 2. selects a capable remote player to play chess with. 3. a channel is created and New Game screen window hides itself. 4. mission-control-daemon launches glchess-channel-handler 5. Requesting new channels with the glchess-channel-handler is even more easy- right click a contact and click start new game. 6. "Game Options" screen is shown again (thus skipping asking for the obvious settings about the apponent for this new game). Incoming chess channel- 1. If glchess (--with-networking=yes) is installed and you are connected to any account supporting dbus-tubes (eg. an XMPP account using telepathy-gabble connection manager(which works behind Gnome Online Accounts and Empathy for instance)), then any of your contacts can see you as capable of playing chess if they are using a powerful chess playing client like a recent enough version of glchess! 2. Games-channel-approver is a dbus-activatable service which is started when there is an incoming channel request. 3. If "Advertise chess playing capability to contacts" GSetting is checked and if you are online using an appropriate account(as mentioned above), you are in a receptive state of chess game requests from your contacts whether or not glchess is running. (This is a plus point which I am making possible for the first time through feature https://bugs.freedesktop.org/show_bug.cgi?id=53818) 4. If an incoming channel arrives and you approve it, glchess-channel-handler is launched where you can play. 5. If you don't want to receive channels for chess games at any time, just uncheck the "Advertise chess playing capability to contacts" setting.
Here is the branch with up-to-date work. Unfortunately (or fortunately) I dicovered a bug in establishing channels with remote contact which lead me finding myself working on 2 separate X-sessions and 3 separate consoles with multiple screens simultaneously. But that I am fixing so nothing to worry. https://gitorious.org/glassrose-gnome/gnome-games/commits/glchess-telepathy-networking-support-664946-new We will get this completed very soon, stay assured. I just don't want to leave any chances of correction and make commits as atomic as possible so that reviewing it is ABC. Thanks for being patient. The additional functionality listed above in point 3 may or may not be implemented in this cycle depending on how quickly I fix this bug.
Hi Chandi, Can you attach a git patch here so it can be reviewed using the bugzilla tools?
Sure! A few lower level blockers have been resolved and merged: https://bugs.freedesktop.org/show_bug.cgi?id=54543 for telepathy-glib0.19.9 https://bugs.freedesktop.org/show_bug.cgi?id=55024 for telepathy-glib0.19.10 There have been a few corrections for comments in branches blocking on this bug which have caused some havoc here. Will upload latest work soon.
Running status: https://gitorious.org/glassrose-gnome/gnome-games/commits/glchess-telepathy-networking-support-664946 Promotion-type selection dialog- done New game launcher- done Folks Contacts- done Game Filters for contacts- done Chat channel initiation- done Launcher split- done Application split- done Channel handler framework- done Handler subclass chess application-done Connections- done Tube Channel dispatch- done Tube offer and accept- done Channel Handling and channel cache- done Channel display- WIP (some amendments remaining) Presence controller and gnome-online-accounts integration- todo Few things I planned for 3.7 but will go together now as a complete goodie package(for good! I hate people complaining of incomplete features due to small gnome cycles full of unstable bleeding edge software): Remote game save and unfinished history-todo Approver notifications- todo Telepathy feature bug# 53818-todo GSetting preferences- todo Additionally, lower level branches(bug#655761 on peer-review currently) are waiting to be eyed upon by Robert Ancell for things I might have overlooked and to provide an expert finishing touch.
> Telepathy feature bug# 53818-todo I mean https://bugs.freedesktop.org/show_bug.cgi?id=53818
Hi, As discussed, for identifying "unfinished games" we aren't quite willing to move forward with a separate database using a 4 tuple UUID (<sender ID>, <receiver ID>, <offerer unix-timestamp>, <offerer-tossed random no.>)); which I suggested, as that would be an overkill at this stage; giving preference to searching list of unfinished game-files to find required one. matching the file contents as provided in the request (and if not creating one). I thought about it's implementation and can see other aspects which come with this that are worth a note: 1- At the offerer end, every time a remote individual appears online, we will be searching through offerer's database of unfinished games to find an unfinished game played between any of our currently logged in accounts and any of that individual's currently online tp-contacts. (slight visible delay may occour with O(no. of game-files * total personas involved) at this point but we can be OK with that) 2- At the acceptor's end, the approver will search game-file directory to find a game-file matching the one in offer and will notify player if game didn't exist and ask whether to continue with the file provided. Then channel will be forwarded to handler where searching will be reperformed to find the game-file to edit again since there is no way the approver can pass it's search results to handler and can't edit the incoming channel's parameters to provide the handler with this processed information (situation might change in future: https://bugs.freedesktop.org/show_bug.cgi?id=57721). If handler doesn't find it, it will fallback to creating a new one with the file-data provided in the offer. 3- 2 extra Black player ID and White player ID tags will be introduced in game-files which will hold player IDs according to underlying IM protocol to compare against. These are needed since without player entries in database (which we don't want to add), that's the only way offerer can identify which game-file to resume. 4- For search, we cannot compare file contents word-to-word since Date and Time tags(which contains local times) will be mismatching. So we'll be converting them to corresponding pgn-games to compare a)Player IDs and b)FEN moves c)Time Control and d)Result, at every step. Games with any other mismatches apart from these will be considered same and the recent-most locally will be continued. Will be proceeding with these in mind if these sound good enough. I also want to bring to notice the interpretation of TimeControl on game resumptions. Unfinished timed games don't track how much time elapsed in last rounds and start from full-time each time. I'll leave them working as such. That could be another bug so I'll avoid cluttering this one.
I am in strong support and inclination for having Black and White player ID fields along with the local pgn-creation times in the database as well as as to let sqlite3 do the lookup for us.
(In reply to comment #24) > > 2- At the acceptor's end, the approver will search game-file directory to find > a game-file matching the one in offer and will notify player if game didn't > exist and ask whether to continue with the file provided. Then channel will be > forwarded to handler where searching will be reperformed to find the game-file > to edit again since there is no way the approver can pass it's search results > to handler and can't edit the incoming channel's parameters to provide the > handler with this processed information (situation might change in future: > https://bugs.freedesktop.org/show_bug.cgi?id=57721). If handler doesn't find > it, it will fallback to creating a new one with the file-data provided in the > offer. > Here we have one more alternative. If we take advantage of the fact that an average user does not play chess with varying machines from one persona, then there are high chances that we will almost always have a matching game-file at the acceptor's end to continue. We have already laid a restriction that a user will only get offers to play unfinished games which he has played with any of the IDs with which he is logged in currently (point 1 in comment 25), so having to ask him to log in with the his another ID is already ruled out. As such, we can want to have the Approver only ask the acceptor if he wants to play an unfinished game with the offerer at all. Only this. ..and then if answered "yes", the Handler process will do the appropriate file search and loading. If not found (which we take as an extreme rare case so won't hurt), the handler will ask user to continue creating a new file or close the channel. Seems more practical to me.
I am making these assumptions and work is proceeding in branch https://gitorious.org/glassrose-gnome/gnome-games/commits/glchess-telepathy-networking-support-664946-rebase-2.
Please rebase your branch on the new gnome-chess respository.
Ok, yes. I should change names
Rebase-merged and pushed 65 commits up here: http://git.gnome.org/browse/gnome-chess/log/?h=chess-telepathy-networking-support-664946-rebase Not completely complete yet. I need some sleep.
Work on this is on hold due to src/gnome-chess crashing on startup due to folks/gee. Here's the bug tracing this: https://bugzilla.gnome.org/show_bug.cgi?id=702279
I see in the Telepathy 0.18 changelog "old-style Tubes channels have been removed." I am not terribly familiar with Telepathy, so my dumb question is: is this bad for your sidebranch? (In reply to comment #31) > Work on this is on hold due to src/gnome-chess crashing on startup due to > folks/gee. Here's the bug tracing this: > https://bugzilla.gnome.org/show_bug.cgi?id=702279 Whoops, I completely missed this! Looks like you've gotten that taken care of?
(In reply to comment #32) > I see in the Telepathy 0.18 changelog "old-style Tubes channels have been > removed." I am not terribly familiar with Telepathy, so my dumb question is: > is this bad for your sidebranch? Whoops again, that's just the gabble changelog... I doubt you're using that.
Hello Michael, No the old style tubes are useless and I use the new dbus-tubes. I am afraid that the master has diverged widely including the files I have touched. So my question is that, Is it OK, If I try to make my branch work on master by reverting some of your commits which touch the files I require?
You can make a new branch off of master, revert commits there, and merge that branch into the telepathy sidebranch. (Just be sure to keep track of what's been reverted, so we can manually un-revert later.) Please don't revert anything in master itself, though. I've started working on this merge to see how bad it would be (it's bad), and cleaned up most of the conflicts outside of gnome-chess-application.vala, but there are lots of conflicts there which I haven't gotten to yet. This work is in the new branch telepathy_merge. You might find it helpful to start from there, but feel free to just ignore it if you don't think it'd be helpful. (Certainly if you're going to try reverting commits, it'd be easiest to not use this branch.) My strategy was to handle the gnome-chess.vala -> gnome-chess-application.vala split separately in order to get conflicts in gnome-chess-application.vala (otherwise the entire Application class is treated as one big 2000-line conflict).
One more thing: if you do choose to work on the new sidebranch, don't worry about cleanliness of commits. We can squash everything merge-related together when we're done.
I knew, rebasing this without reverting some of the commits is going to be a walk through hell! We can redo the reverted commits later. I'll keep a track of each reversion in a new side-branch.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-chess/issues/9.