On Mon, 16 Jan 1995 22:21:59 -0500,
"John P. Rouillard" <rouilj@dstar.iddis.com> said:
John> I am generating a monitoring system that needs to look at specific
John> processes on a number of systems. What I would like to have is to make
John> the icons representing the systems and processes have attached menus
John> so that I can call up the menu by double clicking with the left mouse
John> button. I figure that the attribute "post-menu" can be read on a
John> double click and its value would name the menu.
I think something like that will appear sooner or later, but I have
not decided how to do it. I would like to associate MENU objects with
other tkined objects. The problem is (besides some coding time) that
there must be a way to control which menu goes where. I would like to
see this kind of stuff done by tkined itself to keep scripts simple.
Obe way to go would be to implement some drag&drop stuff which would
allow you to take a menu and move it to a node or something like
that. But what happens if your create a new node or another script?
How should tkined remember where menus go if you load a saved map?
This touches a very general problem: The current way to handle and
store configuration options needs to be revised. (I am very unhappy
with the current approach: Something is in the tkined.defaults file,
some things are stored in attributes, other things are maintained by
the scripts themself) All ideas on how to get a general and easy to
use/understand mechanism are really welcome.
John> Also it would be nice if there was a way to lock the tkined
John> graph.
This will be in the tk4.0 release.
John> Is there any way to automatically set various attributes when adding
John> new nodes?
I already mentioned that I have added dialogs to set/modify/delete
attributes on all selected objects. This will be ok for most cases.
If you need more default attributes, just write a small script like:
proc "Init Attributes" {list} {
foreach comp $list {
catch {ined attribute [ined id $comp] "Serial No." " "}
}
}
John> Also different link designators/types, e.g. dashed lines, dashed and
John> dotted etc. would be useful. I have serial connections from some hosts
John> going into a terminal server that need to be represented on a black
John> and white screen, and in printouts. Sadly changing the color of the
John> links just doesn't quite do it, but a different link pattern would do
John> nicely. This could also be used for networks as well, since telling
John> line widths apart can be somewhat tricky.
I did some experiments some time ago to get dotted lines, but tk does
not support dotted lines directly. The only way to get them is to use a
stiffle bitmap. I remember that those lines locked quite ugly. I did
not check if there is a better way to get dashed lines with tk4.0.
John> Would it be possible to allow groups within groups? By this I mean a
John> strict heirarchy. If group a is within group b, then all elements of
John> group a are in group b. There are no elements of group a that wouldn;t
John> be in group b.
This should already work.
John> What would also be nice is to allow the references to be linked into
John> maps as nodes. Also all of the group bitmaps should be usable as
John> bitmaps for references. This way I could create a map of groups and
John> pull up new tkined maps for the group expansions. One major problem I
John> have is that group expansions always take up more room than the group
John> icon, and when expanded invariably collide with other things drawn on
John> the map. Using the refernces and allowing them to be linked is an easy
John> way of representing groups that pop up new tkined screens with their
John> own monitoring tools. I see no reason the "expanding groups" paradigm
John> couldn't be used on a "reference group" as well. Expansions on groups
John> would have to be defined a bit differently depending on whether the
John> group is a real group, or a reference, but that should be easy enough.
Perhaps. There are really some reasons to merge groups and reference
objects, but you wont get links to reference objects this way: a group
object never has a link. The link you are seeing is just the
representation of all the links going from outside into the group
(which I think is the right way - there is no way to plug something
into all hosts of a subnetwork). Getting links to point to reference
objects would require to support link objects between nodes/networks
in different tkined maps.
John> Also is it possible to traverse the host to group mapping so
John> that the group icons could also be flashed when a host inside
John> the group is flashing/changing color? Setting the propigate
John> attribute on the group icon/border could be the flag that
John> allows this.
This is not very difficult, perhaps it should be the default
behaviour. The problem with those attributes that control how
something works is that we start to get large attribute lists that
control things from tkined internals (how flashing is propagated) to
very specific things (like interface speeds). And setting the
propagate attribute on every new group will get us back to the your
wish for preset attributes, I guess.
John> Obviously this wouldn't work with "reference groups", or would
John> it? Is there some way for the new tkined process to know what
John> the original reference and interpreter was so that it could
John> flash that node?
No, this would require that the reference object knows something about
the objects it is pointing to. (There may be ways do get this information,
but better think of it as impossible :-)
John> Also has anybody figured out a way to set thresholds on individual
John> components of rstat bar graphs? I would really like a notification
John> when swapin/swapout goes above 0, but setting thresholds trigers when
John> any value goes above 0.
This one is easy: Set the threshold value to a vector containing as many
elements as you have bars. This should do the job.
John> Well I guess that's enough for now, I'm tired 8-).
Thanks for your input, staying awake so long and waiting even longer
for an answer,
Juergen