From the code that you've shown, I am not sure what you are trying to do. Let's try it this way: I will give you some runnable code and you tell me what else it should do or not do. When asking a question, it is important to show a short runnable example.
It been more than a decade since I've worked with a GUI. But I hacked an old application to make the code below. Repo has a cascading menu underneath the Configure button. There is no real code behind any of the options other than a snarky "this doesn't work" message box. I did put a label with the current repo name as a label box to the far right of the menu frame. Maybe something like that is appropriate for your application?
Provided that my simple framework is in the direction that you want, I guess the question is how to get Configure|Repo|Change Repo Name button to actually do something? You will need to supply a subroutine along the lines of my "not_implemented" sub.
To do this, I would back up. Start with a main window. Make a frame for your new "Change Repo Name" functionality. I suppose that you will need multiple GUI objects within this frame. A entry window, some labels, probably some action buttons like "Submit", "Cancel" or whatever. You probably start with a copy of the current repo name variable, allow the user to edit that name, submit the change, then validate it, probably with some message boxes that show various error scenarios (like my "not_implemented" sub). Next to last step of "validate" would be to copy the validated new repo name to the displayed name in the main menu bar. Get all of that working as a prototype.
Now instead of making all of this within the main window. You will need to create a new TopLevel window. Put the same code from your prototype in that window. Its fine for this "pop up" window to destroy itself as the last step in "submit". You presumably won't be doing this that often. For windows that you use a lot, you can withdraw them from the screen and then just display them again on the second use. I don't think you need that complication.
There are many ways to code my example framework, I just show one way. There are many really fancy ways to do this. I would advise keeping things as simple as you can until you become more proficient at this. So here you go....play with code below.....
use strict;
use warnings;
use Tk;
my $repo_filepath = "some current repo path?";
my $STD_TITLE = 'the title of this application';
# --- generate the "main" window
my $mw = MainWindow->new;
$mw->configure(-title=> $STD_TITLE);
$mw->geometry("400x100+0+0"); # appears in upper left corner of screen
# --- make a menu frame within the main frame
# A common mistake is not make enough frames when using pack().
# Basically, make a frame for everything that has more than
# one Tk object in it. With pack(), more frames ==>> good!
my $menu_f = $mw->Frame()->pack(-side=>'top',-fill=>'x');
# --- populate top level menu buttons in the menu frame
my $menu_file = $menu_f->Menubutton
(-text=>'File',-tearoff=>'false')
->pack(-side=>'left');
my $menu_configure = $menu_f->Menubutton
(-text=>'Configure',-tearoff=>'false')
->pack(-side=>'left');
my $menu_help = $menu_f->Menubutton
(-text=>'Help',-tearoff=>'false')
->pack(-side=>'left');
my $label_repo_path = $menu_f->Label # maybe display current repo pat
+h?
# in main window of the applicat
+ion?
(-textvariable => \$repo_filepath)
->pack(-side=>'right');
#---- "Configure" Button options only ---
#---- The menu buttons for 'File' and 'Help' will do nothing at all!
$menu_configure->command (-label=>'Option A',
-command => \¬_implemented
);
#--- the "Repo" option has a cascade of menu options
my $repo_level2 = $menu_configure->cascade( -label => 'Repo',
-tearoff=>'false');
$repo_level2->command(-label => "Valdidate Repo",
-command => \¬_implemented
);
$repo_level2->command(-label => "Change Repo PathName",
-command => \¬_implemented
);
$repo_level2->command(-label => "Back up Repo",
-command => \¬_implemented
);
# continuing with other 'Config' options .....
+
$menu_configure->command (-label=>'Option C',
-command => \¬_implemented
);
#--- end of menu options
MainLoop();
sub not_implemented {
my $response = $mw->messageBox(
-title => $STD_TITLE,
-message => "You wish this feature worked!! Sorry!!!\n\n",
-type => 'Ok');
}
Update:
I will engage in some "mind reading" because your requirement statement is so unclear.
The standard paradigm for GUI's is that you "left click" on something to
perform some action. I show a very common high level menu. To "configure", you left click on "Configure". That click shows a
drop down menu of options. If you want A or C, you click on that. Option B is "special" and you see that by the displayed
right arrow (a cascaded menu). If you just "hover" the mouse over option B, "Repo", that automatically displays the sub-options that you can click upon.
If you somehow think that hovering over "Change Repo Name" should display a complex interactive dialog automatically, I think you are
"barking up the wrong tree". I think that it is proper for you to have to actually click upon "Change Repo Name" for that dialog
to appear. The menu should make it easy to navigate to the functionality that you want. "Implementing the actual functionality" should
require a click.
So I see your question as two parts:(a) Cascaded menus and (b) Implementing "pop up" window for a complex user interaction. For
me, those are completely separate things. I guess that almost anything is possible with a GUI design. My advice again is: don't make
it more complicated than it needs to be.
|