5 posts tagged “progress”

Naming Issues
Brian, the guy I'm going to be doing this whole startup thing with, pointed out to me that theres already a framework named Jade, for Java. My instinctual reaction was to discount it. I mean, it's JAVA, c'mon. Evil language. But once reason returned I had to concede that a new name would be needed. This means I'll have to change all the code for my framework, since all Jade classes have "Jade" as a prefix (e.g., "JadePanel"), which is a direct inspiration from the NS prefixing in OpenStep.

Progress and Preparation
Jade (or whatever .. *grumble*) is now really rather close to being ready to go into alpha testing, which Brian points out is going to require a site and all the accoutrements that go along with having a project like this. So far it seems like we'll need at LEAST info about the project, some sort of blog or forum or similar for building a community, documentation for the framework, and of course site design, server space, and a domain name. Oh boy.

Pretend file systems, URLs, and XHR
Obviously if you're gonna have apps, you're going to want to upload and use files so you need some sort of file system. Also, since it's web based, there's going to be significant use of URL manipulation and XMLHttpRequest usage. But these are all kind of the same on the web, aren't they? URL's reference files on a server, XHR allows you to perform HTTP requests for files, and a file system is just a way of handling files. So I've made the decision to collapse functionality into a single URL class that will let you perform URL manipulation and XHR interactions with the server seamlessly.

Quick status update:

Total classes currently in the Jade framework: 83.
Total classes completely finished: 42.

That means that atleast 51% of the framework is completely finished. Not counting the mostly finished and partially finished classes.

This is a wonderful milestone. :)

So JavaScript's this Object Oriented language without classes, as such. Well, in a way it does have classes, because you can use constructor functions that end up behaving like class definitions:



function MyClass(){
    var foo = 5;   // private variable
    this.bar = -1;   // public variable
}

Which is very nice and efficient and I think much better than working with prototypes, which end up creating only public variables, and no unique objects for properties:



function MyClass(){ ... }
MyClass.prototype.foo = 5;
MyClass.prototype.bar = {};   // all instances reference this same object! bad bad bad


But how do you inherit the private variables? Well it turns out that it's very easy. JavaScript provides you with the ability to call one function in the context of a specific object, so that the "this" keyword refers to that object. You do it with the "apply()" method of functions. So you can have two constructors, one which calls apply on the other, and you get inherited private variables:



function MyClass(){
    var foo = 5;
    this.getFoo = function(){ return foo; }
}

function OtherClass(){
    MyClass.apply(this);
}

var o = new OtherClass;
alert( o.getFoo() );   // alerts 5

Now I have to go back and recode everything to take advantage of this. My task:

Turn this:



...
this.property = someValue;
...

into this:



...
var property = someValue;
...
this.property = function(){ return property; }
...

A few thousand lines of code, that's all... It will be fun, I'm sure...

Today I demoed my almost-completed scroll view class to a friend. He immediately discovered a glitch that I hadn't seen. When you moused down on the scrollers anywhere other than the scroller knob, and then moused up outside of the scroller, weird things would happen. Doing this to one of the line buttons (increment or decrement line) would start the autoscrolling feature that should only occur when you maintain a mouse down over the button for a period of time. When you did this over one of the page regions (increment or decrement page), the scroller would seem to do the page down or page up but then get stuck and flicker and do other weird stuff. And when you made the scroller knob proportion small enough, the same autoscroll behavior emerged from the stickiness and flickering from clicking on the page regions.

Well I investigated this phenomena, wondering what I did wrong. What happened was this: When you moused down on the scroller, if you moused down on the knob, the scroller informed the application that all mouse events needed to be directed to the scroller. But this wasn't true when you moused down outside the scroller knob, so if you were to mouse down on the line down button, and then mouse up outside of the scroller, the scroller never got the mouse up. It still thought you were mousing down. Well this was simple to fix, just change it so that the scroller always received the mouse events, regardless of whether you clicked the scroll knob itself or anywhere else.

 Ah sweet bliss, I'm thinking. How lovely it is that the solution was so simple! But alas, I created another minor problem: when you moused down on anything other than the knob, and then dragged the mouse around, weird stuff happened! All sorts of flickering and junk. And the scroller didn't scroll up or down a line or page like it should have. Hmm, where could this come from? Well ofcourse the origin wasn't hard to find: because the scroller was receiving all mouse events at all times during a mouse down, it was getting sent mouse drag events even when the line up and down buttons (and page up and down regions) were clicked and then dragged. This normally would drag the scroller knob, so the scroller was drying to drag the scroller knob around even though you never clicked on it. Solution? Don't do anything during a mouse drag unless the scroller knob was clicked.

The moral of the story? Little things can have big impacts. And sometimes solving little problems creates other little problems that weren't there before the solution. Think ahead, and pay attention to the effect that your design decisions will have. It's better to know before hand the consequences of your decisions because you've mapped every possibility out, rather than try to discover them later by trial and error because you weren't looking hard enough when you wrote the code.

Ahh, the smell of a new blog. So fresh, so clean. I figured it was about time I created a blog for the Jade project, so here it is. Hoorah! In this inaugural post I think I should bring all zero of you dear readers up to date on the progress of the Jade framework as well as my super secret plans. But first, an introduction to the idea behind Jade.

So uh.. what is it? Well the idea is simple. There are lots of neat web apps out there such as the Yahoo! mail beta and the new .Mac mail, or Google Maps and Docs & Spreadsheets, and all of them utilize some rather advanced, non-webpage-like UI features. In the case of both mail apps, there's your standard drag and drop of items in tables, split panes, buttons, etc. In Google Maps theres a draggable view of the earth, some sliders, etc., and in Docs & Spreadsheets theres text formatting as well as editable text fields in a grid.

All of these are really rather beyond the scope of a traditional website – they push well into the realm of an offline app, the kind you'd install and such. And everyone who coded these sites, Yahoo!, Apple, Writely (for the documents portion of Google Docs & Spreadsheets), and Google, had to recreate a number of standard UI features that any good non-webbased API has. The idea behind Jade is to provide a framework that already has all of these UI features built in by default. I've opted to build it based on the OpenStep API, deviating where sensible.

Jade, by itself, is the framework. Alongside this framework I'll also be creating two applications. The first will be an application that lets you create other applications. A sort of IDE for using the Jade framework. It'll be based of the Xcode/InterfaceBuilder applications, but fused together into a single app to take care of the differences in programming environment. The second app will be a website design app that lets you build an entire website graphically. Not just the visual design, but also dynamic, database-driven content, will be able to be created with simple drag and drop techniques.

Or so that's the plan! But how far along is it? Well it's quite far, actually. I've been building it up piecemeal, starting with the Foundation Kit, containing all the essential non-GUI related classes. That's pretty much finished, so now I'm working on the Application Kit, containing all of the stuff you deal with in a proper GUI app, which mostly amounts to the stuff you see on the screen. For a lot of things I've opted to go completely ground-up, despite there being browser-native versions. For instance, scrollable content will exist in scrollable views drawn entirely by the AppKit, and not a single browser-native scroller will be seen. Same for pop up / drop down menus.

The reason for doing everything ground up is two fold. First, I want visual consistency. The visuals of the framework will be important to the Jade brand, and l want to maintain the look and feel throughout, instead of having off-brand UI elements. Second, certain features of the UI require behavior that isn't possible given native UI elements. For example, custom scrolling a view to a specific place is difficult, maybe even impossible, to do in a scrollable div. There are also some other reasons, like being able to control the behavior of the UI elements to greater extent.

As of right now, the majority of UI widgets remain unfinished. Effectively done are split views, progress indicators, steppers, scrollers, and sliders. Still to go are panels (Jade equivalents of windows), clip views, scroll views, tab views, ruler, table headers, tables and outlines, menus, boxes (titled containers), browsers (the horizontally "nested" tree viewers), image views, date pickers, segmented controls, buttons (including pop up buttons), and text fields (including search fields and combo boxes). Of those, panels, rulers, boxes, and image views are partially tho not mostly done. Some of them will be easy, once others are done. For instance, doing the scroll view class will be a snap, since its just a clip view and scrollers and rulers tied together. Boxes are just well.. boxes with text for the title. Tab views are just boxes with segmented controls.

That's enough of the wall of text status report. What about the good stuff? Well once this is all finished, I'm going to release the Jade framework, and the associated apps, as free software under the GPL, along with full instruction books and enhanced screencasts. I'm also going to run a site that lets people create their own websites using the site builder app, and also will host web apps designed with a preinstalled copy of the app builder. To generate word of mouth before the official launch I'm going to make stripped down versions of the screen casts to leak onto the web before the official release, to get people wondering what this thing is and how does it work.

My highly tentative and undoubtedly impossible launch date is this upcoming Christmas, sort of a gift to the world, but thats probably not possible. We'll see. It will be fun!