On 9/19/07, Bruce <[EMAIL PROTECTED]> wrote: > Sander: > > In your glorious fixings of the kernel, you modified /ADC/X86/Keyboard.cs, > such that SetLEDs() no longer accepts the three boolean parameters.
Oh i might have done that while trying to figure out why my leds weren't changing when pressing the capslock.. i ran out of time figuring out why this happened.. i guess i should've changed it back before committing > Whilst I definitely identify with using state management to privately > control which LEDs are illuminated, the /ADC/Keyboard.cs file contains a > stub that causes an expectation of the "old" SetLEDs(bool,bool,bool) in the > X86 layer. (I noticed, because the AOT is belching since the methods don't > match.) So, out of such, arises a couple questions. I'm suprised the SetLed function is a stub actually > Do we want this stub publicly exposed at all? Do we need to manually toy > with these lights? Or should we just privately toggle them on and off as > their respective buttons are pressed? Well i think our keyboard mapping should have multiple states that can be toggled and a keymap for each state.. (just like we have default and shifted now) Because shift is not enough, we also have numlock.. and some laptop keyboards also have some key special key with which you can make special key combinations etc. > I can commit a change either way, I was just rather disappointed to see the > AOT crash after updating my local working copy hoping to see your fixes in > action... *sniffle* It crashed? That's odd, it didn't here :( Sorry about that, i hope you weren't too upset.. ;) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
