[Janak Parekh]

Originally Posted by nutzareus

I suppose writing a code module for a control panel-like applet to customize your buttons would not qualify as bloated code? That's alot of lines of code and alot of extra paths for a program to take. Remember, this is just for customizing ONE button... DELETE!

Sorry, but as a professional software engineer, I disagree with this one. Sure, it'll add code, but it's nowhere near "complicated", considering the kinds of tasks the messaging applet does. I haven't done WM programming extensively, but in a typical graphical environment, you'd add a few lines of code to read an additional user preference (the code to read preferences from the registry is already there), make one single control-flow decision, and register a callback and update the softkey's label. Thereon, during the runtime of the application, there would be zero cost performancewise. As for an extra option in the user preferences, that's pretty minimal, too.

A much better question is if it is a development priority to add such a feature. That is the true cost, not the processing power of adding a little control-flow logic. For instance (and I think you mentioned this earlier): if the left key should be customizable, which features should be allowed? Surprisingly, such things end up being a lot more complex than they seem at first. That said, since they switched the functionality from one to the other, I'd personally have preferred they add at least one boolean registry setting to allow the old functionality to remain.

Incidentally: a much more difficult, and cooler problem, would be to enable the setting of softkeys at the operating system level. This is far harder since not all applications use the softkeys for the same tasks, and even in the middle of one application the softkeys' behavior change.

--janak

[Janak Parekh]

Originally Posted by nutzareus

I suppose writing a code module for a control panel-like applet to customize your buttons would not qualify as bloated code? That's alot of lines of code and alot of extra paths for a program to take. Remember, this is just for customizing ONE button... DELETE!

Sorry, but as a professional software engineer, I disagree with this one. Sure, it'll add code, but it's nowhere near "complicated", considering the kinds of tasks the messaging applet does. I haven't done WM programming extensively, but in a typical graphical environment, you'd add a few lines of code to read an additional user preference (the code to read preferences from the registry is already there), make one single control-flow decision, and register a callback and update the softkey's label. Thereon, during the runtime of the application, there would be zero cost performancewise. As for an extra option in the user preferences, that's pretty minimal, too.

A much better question is if it is a development priority to add such a feature. That is the true cost, not the processing power of adding a little control-flow logic. For instance (and I think you mentioned this earlier): if the left key should be customizable, which features should be allowed? Surprisingly, such things end up being a lot more complex than they seem at first. That said, since they switched the functionality from one to the other, I'd personally have preferred they add at least one boolean registry setting to allow the old functionality to remain.

Incidentally: a much more difficult, and cooler problem, would be to enable the setting of softkeys at the operating system level. This is far harder since not all applications use the softkeys for the same tasks, and even in the middle of one application the softkeys' behavior change.

--janak