Dirk80 has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I've seen that there is a naming convention for the widgets of perl tk: Unsolicited Advice (Mastering Perl Tk).

But is there also a naming convention for hierarchical widgets? For example I have a notebook widget with several tabs. And in a tab I use a frame and in this frame is another frame and then there is a button. If I just name this button "blah_b" for example it is not enough because I could have a button with the same purpose in another frame. So I would like to give it a name which signals that it is inside this tab, frame, ...

My idea was to do this with a prefix. Another idea would be to do this with a hash which represents the hierarchial structure of the GUI.

So the name would represent the hierarchial structure of the GUI. But if I want to move this button from one place to another then I would have to change the name.

So I'm very interested how you handle this problem. At the moment I have no prefix or hash used to name the widgets. But now I really get confused when I'm creating a bigger GUI with perl tk.

Thank you

Dirk

Replies are listed 'Best First'.
Re: Perl Tk Naming Convention
by zentara (Cardinal) on Jan 13, 2010 at 15:15 UTC
    My idea was to do this with a prefix. Another idea would be to do this with a hash which represents the hierarchial structure of the GUI

    You are asking for objects.... an object is essentially a blessed hash, that can contain all sorts of methods and data. So you would have $obj1->{'frame1'}->{'button2'}

    But there is an arcane underlying naming convention in Tk, in case you want to use it, for example: 

    #!/usr/bin/perl
use strict;
use Tk;
use Data::Dumper;

my $mw = MainWindow->new;

for(0..4){
$mw->Button(-text => "Hello World$_",
                     -command=>[\&change])->pack;
}
MainLoop;

sub change {
#Tk dosn't pass it's widget reference in callbacks
#Only the bind() method will implicity pass a widget reference, and ev
+en
#this default (and generally preferred) action can be defeated.
#use $Tk::widget
print "sub-input->@_\n";
my $caller = $Tk::widget;
#print Dumper([$caller]);
print "$caller   ";
print $caller->{'_TkValue_'},'     ';
my $text = $caller->cget('-text');
print "$text\n";
$caller->configure(-text=>"Hello Stranger");
}

    [download]
    or try this 
    #!/usr/bin/perl
use warnings;
use strict;
use Tk;

my $mw = tkinit;

my $id = $mw->id;
print "mainwindow->$id\n";

my $button = $mw->Button(-text =>'Exit',
                         -command =>sub {Tk::exit;}
                        )->pack();

my $buttonid = $button->id;
print "button->$buttonid\n";
            
my $mwpath = $mw->pathname($id);
print "mwpath->$mwpath\n";

my $buttonpath = $button->pathname($buttonid);
print "buttonpath->$buttonpath\n";

MainLoop;

    [download]
    if you want a simple example of how to make your own package or module, google for "perl tk derived mega", and see my educational example of a simple Tk module example at CanvasDirTree.... you can use it as a template for making your own.
    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku
[reply]
[d/l]
[select]
Re: Perl Tk Naming Convention
by arkturuz (Curate) on Jan 13, 2010 at 15:24 UTC
    The $blah_ part could also specify widget hierarchy. For example: 
    my $frame1 = Tk::Frame->new;
my $frame1_btn_ok = Tk::Button->new;

    [download]
    When relocating $frame1_btk_ok to different frame you get $frame2_btn_ok. That's how I do it in Perl/Tk and Tcl/Tk ('.' being the separator here).
[reply]
[d/l]
[select]
      I usually go with the hash approach, because it is then easier to modularize. So 
      my $frame1 = Tk::Frame->new;
my $frame1_btn_ok = Tk::Button->new;

      [download]
      becomes 
      my %widget_hash;
my $frame_count = 0;

foreach my $count(1..10){
    $widget_hash{$count}{ 'frame'} = $mw->Frame->new;
     $widget_hash{$count}{ 'ok_but'}=  
           $widget_hash{$count}{ 'frame'}->Tk::Button->new; 
 }

      [download]

      The advantages of doing that way, is that you can easily use a variable in your hash strings, rather than trying to concantate strings into strings

      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku
[reply]
[d/l]
[select]
        I used hashes before (after seeing them in the source code ZooZ produces), but now I just stick to underscores. I rarely modify GUI after I'm done with it, so the hashes are not really necessary, I think. For some complex application, I think the hashes would be better approach after all.
[reply]

Back to Seekers of Perl Wisdom