WELD AE

I haven't had much to write about for the previous month not because Weld isn't progressing nicely, but because I'm mainly fixing lots of small issues to polish changes. There have been one or two new features, mainly on the less talked about the Application Engine side of WeldAE.

The big new change is that instead of events calling entire scripts, they now call specific functions inside one master form script. Each Weld form will have a script assigned to it. This script will be a group of functions that an event will call. This will greatly cut down on the number of scripts each form will have and is very similar to how forms work in VB..

I've already got this working just fine but currently have no namespacing for the functions. This is a problem when many forms are open since the chance that two functions on two separate forms being named the same goes up dramatically. I have several solutions to this problem, the favored one is to make the group of functions extend the form class into a new class named from the form scriptid. The only problem with this method is that involves dynamically including the extended class definitions before I unseralize my session state. This is a problem since currently I don't know which classes to dynamically include until I unseralize my session state. I'll probably hack something quick to get around this problem by writing out a file of classes to include at the termination of every transaction. This is, in my mind, another reason to start storing the session string in a DB so I can attach metadata along with it.

All this really underscores that the Weld client is pretty feature complete as is and the server side code is the bit that needs some work. I wrote most of the server code several years ago and it has done an amazing job of keeping up with client side changes with almost no changes. However, now that I understand what the client needs and doesn't need to do its job its time to make some decisions on the final structure of the server side. The biggest change being I am going to require a DB. I really don't want to require it, but I'm leaning that direction if for no other reason than reducing the scope and complexity. I do believe it will be possible to go back later and abstract out the DB code enough to allow the server to operate without a DB, but trying to do both at the same time will just take too much time and I want to get a released shipped sooner rather than later.

Ok, maybe a little slowdown here and there:

Ok, so I am having trouble with a couple of things. On the Windows side, .Net is a big step up from the VB6 version, allowing for a cleaner implementation of dynamic controls and events. However, it appears to be almost impossible to implement dynamic events that reference data other than the object that raised the event without much class back flipping. Because I'm trying to keep my C and .Net code base as close as possible, I'm reluctant to go the class route since once I do that it tends to pull the rest of the code with it. I'm currently looking into extending the control class for each control type with the event handlers needed for that control type. This should allow me to reference my control data structures inside the event to do what I need. Another option are to pass the data structure in via an argument, but this seems very hard. Finally, I'm also looking into a custom control property to store a reference to the control data structure.

The other issue I'm having is a very obscure segfault with the GTK client. I've spent about 12 hours trying to track this down and I think it isn't a problem with the client but with the XML parser or the data I'm getting from the server. It only happens in one place where I'm doing some pretty advanced data transformations server side to load forms inside forms. Hopefully I'll get this figured out soon as its currently holding everything else up since I take any segfault seriously.

Been a bit since I posted an update, but not because progress has been slow, the exact opposite in fact.

The last two weeks I have mainly been focused on adding property bindings to Weld. I've never seen anything like this in any other development platform I've ever used, so I was a little nervous about implementing it. I was very worried that I would put a lot of time into it and find out its impossible, a bad idea or both. I'm pleased to say that not only was it not a bad idea, but probably the best idea I've had yet.

Ok, so what exactly is a Property Binding? Imagine you have a text control on a form that you want to expand in width as the form width change. Normally you would put an event on form.resize to calculate the new control width and set it. This wasn't hard, but involved several pieces and was a bit cumbersome, especially when doing this for dozens of controls. Now with property bindings all you have to do is control.width = "{PARENT.width}" and Weld will take care of the rest. If you want some padding between the control and the parent, just do something like control.width = "{PARENT.width} - {.left} - {.left}". This binding will center the control on the parent and use the controls left padding to determine the right padding.

Property Binding isn't just for sizing controls, but has a wide range of applications. Imagine a list of radio buttons with options underneath. Each set of options should only be enabled if its parent radio button is checked. See the below diagram. The name of the controls are in bold.

• Don't default Value - (chkDont)
• Default Value from description - (chkDescription)
• Proper Case Value - (chkProper)
• Transform underscores to spaced - (chkUnderscores)
• Always Default to this Value - (chkAlways)
• Test - (txtDefault)

With property bindings you can just bind the enabled property of each sub item to the parent items text field which is either True or False like so:

chkProper.enabled = "{chkDont.text}"
chkUnderscores.enabled = "{chkDont.text}"
chkDefault.enabled = "{chkAlways.text}"

As the user chooses one of the main radio options, the sub options will disable and enable automatically. This happens because when a radio button is selected, its text property is set to "True" and when not selected it is set to "False". The enabled property also takes "True" or "False" so binding these two properties together makes perfect sense. Using property bindings is very easy and much less work than creating scripts to do the same thing. About 90% of the current scripts in the example Weld forms can be replaced with simple property bindings.

Another slow week for Weld progress. VB.net is crazy slow when building the screen. The GTK client builds the screen instantly even on a very slow computer, but the VB.Net client takes ~5 seconds on my 2ghz development machine. Its even worse on my 366mhz/196mb laptop. I need to look at freezing the screen updates while adding/moving controls and that should help a lot.

Watched the Novel Brain share video and saw some cool demos of .Net applications running natively under Windows. Tried it out on some simple apps and it worked perfect. Didn't work with the Weld .Net client because of the Curl DLLs I'm using for network communication. Need to look at trying the native .Net functions for the HTTP communication. I'm using the curl libs for two reasons. One, when I did the prototype two years ago the native libraries were horribly slow. Two, using the curl libs keeps the code closer to the GTK code. Despite these two good reasons, I'd like to at least give the native functions another try.

Last week was slow for Weld development because of a trip and other events. I did however manage to add a tooltips property to all the current Weld controls.

Late Sunday night I started working on the Win32 Weld Client written in VB.Net. Most of my time Sunday was spent installing VB.Net SP1, which is a monster. Despite that I've made very good progress and hope to have a functional version by next Monday. I've only got about ten hours invested so far and the basic rendering is already working although only the button and textbox controls are working so far. Take a look at the screenshots for more details.

I finally added the new documentation tables to the public web site today. This table is automatically populated by the Weld client so its pretty easy to keep the information updated as I add new properties and controls to Weld. As you can see, there are still three controls not implemented yet, but the rest of the controls are in pretty good shape. Ignore the "Form" control for now, I haven't done the code to automatically pull form properties yet.

Of course, there are dozens of properties to add to this list, but this is a good set of core properties needed to implement the forms I'm working on so far. I'm really trying to focus on building a good demo application with Weld at this point and not adding support for the missing properties listed or adding new properties. Only if I need to fix or add properties to accomplish a form I'm working on will I do so. I'd like nothing better than to spend a week carefully supporting each property listed, its the kind of person I am, but I know I need to forge ahead and build something with Weld at this point.

The great code reorg is done. The final tally is just 6K lines of code and the binary weighs in at 107K. I need to run through the AE lib code and do some light cleaning, but that can wait since that section of code is pretty stable and hasn't changed much in a while. The GTK code had to undergo a cleanup to make moving forward possible, so I'm glad its done.

Its been too long since my last post so I have entirely too much to talk about. To give you an idea about how much has been done in the last week or so, here are some stats. Last time I posted, the Weld client weighed in at 4500 lines of code and the binary was 83K. As of today, Weld is 6000 lines of code and 104K. What makes these numbers more impressive is that most of the week was spent cleaning up the code and working on documentation. Of course, this is a horrible metric of how work is progressing on a project, but its the only metric I have to offer until I get the code on-line.

What does the extra 1500 lines of code do? Well, some of the new lines are because of the code reorg I talked about last week. However, I did add the memo control and the timer controls to the list of working Weld controls. This only leaves four controls that need to be finished (Tree, RadioButton, ProgressBar and DateTime). The RadioButton control should be easy, but the other three will take some time to get working and will probably be put off for a while. DateTime will probably get implemented after the Radiobutton since after looking at the Win32 equivalent controls I've decided they are both horrible. I had expected to have to do a lot of work to get the GTK control up to speed with the Win32, but looks like Weld will just have a weak DateTime control until either toolkits do something about the quality of this control.

Most of the time this week has been spent adding a 3rd control called "Discovery". This is a fake control that is used by the server to retrieve all the non-custom properties used by the client. Using this information I built a Weld form that will automatically build the entire Control Reference screen. This means that the documentation will always be up to date and perfectly accurate. The database behind the Control Reference screen will track GTK and Win32 versions of the client separately. So for any given control/property pair listed on the screen it will be easy to tell if the control supports that property and if so, does the GTK or Win32 client support it yet.

This will allow me to flesh out the property list with properties I plan to support in the future and the "Supported" indicator will automatically be updated as each client gains support for that property. Currently I haven't moved the new Control Reference page public yet, but look for it by this weekend when I should be done with the code reorg.

This weekend I only added a couple of minor new features to Weld. I spent half the weekend fixing small bugs that kept the existing forms from looking as polished as they should. The other half of the time was spent making Weld larger by rearranging the code base.

Let me explain a bit more. The Weld client is my first C application and my first time to use GTK. Now that I've had a chance to become familiar with them, I can say I love C and GTK is extremely well written. GTK is so well written that its very possible to deal with a vast number of controls and widgets using the same code. However, because of the amount of control Weld give the end user, it turns out a lot of cruft has to happen to make one piece of code set the control width for a couple of dozen controls.

Rather than continue to if{}else{} my way into oblivion, I decided to break each control into its own file and header and code each property for each control separately instead of trying to force each control into one mold. This will result in the Weld binary growing from its current 79K to about 120K with no net gain other than the code will be much more readable and maintainable.

I've still got a lot more work to finish this change over to the new code layout, but I should be finished this week. I've alrady implemented a new control using this new layout so the hard part is done. The new control is the memo control for editing large amounts of text. I'll have screen shots of it up sometime this week hopefully.

Because I only provide a compiled version of Weld for a limited number of Linux distros, I have created a flash movie of Weld in action. It was recorded at 1024x768 and is about 9mb. The movie shows the new open form screen as well as how well the form resize events work despite the control layout being absolute. You also get to see the new debug XML windows at work. I quickly show how changing the event scripts on the server side automatically happens client side without restarting Weld. Last, I show how easy it is to create a blank form.

Added the ability to display the XML that is going back and forth to the server on the fly. This looks very cool when the events are running, so you can't fully appreciate it with just a screenshot. Version 0.2 should be out shortly to play with and see how nice the form resizing is as well as the XML debug output. You bring up the XML debug window with F8 and from the on the XML is updated in realtime. If you click F8 again, a new XML output window will appear and all new XML updates will display in this new window. The previous window will retain its content so you can compare XML output as you change the server side code.

I've mainly been working on the new Open Form screen shown in the screenshot linked above. The event system is really being put to the test when resizing this screen as all the controls move around to fully fill the avaliable window. The Application combobox onChange event is the first useful server side event I've done and only the 2nd one ever. I'm happy to say that it worked flawlessly the first time which is amazing considering how complex the event is. It really gives me confidence that the event code is rock solid and can handle anything.

So many changes went into Weld this week, I'm having a hard time keeping up with the documentation. To solve that problem I have decided to move the documentation into a database make it easier to manage. I don't like putting documentation into a database, but Weld is a special case. The form designer will need access to the documentation so it can give the user detailed information about controls and properties. Because the documentation is in a database, when a user types F1 while on a button control, the full documentation can be displayed. Currently there is only enough information entered to build the form designer property screen, but I hope to soon have enough information to build the Control Reference screen directly from the database.

Menus - Each Weld form can now have its own set of menus. These menus can have sub-menus as deep as you want and can have as many main menu off the menu bar as you can fit. I haven't decided if I'm going to allow image icons beside the menu items. I'm leaning to not allowing it because of the speed impact downloading dozens of icons would cause. Maybe I'll revisit the issue when I have a file caching system in place.

Scroll Bars - Each Weld form window can now be sized smaller than what is needed to display all its controls. Previouslly the minimum window size was limited by the controls on the form. Now when the window is reduced, scrollbars will appear to allow you to see the hidden parts of the form. I had to do this in order to keep the form designer Property Form to a resonable size.

Background Images - And now for a bit of fluff. This is a feature that I hope no one will ever use. I needed it for the form designer, but its not a good idea to use the feature unless your very sure it helps your application function better. I'm talking about form background images. It took me about 14 hours to get this working and I never would have without some help from a couple of helpful persons on the GTK App Devel list.

Tab controls are now supported. Weld has gotten to the point where I need a quicker way to create and modify forms. To this end, I've started working on a form designer. I quickly realized I was going to need a tab control for my property screen. Even though I trying to concentrate on developing the designer, I felt it was worth taking the time out to add this control. It was a bit complex since its a compound control made of several controls and also acts as a container, but I am happy with how it works. Check out the Screen Shot.

I've uploaded the first public release of the Weld client. This is a very rough version, but I wanted to get it out there so it is easier to grasp what Weld AE is all about. The client defaults to the demo server with a valid username/password so all you need to do is run the client and click "Login" to get started. The default form is a list of all forms available on the server. Most of the screens are testing screens for the various controls. The only control that makes a round trip to the server is the Button test form. When you click the button it requests a script to run on the server and sends the form updates back to the client. In this case, it just changes the size of the button control, but it could be anything from calculating your taxes to pulling data from a database.

Update: There is now a native Fedora Core 3 build

Please email me if you have problems running the demo or have any suggestions or feedback.

By far the one of the most complex controls the Weld client will support has been implemented. The Grid is actually a composite control of at least 3 controls. One control for the main grid, one for the actual data and one control for each displayed column. All the remaining controls not done yet should be a piece of cake compared to the Grid. The tree is technically more complex, but the work I've done on the Grid means I'm most of the way there. Be sure to check out the Screenshot.

Controls working:

• Button - 99% complete
• Checkbox - 99% complete
• Comboox - 50% complete. This is the weakest GTK control right now being new in GTK 2.4 so its an uphill battle.
• Data - 90% complete. I'm planning on using this control for caching data client side so there are some more features I want to add.
• Form - 90% complete. Mainly some simple events need to be added.
• Frame - 99% complete.
• Grid - 10% complete. I don't have any events yet and there are a million features to add.
• Grid Column 90% complete. Mainly adding the ability to style columns and individual data rows.
• Image - 95% complete. Need to add image caching.
• Label - 99% complete.
• Spin Button - 80% complete. Mainly need to create a full test screen so I know I have evrything working correctly.
• Text Edit - 20% complete. This control is the workhourse so I have lots of ideas for it. Despite being listed as only 20% complete, its pretty functional as is.
• Update: - Tab Panel - 50% complete. No events and very little control over the style. What is complete is more than enough for most needs.

Controls still absent:

• Date/Time - This one is difficulat to do well.
• Memo - Should be easy to get a simple version working, but advanced features will take a bit.
• Progress Bar - The control is easy, but using it to show the progress of a server side event is still an unknown.
• Radio Button - Should be very easy.
• Slider - Another easy one, just not used much so it will be one of the last.
• Timer - Should be easy to gt working, but can cause a lot of havoc so needs to be thought out.
• Tree - Very complex. Probably the last control to be implemented.

I'm trying to add documentation as I implement features in the client and server, but its progressing at such a fast rate, I'll be behind for quite a while until development slows down. I plan on splitting up each control property into its own page and adding the ability for user comments. Of course, I can't have users until I release the server code, so I probably won't add that feature until after the alpha server code is released.

Ok, after working on Weld AE for over 2 years, its time to get a site going for documentation and an eventual releases.