13/8/2008
Well I've finally settled on a solution to the translation of scripting menu commands. The new scripting support in Scribe v2 uses the new bytecode VM and I've extended the API to include a wrapper around LgiLoadString which is what Scribe uses natively to load strings from the lr8 resource file. So the script can use that to load it's translated name straight from the source. However that doesn't get it on a menu. So the new scripting engine runs each script in "./Scripts" on startup and the main function of each script calls "AddToolsMenuItem" which is a new function that registers a callback connected to a menu item in the tools menu. i.e.

AddToolsMenuItem(LoadString(IDS_REMOVE_DUPES), "DeleteDuplicateMessages");

So you can see that the text of the menu will be translated and the 2nd parameter to that function is the name of the callback method to call when the user clicks the menu item. All in all it's very neat. There is another tricky part in the define "IDS_REMOVE_DUPES" is in a C header file. So originally I just copied the integer value that it mapped to as a literal into the script file. But I decided that it would break too easily and so I made the script engine cope with C style #include and #define so that I can just include the resource defines straight into the script and then use the actual name of the string.

Neat.

Previously, Previously.

8/8/2008
I'm seriously considering deleting the whole plugin feature from v2.x of Scribe and replacing it completely with the scripting engine. For the most part the plugins are fragile because of their dependency on C++ ABI's not changing. Also they tend to be a little bit of glue between the application and some 3rd party tool or library. This should ideally be handled by a script so that the ABI dependency goes away and the functionality is "open source" allowing the user to tweak it to their own preferences.

This will mean that the scripting language will have to support calling into the operating system and shared libraries (DLL's). I think I can make the basic part of that work ok. I'm a lil worried about more complex types not being represented in the scripting language. Currently it's limited to a range of basic types, string, int, list etc governed by the types support by the Lgi GVariant class. Maybe it needs to a custom data type, and I have some idea on how that might work.

But at this stage I'm working on making the script engine cope with registering hooks and callbacks so that it can take over the functionality of the existing plugins. See how far I get.

28/7/2008
I've been inspired to clean out some cruft for Scribe v2 so that the UI and design is clean and easy to understand. The things that are going to be cut so far are:

• The "default" identity. Currently InScribe has a default identity that is carried over from i.Scribe so to speak. This tends to confuse people a lot. So I'm removing it and going with just the identities in the individual account's. This should map over to i.Scribe ok, in that it has one account and therefor 1 identity in that account.
• The C++ versions of the misc tools. The scripts should be fast and self documenting now. I will remove the C++ utilities in the Tools menu.
• The "Add Recipient" window. The search as you type drop down on the add recipient line is good enough for everyone now. I see no point duplicating functionality. If there is some missing functionality in the search as you type box I'll bring it up to speed.
• Some options will be moved into the advanced tab's tree control, which will go "live" soon. This will de-clutter the options dialog. I'm hoping to drop the tab count down so that they never need "scrolling" even with large fonts.
• The recipient entry edit box will be merged with the recipient list. Not sure on the details on this but it needs to be done.
• I'm thinking about removing email "Templates". I'm not sure they get used enough. Feel free to correct me if you think they should stay.
• The "security" options for folders and settings. I want to delete it and replace it with file system based permissions for folders/email and maybe an idle password if you havn't used the app for a while.
• Make the help html viewable in the built in HTML renderer, instead of relying on the host OS's web browser. Sometimes the host's HTML association is broken or pointing at something dumb (like MS Word!). So I can remove that pot hole by just rendering the help myself.

Which are all fairly tame I think. However there is one change that I'm considering thats a little risky. And that is the default location for settings and folders. Currently the default is in the same folder as the application install. Which works for single user Windows quite well. But it's been several years since Scribe has run on Linux and Mac OS X and well things just don't work that way on unix based operating systems. Their main concept is that the app sits in a central location and saves all it's user specific data somewhere in the user's home directory. A definate separation of application and data, and in Linux enforced with permissions so that users can't modify the application. Modern Windows applications follow the same model as well, the app sits in the Program Files hierarchy and the data is saved in the user's Application Data folder.

By default I think Scribe should move to this model. However Scribe has prided itself in being able to by portable so I'm considering making the install ask the user for a "desktop" install or a "portable" install and locate the settings and folders appropriately. That way people get the best of both worlds. There are some edge cases that will need smoothing over but I think it'll work in theory.

Backup/Copy: the user can no longer assume that operating on the app's folder will backup, copy or move their settings and email. So I will probably make some sort of menu for doing that manually. Maybe in the form of converting between desktop and portable storage post install. I'll probably get a fair bit of feedback about that in the next few v2 builds.

What else needs to be cut from v2?

27/7/2008
So every 2-3 years I have to reinstall windows. It's part of life. This week it's my turn to face the dreaded reinstall to get XP running on a new faster HD with way more space. Anyway the install went something like this:

• Put new drive in.
• Put XP pro cd in drive, boot machine.
• Drive doesn't read disc. Wow great start.
• Make copy of disk using Macbook
• Boot copy of disk. Install.
• Wait for 2+ hrs while it formats the drive.
• Boot up, no network.
• Download nForce4 drivers on Macbook, sneaker net.
• Install them and reboot.
• "Pci.sys" missing. Oh great... here we go.
• Boot into repair mode, decompress pci.sys from i386 and copy into place (using Macbook for reference info)
• Boots... *sigh*
• Install the latest nVidia drivers.
• Install other apps, drivers, HD's etc.

Now at this point I have a working machine with most of the apps we use day to day working well. Seems fast, hasn't crashed... looking good.

Of course it's not good is it.

TV out doesn't work. Here we go. I have painful memories of getting this working last time.

• Open nVidia control panel.
• Select TV format PAL/B
• Select show video on TV monitor
• "Apply"
• Nothing works.
• Repeat all those steps.
• Still nothing, watch the settings as I do them and each time I set "PAL/B" as my composite output format it reverts to "NTSC/M". Nice.
• Ok so I poke around on Google, and it seems the regional settings matter. So I set my regional settings correctly and reboot (just to be sure).
• Then try nvidia control panel again. Same results.
• After a few minutes of clicking around I pressed apply and the screen went totally desktop blue. Somehow it had decided that 640x480 was good for my main LCD... almost like it had swapped the resolution settings between TV and the LCD.
• I managed to get the nVidia control panel up again and reset to 1280x1024, but all the task bar and icons were gone.
• I turned off dual view mode hoping to get my desktop back with "Single Display". Guess what nVidia decided I meant by doing that?
• It shut down the LCD completely and output to the desktop to the non-functional TV out. So I had 2 displays dead in the water.
• Some nice descriptive words came to mind for nVidia.
• After uninstalling the driver, I sorted through my little collection of drivers from past installs. I'm somewhat of a pack rat and sure enough in my nVidia drivers folder is a file called "84.21_forceware (really good).exe".
• Lol that looks good, so I install it and bang... the TV out is working perfectly. No thanks to nVidia, they must hate their customers with a special sort of evil malevolence to release their current series of drivers.

Needless to say my days of buying nVidia are well and truly over.

8/7/2008
In my travels I've had reason to play with custom memory managers for tracking leaks. My particular flavour outputs a text file on exit with each leak and the stack frame of the allocator, including file and line numbers. Very useful.

Initially I ran the dump code using an atexit handler. This seemed to work well, but then I noticed that some global objects were being destroyed after the dump handler was called AND to top it off the handler would not finish. The process would exit WHILE the dump was mid stream. So you get some of the blocks but not all.

So I've been playing with other methods of calling the dump code in the right place. The best so far that I've come up with is this:

#include <process.h>
#include "MemTrack.h"

int main()
{
    char *buffer = new char[256]; // leak something

    // normal main code..

    #ifdef TRACK_MEMORY
    _cexit();
    MemDumpBlocks("leaks.txt");
    ExitProcess(0);
    #else
    return 0;
    #endif
}

Or something like that. The call to _cexit calls all the global destructors so that their memory is freed before you dump your blocks to disk. Then the ExitProcess is the neatest way to end the process right now without any more cleanup code being called. I played with _exit, but it didn't really exit right now... it wanted to call all the global destructors again. Not cool.

Anyway there you have it, an insight into calling code after all the global objects have been cleaned up.

3/7/2008
Just thought I'd mention some technology developed in Australia that could put a serious dent in the argument that electric cars, motorbikes and bicycles aren't good enough yet.

Redox Gel Batteries

Farnow Pty Ltd, see this PDF for some more info, but it's basically a higher density gel battery that can be made cheaply, has a fast recharge time and can deep cycle.

Gemini Electric Motor

Gemini motors are using both ends of the magnets for better power output and efficiency.

Put both of these technologies together and you might get a vehicle that can compete with the gas guzzlers.

Except the technology is protected by the patent system. Which means that we won't see anything happen for another 15 years when the patents run out. In the meantime the human race is running headlong into extinction. All because a few companies need to make a buck. Or not.

Patents are overwhelmingly evil, there is no good side to them. Just stifled innovation to the detriment of human kind.

Previously. Previously.

25/6/2008
Visual Studio 2002, 2003 and 2005 all have a delightful little bug where sometimes the keyboard state can get messed up so that find in files stops working with the error message:

No files were found to look in.
Find was stopped in progress.

Which I've blogged about before. The commonly held solution is to press Ctrl+Scroll Lock and everything is dandy again.

Well until yesterday that is. Where upon that error message appears in my Find Results pane. I dutifully look up the key press on my own blog (who remembers these things?) and press the key combo. And...? Nothing. Still the same error. Huh?

So back to dearly beloved Google, and I'm searching around. And ran into an alternate solution.

Yes, a different key combo.

For the same problem.

*sigh*

I present to you: Alt+Pause/Break.

Yes... believe it. If the first combo doesn't work, try the 2nd. I suspect by now there are "n" different combos that might need to be invoked to pacify the raging Visual Studio, and that getting you hooked on Ctrl+Scroll Lock is just a gateway drug to a whole swath of arcane key combos that you have to know. I expect that this would make a good interview question.

Previously.

23/6/2008
When you are running X windows apps in gdb and they grab the mouse and then crash or hit a breakpoint your console is locked out, you can't do anything except quit the app from a text terminal (i.e. Ctrl+Alt+F1).

However there is a better way. Add these lines to your X11 config:

Section "ServerFlags"
    Option "AllowDeactivateGrabs" "true"
EndSection

And restart X, now you should be able to use Ctrl+Alt+NumPad / to "ungrab" the mouse at any point and debug the issue in gdb.

Nice.

But it begs the question, why is it not on by default?

5/6/2008
Some 8 months after I ordered a BYOC EQ pedal it arrived today, just as the Aussie BYOC distributor is calling it quits.

I didn't intend for it to arrive the same week as the Microprocessor, I'll be getting pretty good at wielding a soldering iron yeah?

On top of that I finally picked up D.M. Cornish's Lamplighter last week, written by a friend of mine who now lives in SA.

How am I ever going to get time to code?

4/6/2008
Basically in the background over the last few months I've been working on a complete rewrite of the Scribe/i.Mage/i.Hex scripting engine to a bytecode/VM model. Currently the engine is going into i.Mage first as a non-default option (i.e. it'll use the v1 engine by default) until I shake out all the bugs.

The main reason for doing it is a lot more speed. The initial version 1 engine was a dumb interpreter and hideously slow. I'm not sure how much faster it'll be until I get a few more things working but I'm expecting a 10x at least increase in speed. The 2 engines run the same code in the same environment, but the error checking is a lot better in the new engine. At the moment it's a switch branching design (i.e. dumbest) but it'll do for the moment. I can refine the internals later if need be.

This will be shipping in the next release of i.Mage, and most likely be the default and only engine in Scribe v2.

2/6/2008

I'm going to see if I can program it to display current economy figures in my car using the OBD-2 connector.

29/5/2008
This morning I did some work on the drag and drop support for Mac Lgi applications. Basically I'm playing with SetDragImageWithCGImage to add an image next to the cursor that displays the current drag verb as you move the mouse across the screen. Currently this is static, but it should be possible to have this update as the cursor moves across different windows that may or may not accept the type of data you are dragging. This is not quite as defined as on windows, but with a little extra code I think it could be better than the windows implementation.

At the moment I think the default behaviour will be to write the word "Copy" next to the cursor if the d'n'd action will be to copy. And "Move" if it will move the data etc. Eventually I will add a hook back into the application so that apps can provide custom images for d'n'd operations. This might even be portable back to Windows and Linux, I don't know yet. But if I implement it on Mac first I'll have something to play with back on Windows.

I've always found it annoying when the default icon or picture doesn't give you feedback on whether you're copying or moving the data with d'n'd. I know on windows there are different icons and sometimes Mac gives you a "+" sign, but still... I don't want to have to remember what "+" means!