quest #11007 Is it possible to add usage relations to the collaboration diagrams for properties? #11008
Conversation
…aboration diagrams for properties? Adding to `DOT_UML_DETAILS the possibilities: - `NONE_FLD` same as `NONE` - `NONE_ATTR`, Doxygen will not generate attributes on the edges between the classes in the UML graphs. - `NONE_ATTR_FLD`, Doxygen will not generate fields with class member information nor attributes on the edges between the classes in the UML graphs.
| If the \c DOT_UML_DETAILS tag is set to \c NONE_ATTR, Doxygen will not generate | ||
| attributes on the edges between the classes in the UML graphs. | ||
| If the \c DOT_UML_DETAILS tag is set to \c NONE_ATTR_FLD, Doxygen will not generate | ||
| fields with class member information nor attributes on the edges between the classes in the UML graphs. |
There was a problem hiding this comment.
I find it hard to understand these options. Especially since the documentation now says what doxygen doesn't show, not what it does show. I think the original NO and YES was meant to control if detailed information about type and arguments was shown or not. Then NONE was added to show no field data at all. With these new options, I'm a bit lost as to what will be shown.
There was a problem hiding this comment.
Some thoughts
When we look at the image:
We see here a number of items:
- What I call fields (FLD):
- in the class
other- publicMethod();
- privateMethod();
- mPrivateMember;
- in the class
main- other()
- privateMethod();
- in the class
- What I call attributes (ATTR)
- between the classes
otherandmain(along the edge):- mOther;
- between the classes
Currently (doxygen 1.11.0) the option NONE will remove the fields but not the attributes.
With this proposed PR (derived from #11007) a more granular approach is possible:
NONEunchanged for consistencty with the older versionsNONE_FLDis identical toNON, added for simularity / consistency with the other added optionsNONE_ATTRthe attributes are removedNONE_ATTR_FLDboth the attributes and fields are removed (so as actually requested in Is it possible to add usage relations to the collaboration diagrams for properties? #11007)
When the NONE should also have removed the attributes in the past (and this is now considered as a bug) we can update the PR to reflect this (and not add the new options).
I don't get the:
Especially since the documentation now says what doxygen doesn't show, not what it does show.
It is not that unclear to me.
Thinking about it we could change the formulation a bit
NONEshow only the attributes on the edges between the classes in the UML graphsNONE_ATTRshow just the fields of the classes in the in the UML graphs.
Maybe a possibility to change the NONE_ATTR in FLD, NONE_FLD in ATTR but home to call the current NONME and the proposed NONE_ATTR_FLD?
There was a problem hiding this comment.
What you call fields, in UML are called attributes, and what you call attributes, in UML are called dependencies 😉. See here for instance.
So I think we have the following (existing) levels of details:
- ALL (YES): show attributes with types and parameters
- COMPACT (NO): show attributes without types and parameters
- NONE: show no attributes
For each of the detail levels, the relation labels could be shown or hidden. Instead of adding 3 new values to the existing option, it is then probably better to add a new option DOT_UML_RELATIONS. But I'm also not so sure that this actually solves the original problem. Didn't the user want to show the relations even when EXTRACT_PRIVATE is disabled?
There was a problem hiding this comment.
Thanks for correcting the terminology, the terms I used were in respect to UML a bit confusing (when there is no explanation given. Maybe even operations should be introduced into the possibilities. Nice referenced page).
the user stated:
I would like to be able to generate a collaboration diagram that includes usage relations but does not show the private members and methods.
But at the moment that EXTRACT_PRIVATE=NO there is "no" relation between the classes main and Other anymore based on dependencies but there are still relations between main and Other namely based on the return types of some operations (her probably other() would use the private member) and on the Q_PROPERTY(and this is not the case in the example but it might also be that the arguments of theoperations` contain the other class name).
- The idea about
DOT_UML_RELATIONSis a nice idea but indeed doesn't solve the original request this setting though would give more flexibility (and probably less confusion compared to my implementation) - what to do with the
operations? - what to do with the return types and argument types?
Adding to `DOT_UML_DETAILS the possibilities:
NONE_FLDsame asNONENONE_ATTR, Doxygen will not generate attributes on the edges between the classes in the UML graphs.NONE_ATTR_FLD, Doxygen will not generate fields with class member information nor attributes on the edges between the classes in the UML graphs.Example: example.tar.gz