Begining the multiple user editing

Today we finished the proof of concept for the multiple user editing. When users make an action their action is sent to the server and the server stores the data in an array of changes to send to all the other connected users. Currently only one instance of a document can be opened by any one user or the data will be split between the two browser windows. Soon in the future this will change. I am truly exited for when this features is completed.

– Asher

More Upgrades

With the addition of a whole new back end structure I went forward with recreating the front end a little bit. Aside from a few bugs that exist in the spreadsheet application we now have a new login and user profile page. It is almost the same as the old one but is a bit shinier. The shadows and background moves in response to your mouse to give it some 3D looking effect, not sure if that is going to stay or not though. Jerry Schneider is working on redoing the code editor and got some work done at the hackathon but has not pushed his code yet because of some integration issues with the code editor and the new backed. Hopefully when that is done we will see some of his awesome work.

New Login Screen

Image

New user profile

Image

Changing the Spreadsheet rendering method

The current rendering method for the spreadsheet is the HTML5 canvas. Which works remarkably well. However it has two drawbacks that I have run into so far. The first is that it renders raster images, which means that if you zoom in to the page, the input text and menu bar scale fine but the spreadsheet gets very pixelated. The other is speed. Everything drawn onto the canvas is done in javascript which is inherently slow. Due to me not knowing enough about how the HTML5 canvas drawing functions work, I have no doubt that I am causing multiple redrawings to occur each time I want to change the canvas contents. While the canvas version of the spreadsheet will not be going away the focus will shift for the time being onto a native rendering environment. The WYSIWYG editor is still planned to use the canvas, hopefully by the time that begins development we will be better at writing efficient canvas drawing functions.

– Asher

Multiple Cell Selection

After a while we now have a functional multi-cell selection working! Though at the moment of writing the functionality for manipulating those cells is not yet implemented I do hope that they will be soon. Once the ability to manipulate multiple cell groups is complete I will begin again at tackling the problem of the code editor and how to make it faster.
Multiple Cell Selection Screeshot
Beth is currently working on getting the back-end to handle the live view for multiple users. There are also some problems with database migration that cause the database to be deleted every so often. Once that bug is fixed we will have a public server that people can access in order to test out our software. I also hope to roll out a few new application ideas before too long for interested parties to begin work on if they want to help contribute.

– Asher Glick

New keyboard shortcuts for the spreadsheet

The spreadsheet application can now handle the tab key being used to progress to the next cell to the right. the enter key will select the next cell below the one you were at before you started tabbing. Finally the arrow keys can be used to manipulate the selected cell. There is still one bug with this new feature set, the Keyboard bindings allow for cells to be edited off screen. Hopefully that will be fixed soon, I do not believe it to be a large bug but it is late and I will fix it Tomorrow.

– Asher

Bad code and little documentation

In the past few weeks I have begun writing two new applications for Briefcase: Code editor, and Presentation Editor. The code editor is based off of the LDT syntax highlighter and the presentation editor is meant for use with the BIG presentation system. As I have been rapidly coding there is little to no documentation for these applications and the code base for them is quite horrendous. But that is ok. Why is it ok to have horrendous code? For research, just messing with code to figure out how it works. However, looking back on it I see that it is quite bad. I also tried to see how the LDT would work with a content editable DIV tag. It works, but there are many problems with it. So I am now going to begin working with ranges within text areas in order to implement adding and removing selected text within a text area. If I am able to do that then the entire code editor will be created using a slight derivation of the LDT. The documentation for Briefcase need to be improved quite a bit before I can consider the program even remotely ready for a release.

Progress on the spreadsheet refactor

Progress has been going well. Many of the bugs that were plaguing the program have been removed and overall the spreadsheet looks nicer. The whole thing is still a bit gray but that is ok for now. Not all of the features have be re-implemented but the ones that have are done much better then last time. The spreadsheed has been tested with 5,000,000 datapoints (five million) and it was able to render at a fast enough speed to consider easily usable. the problem will be when those datapoints are all functions and twice the amount of data will need to be stored or more processor time will be used. Ill write more about it later but for now I will leave you with a screen shot!