Re: [gtk-list] key bind class
- From: Kenneth Albanowski <kjahds kjahds com>
- To: gtk-list redhat com
- cc: gtk-devel-list redhat com
- Subject: Re: [gtk-list] key bind class
- Date: Mon, 27 Jul 1998 23:27:57 -0400 (EDT)
On Tue, 28 Jul 1998, Oskar Liljeblad wrote:
> I'm working on a class that manages key events in a way different to
> accelerators. Instead of binding to a signal connected to an object, the
> application is notified through callbacks.
>
> The class is part of an experimental command-based API for Gnome, where it
> crucial that key events are bound to callbacks. (Command-based applications
> allow the user to easily modify menus, toolbars and key bindings. Every menu
> item, toolbar and key binding is bound to a command with name, callback and
> some other properties.)
Feel free to ignore me, I'm just kibitzing, but: this _really_ calls out
for an OO approach, and indeed connecting a signal to an object. Just
that, instead of having a menu-item object, you have an "Action" object
that has an "Activation" signal that users can trap. This object would
contain useful defaults (icon banks, localized names, default
accelerators, etc.) but no visual appearance. All things that want to
allow the user to trigger action (menu-items, toolbar buttons, etc.) will
display some visable interface, and contain a link to the original,
_unique_ Action object. Among other things, this makes it easier to share
the state involved in toggleable actions (think of checkbox menu items,
etc.) across different appearances (toolbar and menu) and multiple
appearences (torn off menus, a la Tcl.)
Put another way, the Application and/or the Document would own a list of
UserEvent objects that can be placed (or rather linked-to), as desired, in
menus, toolbars, speech-recogizers, scripts, etc.
--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]