#8370: Onscreen keyboard -------------------------------------+----------------------------- Reporter: X512 | Owner: korli Type: enhancement | Status: new Priority: normal | Milestone: R1 Component: Add-Ons/Input Filters | Version: R1/Development Resolution: | Keywords: Acer, W500, GCI Blocked By: 8338, 9545 | Blocking: Has a Patch: 0 | Platform: All -------------------------------------+----------------------------- Comment (by axeld): Replying to [comment:10 X512]: > Replying to [comment:9 axeld]: > > Looks nice, patches welcome. However, I think it must share the same code (KeyboardView) that Keymap is using -- it does not make much sense to maintain code that pretty much does the same thing in two different places. > At first KeyboardView in Keymap preflet is hardcoded to be keymap editor and not keyboard. So what? Same goes for BTextView, and it can still be used (and is used in a number of places) in non editable mode. > It need to be changed a lot to be shared. Changing will be more complicated than writing independent implementation. Not really. Duplicating code is not a good idea, in any case. > Current Keymap preflet is also waste a lot of CPU time that is a problem for mobile devices. I don't see this. Are you referring to the rounded borders, by any chance? > At second I plan to use different keyboard layout format that layout keys like layouting of BViews using BLayout and had ability to use special keys such as keys without scancode (smiley, special characters), and keys that change layout or keymap. Sure, KeyboardView does not have these features. I just can't understand how rewriting it completely is any easier than adding them. > Also I plan to make GUI editor for layout to take benefit of modifiable nature of onscreen keyboard unlike hardware keyboard. KeyboardView already supports arbitrary layouts. > Also is it OK to use MacOS like icons for command and option keys? As I know BeOS keyboard layout has origin of MacOS one. This is probably nothing we would ship Haiku with, but other than that, it doesn't really matter if the keyboard is changeable. Was there any particular reason to implement this as a keyboard device within the input_server rather than as a stand-alone application? How does the keyboard know when it should be visible? -- Ticket URL: <http://dev.haiku-os.org/ticket/8370#comment:11> Haiku <http://dev.haiku-os.org> Haiku - the operating system.