On 02/17/2008 12:08:40 PM, zentara wrote: -> Yeah, dynamically generated menus would be the way to go, -> but I would watch out for memory gains everytime you invoke the menu. -> Tk isn't very good about object cleanup.
i will remember and look into this. -> Another problem with dynamic menus, is that is may be harder on the -> user. I, for one, get a feel for what-and-where all the menu options -> are. If they change dynamically, it can be an annoyance.hmmm...personally, i don't use any button-bars or docks, or even title-bar buttons with my WM. Just key macros and mouse menus. Atypical, but faster and easier (once you know all the combinations).
In fact the menus in the app i did were all filesystem directory entries, and the operation performed on them depends on context (it may be copy, or find, or whatever). So there is no way for me to keep the entries static. It is, in essence, a file browser with much less clicking -- via the cascades you can move into a tree recursively at once, since the entire tree is generated at once. Fast. But remember, no one else has to use it ;)
I included a script which does something very similar to your last post, but with popups in my subroutine driven style. Two things i would observe 1) it involves more perl, less tk; 2) it is less than half the size in bytes. Line length limits in email mean i had to attach it, hopefully the unix LF's are ok.
-> (i never "use strict" -> because -> >i am convinced that declaring a variable LOCALLY should be the -> >exception, not the rule, instead of vice versa w/ strict). -> -> You will probably change that attitude toward strict later. I think -> in -> Perl6, strict will be on by default, and your code will be tough to -> work -> with.I guess i will have to keep my copy of 5.8.8, haha. Thanx for letting me know, and about comp.lang.perl.tk, i had forgotten newsgroups.
new.pl
Description: Perl program
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
