Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 46 47 48 49 51 52 53 54 ... 55 ... 60
|Mac Development Screenshot|
Date: 18/7/2006||So hows that whole Mac port thing going?
The main screen of i.Ftp renders fairly well. The text on bitmaps is still a little out of place but otherwise it's looking pretty good. This week after I clear some high priority Scribe things I'll get some mouse and keyboard input handling going. It feels like I'm over the hump now and it's going to be fairly downhill from here on in. I hope that it'll only take me another few weeks till I get a mostly working build of i.Ftp. At which point I'll have to start putting together a release script or whatever you have to do to build .dmg images for distributing software for a Mac. Exciting! :D
|(3) Comments | Add Comment|
Date: 17/7/2006||As you might be aware I have 2 kids, 3 1/2 and 2 years old. And we have 2 "bear lights", which are night lights in the shape of a teddy bear. They have a timer mode to switch them off after a while and a 2 monophonic tunes they can play. And of course our little ones love them, "bear light daddy!" is the cry if I forget to turn them on.
Some months ago first one and then the other started playing up, in that they'd turn themselves off for a while in the middle of the night, at which point if the child noticed they would cry out and wake us up. (We don't use the auto off mode). This will not do at all.
So after last night's wake up call I decided it's time. Time to hack. So I opened one of them up and it's got all this circuitry inside. I tried to step my way through it with a multi-meter and well I'm not an electrical engineer so all those IC's and transistors were over my head.
I gave up on understanding the original circuit and ripped all the active components out, and using a basic light circuit someone thoughtlessly left lying around on the intarweb I cobbled together a working light using the main variable resistor / switch as a dimmer and a resister of roughly the right value I found on the PCB. I drilled some holes in the plastic casing, mounted the pot back on the body of the unit with tiny bolts and screwed it all back together. I'm quite proud of my first ever circuit design... be it simple as it is.
Beware the franken-bear-light!
|(2) Comments | Add Comment|
|Scribe On Linux Issue|
Date: 6/7/2006||I've been working on the Linux build, getting it to build and run on Suse 10, which is my latest distro. Suse 10 comes with GCC 4 so I had to fix all the build errors that had appeared since I last compiled on GCC 3.x, which took a while. Then I had to fix the keyboard input. The #1 complaint about the Linux version is that is doesn't support international keyboard input properly, so I finally found a way of adding support for that without going insane. The documentation is beyond hopeless with regards to XIM (X Input Manager) and this has prevented me from adding support for XIM for about 3 years now. So this time round I just had a look at an existing implementation and copied it. The implementation that was easiest to understand was SDL, I had tried to extract a usage example from KDE back in the day but that was fairly futile. SDL is much simpler and I got what I needed fairly easily. Now Lgi supports XIM, or more to the point uses it all the time. I expect this will mean that older distros aren't supported but I care little for backwards compatibility in the Linux world. Linux is so backward that the "current" setup is just barely good enough. Thus you have to have FontConfig, XRENDER, XIM to run any current Lgi apps. I'm not going to support X fonts or the old X keyboard input that belong in the '80s. We are in 2006 now upgrade or die! ;)
Anyway, it came to my attention that Scribe can hit the 1024 open files limit quite easily in Linux. So you had 1300 mail in your POP account and you try and download it all, Scribe opens a file handle for each one, all at the same time. Now I could fix this now, but it would delay the test4 release, and for most users you rarely have to download that many mail at once. Is this a showstopper? Or should I just release now and fix it later? I guess users could just change the limit if it effects them. The ulimit command can change that limit if you have super user rights (I think).
|(1) Comment | Add Comment|
Date: 7/6/2006||I wrote a simple scripting language for i.Mage last night. Lets you create graphics based on little bits of script that can specify things in exact co-ordinates. This is generally useful to me for generating bits of graphics for web pages and applications that conform to some very specific size and shape requirements. Things like little circular filets for rounding off corners in webpages and the like. But I'm sure others will come up with a whole plethora of uses for it.|
|(9) Comments | Add Comment|
Date: 5/6/2006||Last night I ripped out the UI for conditions in Filters and replaced it with the slick new UI that I wrote last year. I've updated it and intergrated it into the application and it looks and works great. The UI is serialized into XML which is stored as a new property field in the existing filter object. Old filters are upgraded transparently to the new format when you save them. So there is some lack of backward compatibility, i.e. if you save a filter in the new version of Scribe and then try and view it in an old version all the conditions will disappear. Oh well, at least it won't crash or misbehave beyond that. All I need to do now is hook up the new condition data to the code that evaluates the conditions against an email.
I'm thinking about actually letting the user export/import filters to XML files. Some benifits of being able to do that would be allowing groups of users distribute their custom filters, backup/restore and maybe evan scripting/automation of filters down the track.
The filter UI will also effect the find/search window, which I haven't even started on yet. But chances are I'll get to it this week.
|(1) Comment | Add Comment|
|Scribe Test4 Directions|
Date: 2/6/2006||Apart from fixing the new Scribe crashes that are appearing in Test2 and Test3 I just wanted to say a few words on where I'm heading in Test4 in terms of upgraded functions and features.
Here is where the rubber hits the road. If the software is going to get "better" then it needs to get worse in the short term as I rip out badly written code and insert better foundations. Change always brings unstability in the short term. It's a constant in the software industry. Especially with a dev team of one. The options are lots of fast turn around test builds that are not stable, or no releases for a while (months?) and then a relitively stable release. What would you, as a user prefer?
|(3) Comments | Add Comment|