OMNET feature request

[Mani Amoozadeh]

Qtenv filter window button in the log window cannot show partial selection (like a square).

For example, even if I select the rip sub-module in router0, the filter window shows a clear selection for router1.

[Attila Török]

Hi!

I think this is expected, and after a bit of explanation, even reasonable.

You see, the regular pattern of compound modules only providing structure but not behavior (therefore being unable to output log messages), and simple modules only being leaves of the hierarchy (therefore not having submodules) is a very common and good practice, but is not at all enforced.

Compound modules can have custom behavior attached to them via the @class property (the new 802.11 implementation in INET 4.0 does this extensively), and simple modules can spawn submodules dynamically (at the very least some OMNeT++ test simulations do this). These are both valid, if rare, use cases. The distinction of "compound" and "simple" modules somewhat disappears once the network gets built at runtime, it is only really relevant at the NED language level (AFAIK), as a guide to model designers.

If, according to your suggestion, the inner nodes of the module tree in this dialog showed a "partially checked" state, purely based on the state of their descendants, it couldn't show whether or not the actual inner component has its log output suppressed or not.

It is true that since toggling the state of an inner node recursively sets the same state for all its descendants, it may be expected that it will display a partially checked state if the descendants have mixed states, but really, this recursive setting feature is mostly just for convenience.

I understand that this might be confusing at first, and it could be improved, but I don't think this partially checked state would be a proper way of doing it. Do you have an alternative suggestion, in light of the above?

Attila

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/omnetpp.
For more options, visit https://groups.google.com/d/optout.

[Attila Török]

Now that I have thought about it a bit more, maybe the partially checked (greyed-out) state would indeed be a good solution to this, because that is the most likely expected behavior, and it works in the common case. But first we'll have to find a nice way of indicating the actual enablement state of the internal nodes themselves, independent of the checkbox. Anyways, since we don't think this issue is of particularly high priority, for now I've only created a bug report, just so we won't forget about it: https://dev.omnetpp.org/bugs/view.php?id=1036

Thanks for your feedback!
Attila

[Mani Amoozadeh]

Ok, thanks Attila,

 

Another issue I noticed in the INET framework is that although I only select aodv module in the filter window, the log messages related to the mobility is also shown!

I am not sure if this is a bug from the omnet++ side or an issue in INET. In later case, I guess I need to submit an issue to INET github.

 

 

As you can see, the mobility module in node1 is unchecked in the filter window.

 

 

- Mani

--
You received this message because you are subscribed to a topic in the Google Groups "OMNeT++ Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/fkQkDilZJ0o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.

[Attila Török]

Every line (entry) printed into the log has two components (modules) associated with it: One is the module that processes the current event (message), and the other is that actually executes the logging statement. These two are the same module most of the time, except when the message-processing module makes a method call into an other module (annotated with Enter_Method()). I think this is often done by the mobility, and (again) the new 802.11 modules of INET.

The problem is that it's not clear which of these two associated modules is considered when doing the filtering. It seems that it is based on the module which does the event processing. These lines are visible because a module that is not filtered out makes some function calls into the mobility modules.
We will have to think about this (whether or not we want to keep it this way, or use a different filtering logic), then fix it if needed, finally document it, so there is no confusion anymore.
There are some other problems with this as well, for example lines printed during network initialization (when there is no event being processed, so there is only one associated module) sometimes have the same module path (that actually does the logging) prepended to them. Once we get to this, we should fix that too. I'll submit this too in our bug tracker.

Thank you again for your feedback,
Attila