|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.
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?
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|
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.
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:
|(0) Comments | Add Comment|
|Scribe Final (Really)|
Date: 13/12/2004||Well we're counting down to that magical stable Scribe release (yes I know Christmas IS comming) and the translators are passing in their last edits. It's likely it'll be out by the 20th. Just in time to pop it under the tree of your Outlook stricken family members! ;)
I've also fixed one last crash bug and updated the GnuPG plugins as well.
But we're really just watching and waiting for things to settle and for people to have a last chance for feedback before it's finally really actually final.
We will be taking a break over the Christmas / New Year starting around the 23rd through to the 7th. So don't expect much in the way of response from us then. PayPal purchases of InScribe will still get immediate key and download information but Kagi purchasers may have to wait a little longer than normal for their key.
|(0) Comments | Add Comment|
|The Sky IS Actually Falling|
|(6) Comments | Add Comment|