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 / Scribe v2
Date: 2/9/2008
After getting a gentle push to read the docs more carefully from the IMAP protocol mailing list guys I'm close to having an implementation that understand the BODYSTRUCTURE field such that it can be picky about which parts of the email's body to download. In the case that you have an email with a large attachment it seems obvious that the client downloads just the text/html part for display without immediately fetching the attachment. Well thats easier said than done. I've got some code now that extracts the body structure into a XML dom tree and I'm hoping to expose that to the UI layers in Scribe so that I can start picking which bits I need for display instead of fetching the entire body of the message. I'll have to synthesize similar functionality on the mail2 backend but that shouldn't be too much work. It's already half there with the attachments as separate child objects of the email.

However the whole caching model is taking longer than I anticipated to get running smoothly. I keep finding that email is falling through cracks or asserts firing, telling me that something couldn't be found when it really should be there. Clearly it's a non trivial piece of code.

(0) Comments | Add Comment

DVB → Mp4
Date: 2/9/2008
For a long time I've had a private stock app that manages encoding DVB mpeg2 to whatever compressed video format is in fashion. Which at the moment is H.264.

So anyway recently I started pushing HD through it and well it did not like that at all. Basically after much head scratching I worked out that avisynth, which serves up frames to x264 was "guessing" the length of the input mpeg2 file, or more correctly, one of the filters in it's direct show graph was doing the guess. Unfortunately, because Avisynth has to report an exact length of it's AVI at startup it means that the video stream is only ever as long as Avisynth's "guess". This is unacceptable, and there is only one route around this, and that is not to use direct show (i.e. DirectShowSource). So the option is using Mpeg2source filter plugin (oh no yet another dependency!). And that relies on an indexer to produce d2v indexes of the mpeg2 first. So now my graph looks like this:

This is a graphical editor for video processing blocks that I've been working on. Essentially the current system is a hardcoded version of this, but when I'm done, all the same functionality will be plug and play, probably with some scripting support as well.

This week I did finally get my mpeg parsing library up to snuff so that it can dump out all the meta data for a mpeg video stream (not PS/TS, just video at this stage) which is a good step forward. At the moment the mpeg2demux stage runs Pvastrumento which is the best error correcting demuxer available. However I'm about halfway to having a demuxer myself, and I suspect that I can create something that can compete with the error correcting capabilities of Pvastrumento and probably produce a d2v file in the process. So that would greatly simplify the whole diagram and get rid of that ungainly d2v indexing step.

Eventually I'll build up a library of components and graphs to handle the vast majority of media re-encoding needs and possibly release it as an application.
(0) Comments | Add Comment

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