| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 43 44 45 46 47 48 49 50 51 ... 55 ... 60
| LgiRes/Scribe | |
|---|---|
|
Date: 3/11/2006 | About 2 weeks ago I got an email from a Scribe translator about how the some of the controls in the Scribe.lr8 file are too tiny to select and translate, this was because LgiRes had a bug that meant the controls moved around when you loaded the file again. In fixing that I ended up changing some of the way Lgi handled client/non-client regions in GView's that don't have an actual HWND (otherwise known as virtual views). Previous this had been a bit broken and in fixing it I had broken it properly. After hours of work I got sick of mucking with it and gave up. However this left the development build of LgiRes dead in the water. So I started using the build off the website. Which works but all the controls in the LayoutTable's move around randomly.
Then of course I had need to delete a control and it crashed. Bugger. I was trying to change the receive account UI in Scribe to have a specific field for the "Port" number because I'm sick to death of explaining to people what "Server[:Port]" means. So my grand idea was to make Port a separate field with a checkbox to enable it. And when it's not enabled its greyed out with "(default)" written in grey text. Sound good? Well at least it'll be bleedingly obvious I hope. Anyway I've been forced to fix LgiRes, which I got done today. One little question from a user sometimes triggers off weeks of work, refactoring code, fixing design/architecture issues, fixing fundamental parts of code that requires lots of testing. So when you're wondering why things sometimes take so long, thats why. Some changes are a few lines of code, some are many weeks of work spanning multiple software products and effecting API's, DLL's and my sanity. Next week will likely see the release of Scribe v1.89 test8, with all it's shiny new options code. I want to run it live a bit more now that the development is slowing down, see if there are any showstopping issues. PS the lr8 file format had a hard coded offset in the child controls that hang off a dialog. That has been removed in the latest LgiRes + Lgi builds. You just need to load/save you lr8 to update them to the new offset. |
| (0) Comments | Add Comment | |
| Progress | |
|---|---|
|
Date: 31/10/2006 | I've refactored the SSL implementation in Scribe v1.89 test7 a bit. Basically I reuse the one SSL_CTX object allocated with SSL_CTX_new for the lifetime of the application instead of for just one connection. I also made the mistake of deliberately freeing the SSL object that I retreived with BIO_get_ssl. Obviously that belongs to the BIO object or something, because when I freed the BIO object with BIO_free_all it seems to free the SSL object as well. And if you try and free the SSL object after that it crashes.
End result is that now it seems to be working fine. No crashes, just normal operation over time. I'm just keeping it connecting regularly to test it over the next few days. The state of the core components of Scribe is getting more stable now after ripping out the old options system and implementing a new one. There is one area that hasn't been fixed up yet and that is the plugins option storage. Currently they use this weird indexing system which won't be compatible with the new XML options file. So I'll have to rewrite that over the next day or 2, and then test it. There is now a new more robust method to save Window state (position and min/max) to an option file and built it into the GWindow object. This should mean that over the next release or 2 window positions become more reliable on a wider range of systems. Hand in hand with that I've fixed the "MoveOnScreen" method of the GView class to handle multiple monitors (at least on Win32) in an intellegent manner. And I plan to do the same sort of magic on the "MoveToCenter" method to avoid it going to the wrong screen or the edge of 2 screens. It should center on the same monitor as the other windows in the application. More or less. I'm playing with the idea of offering an option to store mail, contacts and other objects in a Maildir style folder instead of all in a mail2 file. This has some benifits and some drawbacks but I think the benifits outweigh the drawbacks. In the long term I'd like to move fully away from the mail2 file format. But I worry that some users need the benifits of it, especially people that use space limited USB drives will get hit with wasted space per node due to file system limitations. I don't know how bad that'll be yet but it might be a problem. The benifits are mainly, opportunity for corruption is very limited and easily fixed, you still benifit from being able to move large email around effortlessly, deletes are easy and quick (unlike MBOX) and it's mostly compatible with other mail clients that support maildir. It's tempting. One question I havn't fully answered is whether I should attempt to support both at the same time or just drop mail2 all together. You might like to weigh in with your opinion in the comments. |
| (2) Comments | Add Comment | |
| Scribe Options Format | |
|---|---|
|
Date: 25/10/2006 | I've spent the last 10 hours of coding time converting Scribe's internal settings format across to a new thread safe XML format. The old system used a non-thread safe property list and associated UI serialization code. And rather than try and hack thread safety onto that I decided to move Scribe over to XML at the same time. I underestimated the amount of work involved to a large degree. The code base has been converted over and is kinda running, but there is a lot of clean up work and testing still to go.
Apart from thread safety, one of the reasons I wanted to do this now is that I couldn't tack on extra meta data to the information about messages still on the server. With XML this will be easy and extensible. So features like "leave mail on server for [5 ] days" should be far easier. Not to mention that it'll open up the options format for inspection by users. I expect that I'll feel happier about adding "hidden" options in the XML for users that need some obscure behaviour modification. I expect that even with a lot of testing there will be some amount of regression bugs in the next release. With that number of code changes there is simply no way that nothing will break. But it'll mean better stability, feature depth and flexibility in the future. Sometimes it's two steps forward, one back. Update: Core functionality is back online, I'm receiving email using the new code base. SSL is still dead and there is no way to import settings from an old Scribe.r file. Which people will no doubt need right? Update2: SSL now works and I've fixed Bug #118 as well. |
| (3) Comments | Add Comment | |
| Oldest Scribe Bug Fixed | |
|---|---|
|
Date: 16/10/2006 | A very old, but rare Scribe bug got fixed today. Actually it's a general bug in Lgi. But only Scribe users reported it, and it was entered in Bugzilla against Scribe... anyway it should be all good in the next release. |
| (0) Comments | Add Comment | |
| What happened to all those BeOS ports of Memecode apps? | |
|---|---|
|
Date: 14/10/2006 | Well basically they still all compile/run on BeOS except that shortly after running they hang and don't recover. I've spend a long time analysing this issue and I've posted the specifics here. So if you'd like to see Lgi apps running on BeOS/Zeta again feel free to help nail this one bug.
I expect that if valgrind ran on BeOS it'd be a matter of minutes to fix but it doesn't so here we are years later, no closer to solving this. This time around I got a lot closer to the code having problems. I've mostly isolated which calls in my code create the problems. But they seem perfectly normal and sane. Help? |
| (0) Comments | Add Comment | |
| Recuring Calendar UI | |
|---|---|
|
Date: 3/10/2006 | This is the draft layout for recuring events in the Calendar window:
The combo boxes contain "Days", "Weeks", "Months" and "Years". The other "End Date" drop down is a calendar month view selector like in the Appointment tab. Any comments? |
| (3) Comments | Add Comment | |
