Blog
Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35
File Search App
Date: 5/1/2005
5 hours of coding and I produce this from scratch:
2 minutes to index ~ and /usr, 200-500ms typical search time, does substring match on file names and displays most recently changed files first. Works on windows and linux. Opens files directly or browses their folder.

5 freakin hours. Not bad I reckon.
(3) Comments | Add Comment

New(ish) InScribe Only Feature
Date: 5/1/2005
Well some time ago someone contacted me about adding some features to Scribe and putting it on a USB key for a modest price. They got their features and then stopped responding to my emails, and of course I didn't get paid as per our agreement. And I wouldn't be surprised if the software is going out on USB keys without my knowledge or permission either. Damn stupid of me not to timebomb the test builds. Oh well...

So what to do? Well I've put that feature they got me to implement (and test to the nth degree) into InScribe for all those loyal supporters that DID pay for the software.

In the last few releases of InScribe there is a full Outlook (MAPI) export function in the export menu which is fairly robust and featured. It's been tested on most versions of Outlook/Windows and it does a replicate instead of a straight export, so you can mirror the Scribe folders onto your Outlook mail store. Can you see how handy this could be for people that use Scribe on a USB key? :) Also you can export a sub tree of the mail folders if required as well.

A late Merry Christmas to all you InScribe users!
(0) Comments | Add Comment

Ye Olde Bugeth
Date: 4/1/2005
There has been a couple of peculiar bugs in Scribe for so long now I can't remember when they were first reported (guessing: 2000-2001?). And of course every 3 months or so someone, frothing at the mouth, tells me breathlessly that "there is a bug in Scribe!". And my standard response basically boiled down to:

"So? You'll live."

Because I'd spent several weeks in engineering hours trying to fix it and well, just got no where fast.

Then some, ok many, years later I was bored and for some reason started thinking about the bugs again and dusted off the debugger and had another look at it. Well basically the first bug was sometimes when you move the mouse over a Lgi window that was behind the active top level window it would pop to the top of the z-order but not take focus. The user would be mousing around, not clicking on anything and bam, the z-order changes. Another similar issue that people love to tell me about is after compacting the folders in Scribe the main window pushed itself to the back of the z-order for no apparent reason.

These things in of themselves are annoying but not showstoppers. People learn to work around them and just get on with life (a useful skill btw). And I even stopped noticing they happened at all.

Until today.

So I decided, that maybe the bug had something to do with the mouse move message handler. Makes sense right? The mouse is moving across the window and then it happens. Well sure enough, after commenting out the WM_MOUSEMOVE handler the bug stops happening. But of course the app isn't very useful anymore. So I start the standard procedure of slowly commenting out less and less of the code until the bug reappears. But the problem with that was there was no garrenteed way of making the bug happen. But by repeating the best known method, move the mouse quickly over the title bars of several Lgi windows, many times I could build up a statistical likely hood of the bug being present in the currently running code.

After a little while I isolated the call to the current windows OnMouseEnter function. Hmmmm... what could be in that to cause the z-order change? Well I did a code base wide search of all the implementations of OnMouseEnter and the GToolBar.cpp file had 2 implementations. One for the button and one for the toolbar itself. I commented out GToolButton::OnMouseEnter... still happens. What about GToolBar::OnMouseEnter?

No bug.

Yes! Nice one. Ok, so what was the code? 3 lines that create the toolbar's tooltips. Open up the tooltip code. Hmmm, I wonder what would happen if I changed some of the flags on the tooltip's CreateWindow? Bug still happens. Oh!?! The tooltip window is parented to the toolbar... maybe... thats it? Change the tooltip parent to NULL. (Good 'ol Windows being a pain again)

No bug: Good.

Tooltips still work: Good.

Compact doesn't push window to the back of the z-order: Very Good.

w00t! Back away from the code slowly... don't touch a thing! ;) Now I'll run that for a week or so and if nothing nasty starts happening and the bug doesn't show up again then I'll release test3. Sans the oldest bug in Scribe.

Oh btw Happy New Year!
(1) Comment | Add Comment

Getting There
Date: 21/12/2004
Making things simple is well... not simple.

Anyway another Scribe test build... more fixed crashes... less bugs... maybe this will be "The One".

As far as I'm concerned it's only lacking one more translation update and then I'll call it the new "stable" release for the next 6 months or so.

In the mean time I'm starting the v1.88 thread, as the version history shows, and the kick things off I've added a feature. Just a little one. However everyone who has seen or heard about has suddenly become wildly enthusiastic and excited. So I await with some trepidation the response from the Scribe user community ;)

And it seems I need to get out more. Because it was purely and simply inspired by Gmail's most excellent user interface. Which btw I plan to nab more nice features from. Someone was nice enough to send me an invite so I could check Scribe's POP access (which works fine). But while I was there I thought I'd poke around and see what all the fuss was about.
(3) Comments | Add Comment

No Gui Gets Mouse Events Right
Date: 21/12/2004
When you write a GUI library it's a matter of time before you need to track the mouse beyond the borders of your own windows. And in general you want to do this using "Mouse Capture" where by all mouse events are sent to the window that has captured the mouse for a short period. Classical examples of this are push buttons and check boxes.

The problem comes when you don't want to capture the mouse, but you still want all mouse events. Now windows (thoughtfully) has a mouse hook procedure that you can setup to capture these events and do various things. But in vanilla mode it only works when the mouse is over your windows, and not only that, when it's over the _client area_ of your windows. So basically it's pointless. For catching clicks outside your window. So what to do? Well it appears that there is a "low level" mode that the mouse hook can operate in. Great! I thought. And sure enough it works. You get all the events, everywhere. So it's sorted isn't it.

Well, um. No actually.

After I made this change for the rest of the afternoon I noticed that the cursor was behaving rather irractically, often "freezing" for longish periods of time (e.g. 2000ms). And sure enough, switch the Lgi mouse hook back to normal mode and the mouse freezing went away. In low level mode you must have a functioning event loop all the time otherwise the cursor will freeze. Charming. In a lot of my apps I tolerate the event loop locking up for a second or so. The user however won't tolerate the cursor locking up all the time so I had to come up with another solution.

Well since none of the built in mouse hook work to my liking I created a thread that sits there polling the mouse every 50ms while I need events. I bit of overkill but it'll work fairly well. And as an added bonus it'll be very cross platform.

Speaking of other platforms, X11 doesn't even have a mouse hook function so you have to poll it anyway. Windows 1 (for trying), Linux 0.

A GUI should really let windows just have a flag "Want mouse events outside my area". Which gives you all mouse events, everywhere, all the time. I've been thinking about writing a GUI one day.

One day.

PS I wrote one in protected mode DOS using VESA that supported overlapped windows, menus, true colour etc... but that was a long time ago. :)
(0) Comments | Add Comment

All Car Geeks Want For Christmas...
Date: 14/12/2004
Sterio wise is:
  • Ogg playback. (Yes I can hear the difference, mp3 is teh suck!).
  • Wireless connection -> HDD or DVD+R drive to load songs.
  • Uncluttered dark grey/black facia (Is your car silver? No!)
  • No flaming animation.
Such a beast doesn't exist unfortunately. Feel free to prove me wrong.
(0) Comments | Add Comment