RTools - The July 2010 Roadmap

--- 1.1.0 --- (August 2010)
1.1.0 is pretty much just at the point where I'm doing small things right now. (though, I call match slips a small thing) I should be switching this from alpha (features still being made) to beta (bug squashing only) in the next week or so. I'm waiting on one last possible feature addition to work on, but I don't have anything major on my plate.

--- 1.2.0 --- (~October 2010)
This should be the EPIC update. There's also a couple other things which I have part-way coded, or working in some form, that I'll hold off on releasing until here. The EPIC code isn't dependent on 2.0 coding, so I may turn this into 2.1 if 2.0 gets finished before I find a host.

--- 2.0 --- (~2010)
Now, I should clarify how I use version numbers. In a version 2.4.3, 3 indicates that this is the third minor update, with only minor feature changes and bug fixes. the 4 says that there have been 4 updates that I can't consider small, usually for a feature I don't call minor or for a compilation of smaller features. The 2 defines the "build" which the program is; by this, I mean that this is the second time which I have worked on the core of the program and changed just how the program executes through the things it needs to do.

With a lot of the updates since 1.0 (well, the 0.5 beta), there has been a bit of a fragmentation in terms of how the program treats tournament data. The issue is that the original builds treated each window as it's own program, and when you launch a window, the main program compiles and sends all the relevant data to the window; this new window just does it's thing on it's own, and doesn't care about the main program.

Now, if you look at the current program, there's are things which talk between each other in various forms. The settings system and tournament colors are the most glaring, but there are other internal systems that now need to talk to each other. This means that there are sometimes two ways which information is stored, for two different systems to use in different ways; doesn't sound like much, but it's a bother when you need to make sure that two different places are changed always. But, EPIC has one feature in particular that I can't implement because of this fragmenting: a round clock inside the web interface. Since the round clocks are completely separate from the main program, (except for the tournament colors...) there's no way I can ask for the time and send it to the web server.

The fix for all this is to decrease the scope which the back-end has to work though. Right now, everything works on a program-basis; if I press the Pairings button, the program does a bunch of things on the program level, and tells other functions to get the info it needs before it finally goes into the window/printing system. What I want to change this to is a tournament-based system at the back-end. Meaning, what you see doesn't change all that much, but what actually is occurring behind-the-scenes is much different.

For example, when you say you want a timer for a tournament, right now a new one is simply spawned. In the new system, there will automatically be a timer associated with that tournament. If you haven't used it since opening the program, you get a new one. If it's opened already and behind windows, it'll just regain focus. If you closed it earlier and it was still running, it'll come back up as if it was never closed.

The huge benefit to this, though, for a timer (along with other parts) is that since the entire tournament's windows are managed through a single location, it's much easier to do something like get the time from the window, and stick that number somewhere where it would be accessible to EPIC.

The system will also benefit with better settings management. When you first go to a new tournament, the tournament will acquire default settings from the program defaults; however, if you change a setting, it'll be associated directly with that tournament and the windows in it. In essence, how "Tournament-Based Colors" works, but much more efficiently integrated and for fonts, background colors, etc.