I will be posting alpha 12 (v.36) sometime tomorrow. There are several improvements with this update:
- EPIC updated slightly from the RTools side and significantly from the web side. The included EPIC web files includes the updated interface, as well as being able to handle the "Previous Rounds" code additions in RTools.
- Match result slips have adjustments to handle printers that do not follow normal margins. In addition, there is a strip added to the left-hand side of the printout, which is simply a character repeated. The goal here is to make match result slips more quickly identifiable when working with result slips in several different events.
- All scrolling windows have their contents shifted a tad to the right, as when used maximized with CRT screens the leftmost columns were somewhat difficult to read.
- Menu option added to export the local player database in WER into a format that is readable by v3 and WER. The export option in WER is only readable by other WER programs.
There's no exact ETA for this update in terms of time. I just got a new external hard drive, and I'm using this opportunity to run some hardcore drive checking systems on my now-4 drives. This goes at the pace of a little more than 1GB/minute, and I have a little over 4TB to go through here. As the machine doing all this is my programming machine, I'll need to wait for a break in this overall new-drive process to actually get everything together and push it online.
Update 09/30/10 1AM: The update is online, with the updated EPIC files; the external transfers aren't going as well as I expected, so this computer is back to use for normal things. Also, this update pre-emptively changes all "September" listings to "October" a day early.
9.28.2010
EPIC for 2.1 (and States)
This design is the (unskinned) version I'll be running at States: A little more compact, and a much more flexible design. There's no more need for horizontal lines separating sections, and there's also a ton less wasted space, with only minor issues currently with cramped information.
If you are interested in using this during States, the current web version in alpha v.30 works with all the newer versions so far, so you can look at the basics of getting it together on your website now. I'll have this newer setup bundled in the next public alpha release, which I will bring out no later than Oct. 6th. The only issue I want to fix before that is making changes to the result slips setup to fix some margin problems. (these problems don't show themselves in the compact sheet, so I think I'll only need to compare the two setups to find an easy fix)
9.27.2010
A look at EPIC today...
To your right is the current information screen, taken straight from one of my test tournaments. Unlike the other screenshot, this isn't a dummy tournament or mockup, so I just cleared out some of the names. (yes, I know there's a random bracket in the text) This, minus the last section of previous round entries, is what I live-tested at last weekend's prerelease. States will be my official "debut" of the web system, and will use an interface based on this. How much it changes will depend just on how much time I have, but I am intending on making the overall setup look much less like a badly-formatted table (which it is) and actually make it look like something interesting.
Plus, I want to take a shot at looking at how this looks skinned with a different color scheme.
9.25.2010
Prerelease EPIC etc notes
I got the crazy idea this evening to try running EPIC in a live environment for the first time at a midnight prerelease, so that's just what I did. After a quick RTools patch (.31 or .32 will have this random issue I found fixed, I still don't know the cause but I quashed the source) we announced the plan to everyone just before round 1 began, and just had a ticker displaying the website to go to.
Now, this wasn't really an event that would have a strong use case for EPIC, but it still had a few judges, high-level players, and random folk. It's enough that with 4-6 people actually trying it, I could get some good feedback without any chance of server stress. I think about 10 people were using it at some point over the event, and the feedback received was entirely positive and gave me a good path to look forward to in continuing development. (namely, handling bad DCI entries better)
Sleep now, more talk later...
Update 09/25/10: There's a lot of minor notes and changes that I am looking at from one day of the prerelease weekend which I will be at this weekend. The big thing is that things really don't work perfectly when the event is 2HG. I'm not saying that it shouldn't be used, but that the more interesting things RTools can do start having issues once you start moving into team events.
Internally, RTools is at v.32, with the next alpha release probably being v.34. v.31 had a kludge implemented to allow EPIC to work with a specific event setup that I didn't test before, while v.32 made some adjustments to the display that were needed for the setup where I was. Before I release another alpha, I want to clean up these two versions, and also make some changes to the match slip pairing code.
Now, this wasn't really an event that would have a strong use case for EPIC, but it still had a few judges, high-level players, and random folk. It's enough that with 4-6 people actually trying it, I could get some good feedback without any chance of server stress. I think about 10 people were using it at some point over the event, and the feedback received was entirely positive and gave me a good path to look forward to in continuing development. (namely, handling bad DCI entries better)
Sleep now, more talk later...
Update 09/25/10: There's a lot of minor notes and changes that I am looking at from one day of the prerelease weekend which I will be at this weekend. The big thing is that things really don't work perfectly when the event is 2HG. I'm not saying that it shouldn't be used, but that the more interesting things RTools can do start having issues once you start moving into team events.
Internally, RTools is at v.32, with the next alpha release probably being v.34. v.31 had a kludge implemented to allow EPIC to work with a specific event setup that I didn't test before, while v.32 made some adjustments to the display that were needed for the setup where I was. Before I release another alpha, I want to clean up these two versions, and also make some changes to the match slip pairing code.
9.16.2010
I hadn't thought of that...
"Why does the pairings window have that long break between the last pairing and the first pairing?"
The long answer is actually pretty involved. The scrolling system is based off of a previous program which was used in the upper midwest until this year. I built the RTools system initially in the same way as that other program.
If you visualize the scrolling window as a physical window, the scrolling system could be seen as a long sheet of paper behind that window. Every time it moves, the sheet of paper is just moving up until all the information is displayed. Then, the paper is reset to the top and scrolls down again.
So, why doesn't it do it? Because I haven't thought of it, and nobody ever brought it up! Sounds like a good idea, and after doing some implementation to see how this looks, it is most likely a much better setup.
The adjustment that needs to be made is to (using that analogy again) tape the top of the paper to the bottom, and turning it into a looping piece of paper. 2.1.28 has made the adjustments made to add this feature. (2.1.27 also had it, but the implementation was faulty)
Update (09/18/10)
2.1.29 is out to fix a couple bugs brought in with earlier alphas. There is a capitalization function in the program for names that was getting some new text strings sent to it, and those new strings were causing problems in standings by pods printout. Also fixed is an issue that came about with some of the EPIC refactoring, which caused byes to show up again in printed pairing functions. (the byes were checking for a specific signal value in the DCI number as a trigger for not showing, and those values were being overwritten by the new code that ensures DCI numbers will always be on printed result slips)
The long answer is actually pretty involved. The scrolling system is based off of a previous program which was used in the upper midwest until this year. I built the RTools system initially in the same way as that other program.
If you visualize the scrolling window as a physical window, the scrolling system could be seen as a long sheet of paper behind that window. Every time it moves, the sheet of paper is just moving up until all the information is displayed. Then, the paper is reset to the top and scrolls down again.
So, why doesn't it do it? Because I haven't thought of it, and nobody ever brought it up! Sounds like a good idea, and after doing some implementation to see how this looks, it is most likely a much better setup.
The adjustment that needs to be made is to (using that analogy again) tape the top of the paper to the bottom, and turning it into a looping piece of paper. 2.1.28 has made the adjustments made to add this feature. (2.1.27 also had it, but the implementation was faulty)
Update (09/18/10)
2.1.29 is out to fix a couple bugs brought in with earlier alphas. There is a capitalization function in the program for names that was getting some new text strings sent to it, and those new strings were causing problems in standings by pods printout. Also fixed is an issue that came about with some of the EPIC refactoring, which caused byes to show up again in printed pairing functions. (the byes were checking for a specific signal value in the DCI number as a trigger for not showing, and those values were being overwritten by the new code that ensures DCI numbers will always be on printed result slips)
9.15.2010
RTools 2.1.27 (alpha 3)
A couple more features coming in with 2.1.26+ (alpha 2): (more explanations on that numbering in a minute)
- Result Slips going through WER will have DCI numbers added.
- Seatings has an additional option to just show a master list of players. (one-column)
- EPIC is added to the download, as a ZIP file in the RTools_docs directory.
- Context menus (right-click menus) are now accessible from the main window.
- The java icons in the windows are now RT logos. (this was a really old issue; I just figured out I was over-complicating the problem)
I may be holding off on updates for an extended period of time in the near future.
---
There's also another change starting with alpha 2, and that's to the version numbering which I have been using. The system that I was using was great for pre-1.0 releases:
X.Y.Z
X = Full (Major) Release number
Y = Update (Minor Release) number
Z = Revision number
Another way to put it was that Z was for bugfix updates, Y was for feature upgrades, and X was for major changes. (not necessarily upgrades) This worked really well initially, but I actually have never built another program that I actually version-ed into 1.0 and beyond, and there's some annoying aspects to it. Namely, it's really hard to use this system and make incremental updates. When working on 1.1, (and going through now on 2.1) it's a bit of a change, though. For instance, while I was adding features to 2.0, during many of the points the program itself was stable and running fine; the only issue was that the releases weren't much, so in the end a bunch of features just got added together in large numbers of alpha releases, rather than being released as actual releases.
So, the change I'm making isn't actually changing what those numbers mean, but instead changing when those numbers get reset. Before, an update to one number reset all numbers before it. So, going from 1.0.x to 1.1 reset the x to 0.
What's changing is that the x will now be incremented on all releases, private or otherwise; in addition, it'll probably only be reset on major updates. (v2 to v3) So, when I put out what would be 2.1.0a2, it will instead be 2.1.26 (alpha 2). (2.0 had 20 alphas and 3 betas) Full releases won't have any suffix to the version release, but now almost all updates will at least have legitimate version numbers, rather than 2.1.0aXX.
- Result Slips going through WER will have DCI numbers added.
- Seatings has an additional option to just show a master list of players. (one-column)
- EPIC is added to the download, as a ZIP file in the RTools_docs directory.
- Context menus (right-click menus) are now accessible from the main window.
- The java icons in the windows are now RT logos. (this was a really old issue; I just figured out I was over-complicating the problem)
I may be holding off on updates for an extended period of time in the near future.
---
There's also another change starting with alpha 2, and that's to the version numbering which I have been using. The system that I was using was great for pre-1.0 releases:
X.Y.Z
X = Full (Major) Release number
Y = Update (Minor Release) number
Z = Revision number
Another way to put it was that Z was for bugfix updates, Y was for feature upgrades, and X was for major changes. (not necessarily upgrades) This worked really well initially, but I actually have never built another program that I actually version-ed into 1.0 and beyond, and there's some annoying aspects to it. Namely, it's really hard to use this system and make incremental updates. When working on 1.1, (and going through now on 2.1) it's a bit of a change, though. For instance, while I was adding features to 2.0, during many of the points the program itself was stable and running fine; the only issue was that the releases weren't much, so in the end a bunch of features just got added together in large numbers of alpha releases, rather than being released as actual releases.
So, the change I'm making isn't actually changing what those numbers mean, but instead changing when those numbers get reset. Before, an update to one number reset all numbers before it. So, going from 1.0.x to 1.1 reset the x to 0.
What's changing is that the x will now be incremented on all releases, private or otherwise; in addition, it'll probably only be reset on major updates. (v2 to v3) So, when I put out what would be 2.1.0a2, it will instead be 2.1.26 (alpha 2). (2.0 had 20 alphas and 3 betas) Full releases won't have any suffix to the version release, but now almost all updates will at least have legitimate version numbers, rather than 2.1.0aXX.
9.14.2010
EPIC Update
I decided today to make some adjustments towards what I was trying to do with EPIC, and looked at making it work without the database work which I was trying to do. I put together a rough system which basically exported player information via RTools into a text file, which you could then remote-upload to a website and access the data from there. (essentially what v3 does with it's files)
With some major caveats, I do have a path currently where a user can theoretically get tournament information online using this system. Some major things don't work yet...
- Players with byes don't show up. (has to do with how the DCI numbers are currently retrieved, actually a bug but not a visible one)
- v3 only (_much_ easier to do for proof of concept testing than WER)
- No more than one tournament at a time.
So, I do have the opportunity now to expand this into something that's usable without a ton of work; it'll also give me the impetus to resolve an inconsistency in accessing back-end files, which you would see currently in that WER events + match result slips do not print DCI#, while v3 events do.
The one thing which I will be thinking about is whether this modified EPIC system really needs the ability to have more than one tournament at a time in it's system. Since we're no longer worrying about databases, you could instead tell different tournaments to go to different websites, each with a back-end file. The total size of the entire system is currently under 50kb including data, so we're not talking about much in terms of movement.
I would say that the best part of this change in thought is just how long it would take to make an update now. Before, my personal builds were taking 2-3 minutes for a reasonably-sized event to update fully. (not what we're looking for in this kind of software) There is more click-labor in this method, but we're talking about:
- A menu option
- Navigating to a website
- Browsing for the exported file and entering in a short password. (just to make it slightly difficult for someone without knowledge to go in and use it)
You're looking at 15 seconds for this, 2-3 times during a round. Why 2-3? Well, remember me talking about an impetus of the 2.0 changes being the ability to make timers accessible in EPIC? Well, the second update would be re-uploading with the round clock running in order to show on EPIC when the round will end. The third update would be for standings posts at later rounds, just so the numbers get updated.
Just so you know, this stuff is all 2.1 updates at this point, but at the same time this is the first time where I see nothing actually preventing me from releasing this in-full. Although 2.1 shouldn't be out until towards the end of the year, I fully expect that by 2.1 alpha 10, the system will be functional, and all the web application files will be in the downloads for people to setup their own systems.
Update 09/14 5:00PM
The program now works with WER as well as v3 in personal testing. Still getting byes sorted out, as that is a non-issue issue turned into a bug with these upgrades. Bonus: WER match report slips have DCI numbers on them now.
Update 09/15 1:00AM
Byes are being handled mostly at this point. I had the opportunity to go through all the motions during an event tonight and make sure I could get a working system going. The huge plus here is that I can not work entirely on interface improvements from the web end. Since this setup is much more modular than a normal event, I can make the interface a little bit more customizable.
One note is that this system doesn't work with team events at all. There's a myriad of reasons for this, mostly centering around the fact that most of the code in RTools is not designed for multiplayer events. Instead of going through and truly building things in to handle multiplayer as an extension of single-player, RTools rides off of information that is already present in the places where single-player info is stored. (essentially, for a team event, the location that a single-player event stores information has the team's information in it's place) These issues are not things that I have looked into fixing in the slightest, as the amount of work needed to make all this work would need rewriting of all the hook code, which is about 2-3x the amount of code work that the 2.0 update required. (2.0 changed how data was being moved around in the program, this would require changing how that data is acquired, stored, and used, essentially changing everything that _wasn't_ changed in the 2.0 update)
With some major caveats, I do have a path currently where a user can theoretically get tournament information online using this system. Some major things don't work yet...
- Players with byes don't show up. (has to do with how the DCI numbers are currently retrieved, actually a bug but not a visible one)
- v3 only (_much_ easier to do for proof of concept testing than WER)
- No more than one tournament at a time.
So, I do have the opportunity now to expand this into something that's usable without a ton of work; it'll also give me the impetus to resolve an inconsistency in accessing back-end files, which you would see currently in that WER events + match result slips do not print DCI#, while v3 events do.
The one thing which I will be thinking about is whether this modified EPIC system really needs the ability to have more than one tournament at a time in it's system. Since we're no longer worrying about databases, you could instead tell different tournaments to go to different websites, each with a back-end file. The total size of the entire system is currently under 50kb including data, so we're not talking about much in terms of movement.
I would say that the best part of this change in thought is just how long it would take to make an update now. Before, my personal builds were taking 2-3 minutes for a reasonably-sized event to update fully. (not what we're looking for in this kind of software) There is more click-labor in this method, but we're talking about:
- A menu option
- Navigating to a website
- Browsing for the exported file and entering in a short password. (just to make it slightly difficult for someone without knowledge to go in and use it)
You're looking at 15 seconds for this, 2-3 times during a round. Why 2-3? Well, remember me talking about an impetus of the 2.0 changes being the ability to make timers accessible in EPIC? Well, the second update would be re-uploading with the round clock running in order to show on EPIC when the round will end. The third update would be for standings posts at later rounds, just so the numbers get updated.
Just so you know, this stuff is all 2.1 updates at this point, but at the same time this is the first time where I see nothing actually preventing me from releasing this in-full. Although 2.1 shouldn't be out until towards the end of the year, I fully expect that by 2.1 alpha 10, the system will be functional, and all the web application files will be in the downloads for people to setup their own systems.
Update 09/14 5:00PM
The program now works with WER as well as v3 in personal testing. Still getting byes sorted out, as that is a non-issue issue turned into a bug with these upgrades. Bonus: WER match report slips have DCI numbers on them now.
Update 09/15 1:00AM
Byes are being handled mostly at this point. I had the opportunity to go through all the motions during an event tonight and make sure I could get a working system going. The huge plus here is that I can not work entirely on interface improvements from the web end. Since this setup is much more modular than a normal event, I can make the interface a little bit more customizable.
One note is that this system doesn't work with team events at all. There's a myriad of reasons for this, mostly centering around the fact that most of the code in RTools is not designed for multiplayer events. Instead of going through and truly building things in to handle multiplayer as an extension of single-player, RTools rides off of information that is already present in the places where single-player info is stored. (essentially, for a team event, the location that a single-player event stores information has the team's information in it's place) These issues are not things that I have looked into fixing in the slightest, as the amount of work needed to make all this work would need rewriting of all the hook code, which is about 2-3x the amount of code work that the 2.0 update required. (2.0 changed how data was being moved around in the program, this would require changing how that data is acquired, stored, and used, essentially changing everything that _wasn't_ changed in the 2.0 update)
9.11.2010
RTools 2.0.0 beta 3
One (probably) final beta for 2.0, with one fix and one addition.
- There's a dialog that pops up when there is less than 1 month remaining in the license term. It displayed an incorrect date for when the license would expire, and this has been fixed in this beta.
- If you looked at earlier alphas/betas in the 1.1 and 2.0 era, there have occasionally been options in the menu to split or join v3 tournaments. (i.e. what they do at huge GP tournaments) There were some issues with the implementation, and I took another shot at the split portion. It appears to be working perfectly this time, so the option is restored for this beta. I may or may not figure out the join portion by the time the full release is done.
Note that I have seen other implementations of this in program form, and this one works slightly differently. The main implementation I have seen takes a preregistration pool and splits it. This one takes a fully-setup tournament and splits it randomly, (splitting byes) creating two new tournaments files.
- There's a dialog that pops up when there is less than 1 month remaining in the license term. It displayed an incorrect date for when the license would expire, and this has been fixed in this beta.
- If you looked at earlier alphas/betas in the 1.1 and 2.0 era, there have occasionally been options in the menu to split or join v3 tournaments. (i.e. what they do at huge GP tournaments) There were some issues with the implementation, and I took another shot at the split portion. It appears to be working perfectly this time, so the option is restored for this beta. I may or may not figure out the join portion by the time the full release is done.
Note that I have seen other implementations of this in program form, and this one works slightly differently. The main implementation I have seen takes a preregistration pool and splits it. This one takes a fully-setup tournament and splits it randomly, (splitting byes) creating two new tournaments files.
9.07.2010
Update on Standings discrepencies
I spent a couple hours today looking again at the standings code, and doing some comparisons to standings produced in WER to try to figure out just where my algorithm deviates from theirs.
I was able to find an error with my side of the coding today, revolving around my interpretation of this line, from Appendix D of the MTR:
"A player’s byes are ignored when computing his or her opponents’ match-win and opponents’ game-win percentages."
I had interpreted this to mean that, when you are looking at the computing tiebreakers, if one of your opponents had a bye in a round, that 2-0 win is to not be recorded when computing that player's portion of your OMW%/OGW%. However, looking at how both v3 and WER calculate tiebreakers, they interpret this line to mean that if a player has a bye themselves, they don't count that bye as anything when calculating tiebreakers. (so that you don't need to worry what a bye's PGW% is when calculating it as part of the averages to find your OGW%)
If I change my algorithm to take this into account, everything _almost_ matches, and the things that don't I can centralize directly to errors in v3 and WER's calculations. I'm fine with this being a mistake on my part from interpretation :)
So, this gives me the opportunity to add a new dropdown to the Program Settings menu I'm currently building: "Standings calculated via: ", with the three options being "MTR", "v3", and "WER". (MTR will be default) If you have RTools set to be compatible to one of these, the standings _should_ match perfectly.
The adjustments to bring standings in alignment to the MTR will be in A18; the Program Settings menu will be around A20. (I'm changing the download site right now to bring up A17)
Update (09/07/10 8pm)
In my personal (bare-code) build, the standings now work quite well. There's a bug with printing standings through RTools, though that looks more like a remnant of the 2.0 crossover and should be a simple fix. With the fixes I will be bringing into A20 and possibly A21, I may be looking to shift to beta builds. Almost certainly before I hit A25.
I was able to find an error with my side of the coding today, revolving around my interpretation of this line, from Appendix D of the MTR:
"A player’s byes are ignored when computing his or her opponents’ match-win and opponents’ game-win percentages."
I had interpreted this to mean that, when you are looking at the computing tiebreakers, if one of your opponents had a bye in a round, that 2-0 win is to not be recorded when computing that player's portion of your OMW%/OGW%. However, looking at how both v3 and WER calculate tiebreakers, they interpret this line to mean that if a player has a bye themselves, they don't count that bye as anything when calculating tiebreakers. (so that you don't need to worry what a bye's PGW% is when calculating it as part of the averages to find your OGW%)
If I change my algorithm to take this into account, everything _almost_ matches, and the things that don't I can centralize directly to errors in v3 and WER's calculations. I'm fine with this being a mistake on my part from interpretation :)
So, this gives me the opportunity to add a new dropdown to the Program Settings menu I'm currently building: "Standings calculated via: ", with the three options being "MTR", "v3", and "WER". (MTR will be default) If you have RTools set to be compatible to one of these, the standings _should_ match perfectly.
The adjustments to bring standings in alignment to the MTR will be in A18; the Program Settings menu will be around A20. (I'm changing the download site right now to bring up A17)
Update (09/07/10 8pm)
In my personal (bare-code) build, the standings now work quite well. There's a bug with printing standings through RTools, though that looks more like a remnant of the 2.0 crossover and should be a simple fix. With the fixes I will be bringing into A20 and possibly A21, I may be looking to shift to beta builds. Almost certainly before I hit A25.
9.06.2010
RTools 2.0.0 alpha 17
The updates are being slow right now, due to some busy times as well as just taking a break after a few weeks of very quick updates.
Alpha 17's only visible change is that I found how to do anti-aliasing in Java's core GUI library and implemented it pretty much immediately, so timer/clock/ticker/pairings text should look cleaner starting with this alpha build.
There are four "projects" that are in the alpha currently:
- 2.0 Paradigm transitions
These have been completed for a while now, and just some small adjustments have been made in past weeks. One thing that does need fixing is how the timers are affected by menu options and settings changes. I'm pretty much going to go back to how I initially built the timers for 2.0, before I started getting worried about people not liking the inability to have multiple timers per tournament and trying to kludge something.
- EPIC
This is at a point where I'm just looking for the right server, then things will be in live builds quickly.
- The settings menus.
This is the main thing I'm finishing right now; most tournament settings are working right now, and I want to get a program settings menu in place as well. As part of this, I also need to change the font selection GUI to allow font sizes over 200 and just turn it into a text field. (The timer was being used at SCG Open Minneapolis, and we needed a 500pt font for that event; if I didn't have the settings menu built to a point then, I would have needed to use RT1.1)
- Notification panes on the main window for all open windows.
So, if I open a pairings window, the main window will get a little taller and give a little line of info on the pairings window. I can right-click on that area and get the same reaction as right-clicking on the pairings window, (i.e. starting the scrolling from there) and also get windowing options from the main window.
At this point, I want to finish the settings menus and finish the timer adjustments, then get 2.0 out as a full version. After that, the notification panes will probably be 2.1, and EPIC is looking to be 2.2.
Oh, and 2.0a17 will be around in the next day-ish.
Alpha 17's only visible change is that I found how to do anti-aliasing in Java's core GUI library and implemented it pretty much immediately, so timer/clock/ticker/pairings text should look cleaner starting with this alpha build.
There are four "projects" that are in the alpha currently:
- 2.0 Paradigm transitions
These have been completed for a while now, and just some small adjustments have been made in past weeks. One thing that does need fixing is how the timers are affected by menu options and settings changes. I'm pretty much going to go back to how I initially built the timers for 2.0, before I started getting worried about people not liking the inability to have multiple timers per tournament and trying to kludge something.
- EPIC
This is at a point where I'm just looking for the right server, then things will be in live builds quickly.
- The settings menus.
This is the main thing I'm finishing right now; most tournament settings are working right now, and I want to get a program settings menu in place as well. As part of this, I also need to change the font selection GUI to allow font sizes over 200 and just turn it into a text field. (The timer was being used at SCG Open Minneapolis, and we needed a 500pt font for that event; if I didn't have the settings menu built to a point then, I would have needed to use RT1.1)
- Notification panes on the main window for all open windows.
So, if I open a pairings window, the main window will get a little taller and give a little line of info on the pairings window. I can right-click on that area and get the same reaction as right-clicking on the pairings window, (i.e. starting the scrolling from there) and also get windowing options from the main window.
At this point, I want to finish the settings menus and finish the timer adjustments, then get 2.0 out as a full version. After that, the notification panes will probably be 2.1, and EPIC is looking to be 2.2.
Oh, and 2.0a17 will be around in the next day-ish.
Subscribe to:
Comments (Atom)