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


New user profile


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!

Rewriting the Spreadsheet Interface

I have begin rewriting the spreadsheet interface. It is very nice to look at some of the old code and say “what the hell is this, that’s stupid” and then make it better. I can only imagine that in the next time I do it I will be looking at the code I am writing now and say the same thing. But sometimes that is just what needs to happen, throw out all the old code and start again from scratch (or almost scratch). After learning about the two statements “loose coupling and high cohesion” I find that loose coupling, making each function not rely on global variables or non argument states and splitting up functions, is much more important when you go back to try to re-factor the code.


– Asher Glick

Beginnings of the XML Menu and Menu API

A few weeks ago I set out to figure out the best way to create menus in our applications that were easy to use. At first the results were pretty bad. The menus would stack or they would not now up at all. Once I believe i even got one to pertinently stick to the middle of the screen. But now the menus are working quite well. The first alpha of the menu system is what I would call it. It is very simple to use as well. All of this information will be in the wiki as well. Individual menus for each application can be created via XML and different cross application styles can be created using CSS.

Alpha Build of XML Menu

Including the menu in your code

<script type="text/javascript" src="menu.js"></script>
<div id="TitleMenu"></div>

Include the javascript file and then put the menu div where ever you want the main title bar to go. Usually it is put first thing in the body. In later version you will be able to put the menus (or other menus) on the left and right sides of the screen
Creating the menu (in xml):

  <menu name="File" iconsrc="icons/action_forward.gif" version="normal">
    <button name="save" function="save()" enabled="true" iconsrc="icons/action_save.gif" shortcutKey="Ctrl+S" version="normal"> </button>
    <button name="load" function="load()" enabled="true" iconsrc="icons/action_back.gif" shortcutKey="Ctrl+L" version="normal"> </button>
    <menu name="Feature Select" iconsrc="icons/action_go.gif" version="normal">
      <button name="Feature One"   function="alert('one')"   iconsrc="icons/flag_blue.gif" shortcutKey="Shft+Ctrl+1" version="normal"> </button>
      <button name="Feature Two"   function="feature('two')"   iconsrc="icons/flag_green.gif" shortcutKey="Shft+Ctrl+2" version="normal"> </button>
      <button name="Feature Three" function="feature('three')" iconsrc="icons/flag_orange.gif" shortcutKey="Shft+Ctrl+3" version="normal"> </button>
      <button name="Feature Four"  function="feature('four')"  iconsrc="icons/flag_red.gif" shortcutKey="Shft+Ctrl+4" version="normal"> </button>
      <button name="Feature Five"  function="feature('five')"  iconsrc="icons/flag_white.gif" shortcutKey="Shft+Ctrl+5" version="normal"> </button>
  <menu name="Edit" iconsrc="" version="normal">
    <button name="copy" function="copy()" iconsrc="icons/copy.gif" shortcutKey="Ctrl+S" version="normal"> </button>

the XMLMenu element is the wrapper for the XML menu
The three elements, menu, button, and break, all create different menu elements. If you nest elements inside of a menu element then they will show up as a sub menu. If you try to nest them in any other element (break or button) then they will be ignored. Every menu or button has a name and an image icon associated with them. Buttons have a function to run if they are clicked and all attributes have a version. The version does not do anything right now but in the future it will indicate advanced features of the menu system. XML above is the XML used to create the menu in the screen shot.

Allowed Users and UGRS

Today Asher and I submitted our abstract for Briefcase to the undergrad research symposium. Not much else to say about that 🙂

We also worked on getting allowed_users working. I added a many to many relationship field to the Spreadsheet database model that links with the UserProfile model. Asher changed it so that the owner username and the file primary key can be sent through the url. Now not only can you view a spreadsheet if you are the owner, you can also view someone else’s spreadsheet if you are logged into an account that is in the allowed users list for that file.