|
04/24/2007, 10:30 PM
#52
 Originally Posted by hannip
No I was thinking commandline utility. It's nothing worse than how we use LEDUp and other exe's that we depend on. But if there is a way to detect registry changes without the overhead of polling that would be a better interface I guess.
Hannip I hear ya, I agree it's no worse in this case, but what about the uhh, next case...
Hear me out...
I like the i-handle-it vs. you-handle-it paradigm because:
1) it solves two very general cases which cover all possible scenarios of when and what to update.
2) it is compatible with the behavior that scripts see now when updating the carrier line today, they just change the location that they write to and it's done.
3) they have complete control over changes, and can assume responsibility of how efficient or how unforgiving they want to be.
( otherwise known as the "how much rope do you want" defense )
If I add the blink functionality instead:
1) It solves one general case and one very specific case, and pushes the burden on me whenever another case comes up that needs to be solved.
2) not as compatible
3) I'm not sure, but I may have threading issues when adding a non-GDI timer, plus a command line interface, in addition to the GDI code all touching the same state.
IMHO, wouldn't it be better to use the LED to grab your attention, and then update the icons? After all, they aren't just static, you can dynamically change them to say... a mailbox with a flag up, or change the color of the icon to red. And if need be, I could work on adding multiple icon support to the same line, i.e. sms/email/voicemail. Seriously if you search for "user interface guidelines" + "blinking text" in google, you'll find this is a serious no-no for a reason. Most people find it extremely annoying 
Not slamming sling at all, it's all he had to work with on the carrier line, but seriously wouldn't the additional icon support be cooler than blinking text?
Z.
|
|
|