| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 ... 25 27 28 29 30 31 32 33 34 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75
| Panther Support Dropped | |
|---|---|
|
Date: 13/5/2008 | In the upcoming round of Mac releases I'm dropping explicit support for Panther. Supported OS's will be 10.4.11 and the latest 10.5 release. I will try and make a PPC build as well as an x86 build but they'll likely be separate releases so that the download size is reasonable. Otherwise Scribe will be like a 4mb download instead of a 2.1mb download. |
| (0) Comments | Add Comment | |
| Mac Native | |
|---|---|
|
Date: 10/5/2008 | I know that it's been a long time between drinks regarding Mac releases. And thats mostly because I've been very busy with other projects. But the last few weeks I've been working more and more on the Mac codebase. I've spent a lot of time re-working the drag and drop support. Which apart from not looking any different is becoming more reliable and flexible. Secondly I'm working on compatibility with standard Mac key bindings, for instance hiding a window. And now I'm playing with the native Mac file open dialogs. I've got a basic implementation working. Now it's a case of mapping all the parameters to the various Mac APIs.
As for the various apps I've ported, I've got i.Mage working quite well on Mac and i.Hex has been ported as well. The Scribe port is undergoing day to day testing. I've changed some things in the receive code to log all the accesses to the mail transfer status variable which has been getting corrupted by something. So far so good. I'm also planning to play with some of the native controls inside the context of an Lgi application. Which hopefully will make the app look and feel more native. I'm wondering if I can make the toolbars extend the title bar down over the buttons. Hmmmm. |
| (2) Comments | Add Comment | |
| Scribe Progress | |
|---|---|
|
Date: 5/5/2008 | After this debarcle I've had to spend some serious time extending and fixing the FolderDump utility that can re-build badly broken folders. This tool scans the folders.mail2 file and extract all the usable information out of it and writes a "good" version of it to export.mail2. This is a somewhat difficult thing to do depending on the type of damage the file has received. In this case, every object had lost it's hierarchy and had to be re-connection to the tree in some meaningful way. Some other folders have millions of false positive objects and duplicate object pointers. Other have random corruptions and broken links.
So anyway if you've been wondering where I'd disappeared to, well thats where. Oh and writing/recording music. I do more than code apps. |
| (0) Comments | Add Comment | |
| More Visual C++ 2005 Keyboard Idiocy | |
|---|---|
|
Date: 21/4/2008 | After the previous keyboard related debarcle it should come as no surprise that Visual C++ 2005 can shoot itself in the foot with macros. The situation I found myself in today is that the Words fail me... |
| (0) Comments | Add Comment | |
| Leopard Support | |
|---|---|
|
Date: 19/3/2008 | X-Mailer: InScribe v1.90 (Test3, MacOSX v10.5.2, Debug, en)Yes I'm working on Leopard support. So far the major issue seems to be a slow down somewhere in the startup code. So I've built the codebase on Leopard and fixed the project files. And I'm not seeing any slowness on a Leopard based build. So maybe it's because the current release is built on Tiger that it's having issues. Leopard isn't really stable enough for everyday usage IMHO so I'd like to be able to work out what is borking up Tiger based builds of Scribe on Leopard. Most of the other issues appear to be similar to Tiger. Still there seems to be so much work to do and so little time. One issue I'm looking at is that I can't load libPng in Leopard (works in Tiger). When I dlopen(libPng.dylib) I get "image not found" but a spotlight search turns it up in the frameworks tree. What gives? I have fixed some other non-Leopard issues while I'm here. Unfortunately not "the" issue, which is the hang in the receive mail code due to memory corruption. It's hard to reproduce and harder to debug. |
| (1) Comment | Add Comment | |
| Scribe v2 Progress | |
|---|---|
|
Date: 17/3/2008 | I've ported the existing v2 to both Linux and Mac, although I have no immediate plans to make releases on those platforms I like having a working svn. The linux build is particularly useful for checking under valgrind and the mac port is useful for when I'm working on a laptop away from my PC.
As for v2 itself I've been implementing the foundations for a basic Maildir backend which I can reuse for IMAP. I know its not the "proper" way you should do IMAP but I can move towards that once I've got something working. I'm putting in place methods of converting mail between different backends and making that fairly seemless. Today I've implemented an attachment class for the IMAP code and I'm using the GMime class that I wrote a zillion years ago. Because the new internal API's are now well designed I can change implementation details like exactly how the IMAP cache works without effecting the main app in any significant way. This gives me a lot of freedom that I didn't have before. Some of the work I've been doing this week is going towards adding multiple simultaneous folder support. Which is a stepping stone to good import and export functionality too. I could do something crazy like write a MAPI backend... thing about that. Scribe could be corrupted by the dark side! If I wrote a backend for all the mail import/export formats I can read/write, and then rewrite the import/export code to replicate between any 2 backend mail stores... hmmmmm. The possibilities are endless. So far the whole architecture is holding up well in day to day use. I can't wait to write a faster "native" backend to replace mail2 files. |
| (1) Comment | Add Comment | |