Blog
Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35
Todo List For Scribe
Date: 16/2/2005
Well I finally wrote a todo list into Scribe:
The only problem is that now I have to support the VTODO payload in vCalendar files. And it seems there are NO apps out there that do that. So I'm forging into new territory file format support wise.

Please tell me there are some other apps that read/write VTODO objects?
(2) Comments | Add Comment

Perenial Design Issues In An Email Client
Date: 14/2/2005
By most accounts Scribe is good. Some even say excellent. But there are some "grey" areas that still need addressing. And what I'd like to do is put forth the problems and ask my knowledgeable readers their opinion on possible solutions and expectations.

Temporary Files Ahhh, the age old question of temporary files. Or Scribe's use in a particular situation to be more precise. When a user receives an attachment they often want to open the attachment, usually in the default viewer for that file type. Because Scribe stores all data in a single folders.mail2 file it has to write the attachment out to disk for another application to be able to receive the data. So it writes the attachment into the temp folder and starts the associated application to open the file. Now the catch is when the user edits the file they usually don't realize where the file is, i.e. in the temp folder. Then they save there changes into a temp file.

At the moment Scribe produces a new unique filename every time the user opens the attachment to save losing the changes they may have made to the original temp file. It doesn't clean up after the user because they may want the temp file changes. So we end up with a ever increasing set of saved attachments in the temp folder.

I want a system that a) lets the user open an attachment with out specifying a folder to save to, b) doesn't blot over any changes to the file once it's saved somewhere and c) allows changes to the attachment be incorporated back into the email client when appropriate (say in a reply or forward to the original attachment's email).

Suggestions/thoughts/expectations?

Rich Editing Everyone at some point wants to do some basic styling or layout of text in an email, Scribe users included. Now Iíve tried several times to write a decent rich text editor based on the existing compose control. And well I suck at it. So Iíll lay down my parameters for a rich edit control and see if anyone knows of something that will fit:
  • Must have a license compatible with closed source commercial software.
  • Must have a small compiled footprint. Iím not adding a 300kb DLL to Scribe.
  • Must be cross platform: Windows, Linux and preferable BeOS as well. Or have a very limited drawing API that I can shoe horn into Lgi calls.
  • Should be fast with large chunks of plain text, e.g. 1mb.
  • Should have a rich event interface and command API or a built in toolbar for changing styles.
  • Should support HTML input / output.
So far nothing comes close to meeting all those. Iíd like to know if there is something in that vein available. Doesnít have to be open source, but if itís not it still has to meet the cross platform criteria. The other option is that some people help me write a native Lgi rich edit control. I can provide all the interfaces and even a stubbed out implementation.

Summary Listings One of the major speed bottlenecks of Scribe at the moment is when it loads a folder of objects (esp email) it expects to have access to the entire object (email). Including the body of the message. The problem with this is that itís bound by disk speed and on large folders that bogs it down a lot. Large message are read in entirety (sans attachments) into memory, costing Scribe time and RAM. Now itís going to be really hard to make it not do that because I would have to rewrite lots of the architecture to make it not read the whole message. Now I could move the body of the message into an attachment of the message, which would mean the size of the ďmailĒ would be much smaller and thus folder read speed could be vastly improved. As a nice side effect compatibility with other mail formats (like MBOX and .EML) could be improved at the same time.

The question is whether to do this now in the v1 code base or leave it to v2. If I do it now with the v1 code base itíll mean staying with v1 for a lot longer, as itís the worst of the architecture problems. If I do it in v2 it might not happen for a long time. Gee Iíve only been talking about v2 for 3 years. V2 brings with it a whole swath of nice features. The less work I have to do on v1.xx the more time I have for working on the v2 prototype code base. Is there some overriding sentiment in the user community either way?
(3) Comments | Add Comment

Valintines Day Scribe Theme
Date: 14/2/2005
For all you softies, a Valintines Day themed title page for Scribe v1.88-4.



Unpack this into your Scribe directory. It's simple but effective. Some people have started to play with the HTML in title.html that formats the root node page. I'm interested in what people can do with it. If you want to know about the internals of DOM fields, including linking to external applications then email me and I can give you pointers on how to do things.

Obviously if I had more time and skill I could've made some of the icons and other graphics themed as well. Oh well next year :)
(0) Comments | Add Comment

Buying A Printer
Date: 3/2/2005
I'm seriously thinking about buying a Canon PIXMA iP5000 but the only thing holding me back is the lack of Linux driver support. The main things I'm looking for is good photo support, alternative OS support, fast connect (USB2/Firewire - dreaming I know), low total cost of ownership and doesn't look ugly.

The options:
  • Canon - Cheap and separate ink carts, so low TCO. Good quality prints, fast. Update: Commercial linux support available.
  • HP - Hideously expensive cartridges. Can't replace just one colour. Looks the nicest though.
  • Lexmark - Cartridges are chipped = evil business practices.
  • Epson - Cartridges are chipped = evil business practices.
So anyone know of a better unit for A$ 300 ish?
(9) Comments | Add Comment

This Is Why I Hate RedHat
Date: 3/2/2005
lemon# rpm -q ethereal-gtk+-no-snmp-0.10.0a-1.RH9.i386.rpm
        package ethereal-gtk+-no-snmp-0.10.0a-1.RH9.i386.rpm is not installed
lemon# rpm -i ethereal-gtk+-no-snmp-0.10.0a-1.RH9.i386.rpm
        package ethereal-gtk+-no-snmp-0.10.0a-1.RH9 is already installed
10 years on and we still have to put up with rpm. For crying out loud... window's DLL hell is better than rpm hell.
(1) Comment | Add Comment

Visual C++ .NET Can't Find Squat
Date: 1/2/2005
After my last rant about the pathetic excuse for an IDE that Microsoft's Visual C++ .NET (2002) is, I have found a delightfully annoying quirk in the "Find in Files" function. Under certain circumstances that feature just stops working. Instead it says:
No files were found to look in.Find was stopped in progress.
And you want to know what the fix is?

You know I'm going to tell you anyway right?

Press Ctrl+Scroll Lock

Yup... uh huh. Thats it. Great eh? MiserySoft's finest.

Update: The saga continues....
(8) Comments | Add Comment