Page: 0 ... 5 ... 10 ... 15 ... 20 24 25 26 27 28 29 30 31 32 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80
Imap Design
Date: 29/8/2008
I've been working on the IMAP code for v2 a bit and thought I'd post an architecture diagram. Just for fun.

This how email gets from the server to the screen in the current dev build of Scribe v2. I had to write a new FETCH implementation in the IMAP class because the existing methods were too restrictive. Basically I'm moving more towards an API that maps far more directly to the protocol, exposing more power to the calling code. The new FETCH code parses the response on the fly and when it has a whole record, calls a callback method with the fields in a hash table. It's a lot faster and more flexible than the old code.

So, reading mail works. Now just to add moving, deleting and mail change notification.
(1) Comment | Add Comment

Translating Script Menu Names
Date: 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.


Previously, Previously.
(7) Comments | Add Comment

Deleting Scribe v2.00 Plugins
Date: 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.
(0) Comments | Add Comment

Scribe: Stuff to delete and clean up for v2
Date: 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?
(3) Comments | Add Comment

The Reinstall
Date: 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.
(0) Comments | Add Comment

Last one out turn off the lights.
Date: 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
    return 0;
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.
(0) Comments | Add Comment