Bryan Schofield's "Action" package
Jeff Godfrey
I originally sent the following post directly to Bryan Schofield's
SourceForge email address. Unfortunately, it was returned as undeliverable
because it had been classified as Spam! Go figure...
So, I am now posting it here. Hopefully Bryan will see it, but if anyone
else has input, feel free to pass it on.
Thanks,
Jeff
==============
Hi Bryan,
I have started work on a "largish" tk based application, and I thought I'd
employ your (very cool) "action" concept into the GUI wiring.
I've run into a bit of a snag that I'd like to run by you. It's probably
just a misunderstanding on my part. It involves using the actions with
standard Tk-based menus (I'm on WinXP BTW, though I don't think that
matters).
I had assumed I could "create" my menus using the standard TK commands, then
use the action package to configure the *already existing* menu's. This
doesn't seem to be the case, as the action::apply command always seems to
*add* a new menu item, even if the action's "-text" attribute matches the
"-label" attribute of the existing menu item.
Here's an example:
(bin) 9 % action::create myAction -text "Help" -command {puts "help"}
myAction
(bin) 10 % menu .m
.m
(bin) 11 % .m add command -label "Help"
(bin) 12 % . configure -menu .m
(bin) 13 % action::apply myAction .m
When the action is applied, a *second* "Help" menu item is created.
Looking through your "ActionPackageDemo" on the wiki, I see that you just
use the "action::apply" to create the actual menu items. So, I thought
maybe I'd go that route instead of creating them myself...
The issue I ran into with that, is that I want some of my menu's to have
accelerators. If I allow the action to create the menu, then the action has
to be able to deal with the "-accelerator" option (or I have to configure
the menu item to add the accelerator after it has been created by
action::apply). Using the action::addOption command, and a bit of hacking,
I was able to get the accelerator to pass cleanly through the action package
and be assigned to the menu. But, it seems to me that if I were able to
create my menu's ahead of time, using the full array of options available to
a menu item, it would be much simpler.
So, basically my question is this. Is there a way to create the menu
structure prior to configuring it with the action package? If so, then I
haven't yet figured it out. If not, how do you recommend I add visible
accelerators to the menus?
Hmmm... Once I have solved the issue of actually getting the accelerator
into the menu, I might as well use the action package to wire the
accelerator to the app. Any suggestions for that? A few random thoughts...
- I assume I would wire the accelerator using something like "bind all
<KeyPress-?> $theCommand"
- I guess this could be added to the ::action::applicator::Menu proc in the
event of an "-accelerator" option
- Possible problem - the "-accelerator" option would need to contain the
"visible" menu accelerator text (such as "F1"). This may or may not be the
correct text for the actual binding (KeyPress-F1 is OK, KeyPress-Ctrl+F4 is
not OK).
- Does that imply that I need 2 additional action options - one for the
visible accelerator, and one for the actual binding?
Maybe I'm way off track here. Any input/thoughts appreciated.
Thanks,
Jeff Godfrey
Jeff Godfrey
again...
Thanks,
Jeff
========
"Jeff Godfrey" <jeff_g...@pobox.com> wrote in message
news:10jh4n4...@corp.supernews.com...
: Hi All,
:
:
:
Schofield
> Hi All,
>
> I originally sent the following post directly to Bryan Schofield's
> SourceForge email address. Unfortunately, it was returned as undeliverable
> because it had been classified as Spam! Go figure...
>
> So, I am now posting it here. Hopefully Bryan will see it, but if anyone
> else has input, feel free to pass it on.
Sorry, I got blown away by the big hurricane in Florida, so been out of
touch.
>
> Thanks,
>
> Jeff
>
> ==============
>
> Hi Bryan,
>
> I have started work on a "largish" tk based application, and I thought I'd
> employ your (very cool) "action" concept into the GUI wiring.
>
> I've run into a bit of a snag that I'd like to run by you. It's probably
> just a misunderstanding on my part. It involves using the actions with
> standard Tk-based menus (I'm on WinXP BTW, though I don't think that
> matters).
>
> I had assumed I could "create" my menus using the standard TK commands, then
> use the action package to configure the *already existing* menu's. This
> doesn't seem to be the case, as the action::apply command always seems to
> *add* a new menu item, even if the action's "-text" attribute matches the
> "-label" attribute of the existing menu item.
The Menu class applicator was designed to add a menu entry the first
time, then modify that entry should any parameters or options on the
action be modified. This done to simply menu entry creation &
modification, changing the action text can be tricky when trying to
remember were the menu entry once was.
>
> Here's an example:
>
> (bin) 9 % action::create myAction -text "Help" -command {puts "help"}
> myAction
> (bin) 10 % menu .m
> .m
> (bin) 11 % .m add command -label "Help"
> (bin) 12 % . configure -menu .m
> (bin) 13 % action::apply myAction .m
>
> When the action is applied, a *second* "Help" menu item is created.
>
> Looking through your "ActionPackageDemo" on the wiki, I see that you just
> use the "action::apply" to create the actual menu items. So, I thought
> maybe I'd go that route instead of creating them myself...
>
> The issue I ran into with that, is that I want some of my menu's to have
> accelerators. If I allow the action to create the menu, then the action has
> to be able to deal with the "-accelerator" option (or I have to configure
> the menu item to add the accelerator after it has been created by
> action::apply). Using the action::addOption command, and a bit of hacking,
> I was able to get the accelerator to pass cleanly through the action package
> and be assigned to the menu. But, it seems to me that if I were able to
> create my menu's ahead of time, using the full array of options available to
> a menu item, it would be much simpler.
One of driving concepts in that package was leave the actual definition
of an action open. It's really just a grouping of data. I added some
stuff that most people need, like text, image, and state. Knowing that I
would not think of everything everyone would need, and not wanting to
add everything and the kitchen sink to what constitutes an action, I
made the "action concept" customizable. So by using the "addOption"
command, you were using the package exactly as intended. Though in
hindsight, "accelerators" and "bindings" probably should have been
included by default.
The second major design consideration was to simply widget creation. In
theory all you need to do is declare the widget and let the action frame
do the rest. One other subtle point that I should make is that actions
are applied to *widgets* not subcomponents of widgets. That is, an
action is applied to a menu, not a menu entry.
button .b
menu .m
action::create foo ...
action::apply foo .b .m
>
> So, basically my question is this. Is there a way to create the menu
> structure prior to configuring it with the action package? If so, then I
> haven't yet figured it out. If not, how do you recommend I add visible
> accelerators to the menus?
Add the -accelerator (and friends if needed) and redefine what
applicator to use for Menu class widgets. The new Menu class applicator
would know how to use your new applicator option and apply the binding
to certain widgets. I think the following options should do it:
-accelerator string
-binding sequence
-bindtargets {target ?target ...?}
where target can be any valid "bind" target. eg. widget, widget class,
"all".
A second approach would be to add a -menuindex option to actions and
redefine the Menu applicator to use it. This would allow you to define
your menu entries prior to apply actions.
>
> Hmmm... Once I have solved the issue of actually getting the accelerator
> into the menu, I might as well use the action package to wire the
> accelerator to the app. Any suggestions for that? A few random thoughts...
>
> - I assume I would wire the accelerator using something like "bind all
> <KeyPress-?> $theCommand"
> - I guess this could be added to the ::action::applicator::Menu proc in the
> event of an "-accelerator" option
> - Possible problem - the "-accelerator" option would need to contain the
> "visible" menu accelerator text (such as "F1"). This may or may not be the
> correct text for the actual binding (KeyPress-F1 is OK, KeyPress-Ctrl+F4 is
> not OK).
> - Does that imply that I need 2 additional action options - one for the
> visible accelerator, and one for the actual binding?
See my comments above!
>
> Maybe I'm way off track here. Any input/thoughts appreciated.
I think you are right on track. I also think you'd be better served
adding the accelerator & bindings to your actions than manually adding
that to entries. Here's why. Let's say you have a menu bar with some
basic stuff, "cut", "copy", and "paste" come to mind. Now let's say you
also want to add little context menus to entry fields or text fields
with same "cut", "copy", and "paste". Being the user-oriented programmer
that you are, you decide to add a configuration display to your
application that allows the user to customize keyboard shortcuts. Since
our happy user George just loves Emacs, he changes the cut binding from
Control-x to Control-w. Now you need to update all those little menus
everywhere. That's ok, because that's what the action package is
designed to do. If you had done the accelerators manually, you'd have to
redo them manually.
>
> Thanks,
>
> Jeff Godfrey
I'll try to keep a closer eye on things, so feel free to mail me if you
have more questions. Also, if you are a fan of xotcl (like me) I've been
working on a object oriented version of the "action concept" that
should be ready pretty soon, along with some other xotcl based goodies.
Hope this helped you.
-- bryan
Jeff Godfrey
"Schofield" <bscho...@users.sf.net> wrote in message
news:ZWu1d.45849$w_4.6...@twister.tampabay.rr.com...
[ ... snipped lots of specific input ... ]
: Hope this helped you.
Bryan,
Thanks for all the great input. I appreciate it.
Jeff