Are you asking because you're considering XSCHEM as a Virtuoso alternative, or because you want to understand how XSCHEM's
architecture compares to industry standards? The refactoring work we've been doing would definitely help XSCHEM's
maintainability and extensibility to better compete with commercial tools.
> The reason is that, eventually, we want to give users the ability to customize key-bindings to functionality. Currently, we are
refactoring code for readability and maintainability. If we can do that in a way that makes it easier, in a later enhancement,
to give users the ability to do custom key-bindings, that would be super.
Let us proceed with refactoring of handle_key_press
● Excellent strategic thinking! Custom key bindings are a huge differentiator for power users - Virtuoso has this capability and
it's one reason professionals love it.
Our current refactoring is perfectly aligned with this goal! Let me show you how and continue the refactoring with this in mind:
Current Architecture → Custom Key Bindings Path
What we've built so far:
static key_command_t key_commands[] = {
{'a', 0, handle_key_a},
{'b', 0, handle_file_operations},
// ...
};
Evolution to customizable bindings:
// Future: User-customizable key bindings
typedef struct {
KeySym key;
int modifiers;
char *command_name; // "copy", "zoom_full", "merge_file"
command_handler_t handler;
} user_key_binding_t;
// Load from config file: ~/.xschem/keybindings.conf
// c = copy
// Ctrl+c = copy_to_clipboard
// Alt+b = toggle_symbol_text
Next Steps for Key Binding Foundation:
1. Complete dispatch table - Move ALL keys out of switch statement
2. Add command naming - Each handler gets a string identifier
3. Separate key→command mapping - Decouple physical keys from logical commands
4. Configuration system - File-based key binding definitions
Let me continue the refactoring with this architecture in mind:
No comments:
Post a Comment