Meta Javascript

As my work on briefcase revs back up I wanted to figure out how to solve a problem that I ran into with multiple libraries.
The problem is with the ‘onload’ variable
JQuery does a nice job handling this by creating a new function, they even changed the way it works to their own custom implementation that only waits for the html to load not the pictures and ads. However this is not what I was after. I wanted a method that would be able to take two pieces of code that both had onload commands, for example a menu library and the actual application.  After a little bit of research i stumbled upon a function call defineProperty(). Using this function I was able to create the code below.

<pre>
onload = function () {alert("Not Loaded")};
onload = function () {alert("Loaded")};

// You probably dont want to have two onloads being set
window._onload = [];
window._onload.push(window.onload);
window.onload=function(){for(a in _onload) {_onload[a]()}}
Object.defineProperty(window,"onload",{get:function()){return this._onload},set:function(n){this._onload.push(n);}});

// Lets add a few more onloads to test the process
onload = function () {alert("Loaded2")};
onload = function () {alert("Loaded3")};

below This code has four onload functions being created. The first two onload calls are present before the code begins handling the onload commands, the second two appear after.

The very first onload statement will get overwritten by the second, however the third and fourth statements will all get run along with the first

New Interest in our Project

A few people have talked to me about joining our project, however we are still focusing on developing the API for building and using the briefcase interface. However there are some key tasks that need to be acomplished in order to get Briefcase fully off the ground. As a result I will be creating two groups to work on Briefcase. The first group is Briefcase – Core. We will be working on the core API and functionality of Briefcase including the menu system, Django server, the user input configurations, along with the spreadsheet and code editor applications. The second team will be the Briefcase – Dev team. They will be in charge of integrating Briefcase with Apache and other webservers, creating a front facing web site with helpful info about how to use and install Briefcase (the github wiki is just not cutting it anymore), and help run tests on Briefcase-Core. I hope to be able to get a few younger students to help out with this as a good way to introduce them to RCOS and a good way to get code written for the project.

– Asher

Lack of recent work and multi user editing

The amount of work that has been put into briefcase of late has been very minimal. And I would personally like to apologize to those who want this project to be further developed. However, Now that my current life’s issues have been worked out I will be putting in more hours of the day to this project. I will begin by laying out a schedule for what will happen in the future.

The two applications that I would like to have completed first are the spread sheed and the coding document. However before either of those will continue I will first finish the multi user editing. For the most part this will be a very simple task, merely sending organized data to each of the clients. However, for applications like the code document and other general text editors, you also have to do some error checking on the location of the inputed characters. This is what I believe will be the most challenging part of the project. I hope I know enough django to solve this problem.

Previous work on Briefcase

In the past few weeks there is not much that has happened to Briefcase. In addition to moving into a new home, I have been working on a few other projects that needed attention. Now they have reached a semi-stable state and I have new motivation to work on Briefcase. My current work will be on the Code Editor. Originally I had planned to use the LDT highlighter ( https://github.com/kueblc/LDT ) however while using it i realized that it does not have all of the features that I want to have in the code editor. As a result I have begun making more modifications to the LDT, hopefully we will see the core features implemented soon.

– Asher

Moving to a new home

Last week I moved into a new apartment, when I got there the place was a mess and I have been spending the last week and a half cleaning it up. Though it is not perfectly clean, I now have a bed to sleep on and a desk to do work at. Not to mention I just got a new computer as well. A nice practical computer with two monitors, a nice graphics cards, a good processor, a solid state drive for the operating system, and plenty of ram. Aside from the heat I believe I will be quite comfortable coding here for many days. I cant wait to get back to working on Briefcase.

– Asher

 

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

Code Documentation

Documenting code is important. Documenting code is not just commenting code, but also writing pages on how to use your code. Recently I have seen some rookies do things in there documentation similar to:

If you are a user then ask your system admin to set up the server / configuration files

Then never in their documentation include any information for the system admin on how to do so. This kind of documentation is not helpful, you need to have a walk through for each part of the set-up and each part of the usage. Another thing that I have seen recently with projects that include a library or framework is that a link to the installation page for that library is included as the primary source of information about how to install the library that their software depends on.  If you use a library or framework like that then you should try to include a brief summary with a list of instructions on how to install the library or framework under standard circumstances. Then include a link to the external installation page as a backup in case the user needs more information in order to install the package.

While the github wiki is great for documentation it can sometimes be hard to figure out a way to properly display all the information you would like, especially if there is a different way to install the program depending on what operating system you are on. For Briefcase I would like to create a website that has this documentation. A live Briefcase server will also be up and running soon that will allow people to register and test out Briefcase. This will be separate from the dev server that has been running for the past few months, and hopefully more stable.

In other news if anyone is good a graphics design we would love to have you on the project, my claim to fame for graphics design is being able to make the corners curvy and some little photoshop stuff.

– Asher

Gone for a While

I am out of the country for a while, forgot to mention it. I probably will not do much work until I get back to the states. Maybe I will, maybe Ill die on one of the hikes and never work on it again… I hope not though. See ya in a week (whoever you are).

– Asher

Simple Graphical Updates

While we have been developing briefcase one of the goals is for it to look good. Recently I finished what I believe to be a good first version of how briefcase will look. Maybe even in the future we will have people creating their own version of the layout.

– Asher Glick

 

Beginning the summer

The summer is coming along nicely so far. We have accomplished many things with the server back end including a standard way of passing messages between the server and the client, renaming files, deleting files, and making the user profile and login screen look nicer. There are still a few outstanding bugs (some of which are quite important) that need to be fixed before it becomes completely usable. We also improved the documentation on setting up the Django backend so that developers can set up the Briefcase environment in minutes without having to crawl through pages of documentation on the Django or python sites. A menu system with the ability to handle shortcut keys (as well as a stand alone shortcut key library) is my next goal for the project and will hopefully be done this weekend.