Reto> I intend using tkined mainly for SNMP management.
Reto> For this, an SNMP MIB browser would be very helpful.
Reto> Has somebody already implemented such a thing for tkined?
It looks like nobody has done this job jet. There are two problems to
be solved: First, the MIB module needs a good interface that makes
implementation of a MIB browser simple and second, the tkined editor
has only very limited dialog capabilities. But see below...
Reto> For a specific application, I would like to write a new dialog
Reto> window for tkined. ined acknowledge, ined confirm, ined
Reto> request, ined browse and ined list all seem not to be
Reto> completely capable to serve my needs.
When writing tkined, I wanted to make dialogs very easy to use for
management script implementors. This is why tkined only supports five
dialog types. I know that more dialogs would be nice, but which
set of dialogs is generell to build most of our NM applications easily?
Reto> I would like to have something like a directory browser, with
Reto> an entry widget and a menu bar at the top and some buttons at
Reto> the right. I do not see, how the current dialog windows could
Reto> help me.
Right.
Reto> I would like to write a tk script with my new dialog window.
Reto> (As a matter of fact, I have already a rough version of it.)
Reto> But:
Reto> How could I possibly bind it into the tkined program?
There is no nice interface for this yet. The function ined() in
objects.c contains a list of known dialog names. To create a new
dialog called funny, just add the new name to the list:
static char *cmds[] = {
"acknowledge",
"confirm",
"request",
"browse",
"list",
"funny",
0
};
Now you have to write a proc tkined_funny that will be called whenever
the ined command `ined funny <args>' is received. Look in the file
tkined_dialog.tcl. An example may look like:
proc tkined_funny {c args} {
set w "$c.funny"
tkined_dialog_toplevel $w
# do what you like here
tkined_position $w $c
grab set $w
tkwait window $w
}
The first argument is the handle of the tkined canvas.
tkined_dialog_toplevel creates the dialog toplevel window.
tkined_position is used to move the dialog window on top of
the tkined canvas. Finally, the dialog window gets the grab
and we wait until the window is destroyed.
I think it would be a good idea to use a naming convention to get rid
of the modifications in objects.c. I would suggest to name all dialogs
like Dialog::confirm or Dialog::browse. This way, I could check for
new dialog types by testing if a proc with the right name exists. Any
comments?
Juergen