8000 quest #11007 Is it possible to add usage relations to the collaboration diagrams for properties? by albert-github · Pull Request #11008 · doxygen/doxygen · GitHub
[go: up one dir, main page]
Skip to content

quest #11007 Is it possible to add usage relations to the collaboration diagrams for properties? #11008

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

quest #11007 Is it possible to add usage relations to the collaboration diagrams for properties? #11008

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion src/config.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3888,15 +3888,22 @@ If the \c DOT_UML_DETAILS tag is set to \c NO, Doxygen will
show attributes and methods without types and arguments in the UML graphs.
If the \c DOT_UML_DETAILS tag is set to \c YES, Doxygen will
add type and arguments for attributes and methods in the UML graphs.
If the \c DOT_UML_DETAILS tag is set to \c NONE, Doxygen will not generate
If the \c DOT_UML_DETAILS tag is set to \c NONE or \c NONE_FLD, Doxygen will not generate
fields with class member information 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.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some thoughts

When we look at the image:
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();
  • What I call attributes (ATTR)
    • between the classes other and main (along the edge):
      • mOther;

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:

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

  • NONE show only the attributes on the edges between the classes in the UML graphs
  • NONE_ATTR show 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?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

8000
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_RELATIONS is 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?

The class diagrams will look similar to the default class diagrams but using
UML notation for the relationships.
]]>
</docs>
<value name="NO" />
<value name="YES" />
<value name="NONE" />
<value name="NONE_FLD" desc='same as NONE'/>
<value name="NONE_ATTR" />
<value name="NONE_ATTR_FLD" />
</option>
<option type='int' id='DOT_WRAP_THRESHOLD' defval='17' minval='0' maxval='1000' depends='HAVE_DOT'>
<docs>
Expand Down
9 changes: 8 additions & 1 deletion src/dotnode.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -424,7 +424,9 @@ void DotNode::writeLabel(TextStream &t, GraphType gt) const
t << "<<TABLE CELLBORDER=\"0\" BORDER=\"1\">";
t << hr_start << convertLabel(m_label,true) << hr_end;
auto dotUmlDetails = Config_getEnum(DOT_UML_DETAILS);
if (dotUmlDetails!=DOT_UML_DETAILS_t::NONE)
if (dotUmlDetails!=DOT_UML_DETAILS_t::NONE &&
dotUmlDetails!=DOT_UML_DETAILS_t::NONE_FLD &&
dotUmlDetails!=DOT_UML_DETAILS_t::NONE_ATTR_FLD)
{
bool lineWritten = false;
t << sep;
Expand Down Expand Up @@ -609,6 +611,11 @@ void DotNode::writeArrow(TextStream &t,
t << ",tooltip=\" \""; // space in tooltip is required otherwise still something like 'Node0 -> Node1' is used
if (!ei->label().isEmpty())
{
if (!(Config_getBool(UML_LOOK) &&
(Config_getEnum(DOT_UML_DETAILS)==DOT_UML_DETAILS_t::NONE_ATTR ||
Config_getEnum(DOT_UML_DETAILS)==DOT_UML_DETAILS_t::NONE_ATTR_FLD) &&
(gt==Inheritance || gt==Collaboration))
)
t << ",label=\" " << convertLabel(ei->label()) << "\",fontcolor=\"grey\" ";
}
if (Config_getBool(UML_LOOK) &&
Expand Down
Loading
0