Skip to content
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.

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

[doc] Add ldoc @supermodule tag to draw inheritance diagram and manage inherited properties #3288

Merged
merged 17 commits into from
Apr 5, 2021

Conversation

Aire-One
Copy link
Member

This is a new implementation of the "let's draw a hierarchy diagram" thing I started with #3263. For this implementation, I used, as @Elv13 suggested, a new ldoc tag.

This adds a new ldoc tag: @supermodule. We can use it to indicate the module's supermodule. The logic to build the hierarchy tree and find supermodules contents is implemented in the template itself. I couldn't find a better solution and this is what was used in this other project (https://gricad-gitlab.univ-grenoble-alpes.fr/brenona/arcades/-/blob/master/assets/ldoc/ldoc.ltp#L24-56) I found while digging ldoc (lunarmodules/ldoc#293)...

Anyway, the last commit (4fee67d) is actually a POC, so you can easily see what this PR is about (to compare with https://awesomewm.org/apidoc/widgets/wibox.widget.textclock.html):

https://imgur.com/a/EBgVpuO
https://user-images.githubusercontent.com/6602958/111206863-3d66cc80-85c9-11eb-83ac-995f006b1951.png
(links as it was really long and kinda spam the page)

This isn't perfect and still needs some adjustments. The goal would be to completely remove the use of docs/common/object.ldoc and docs/common/widget.ldoc as the content of these file should be automatically added by inheritance.

Looking at the length of the final render, I think we probably shouldn't include all the descriptions and contents from supermodules. Maybe we could try another approach similar to what the Android API references does (for example: https://developer.android.com/reference/android/widget/ImageView, see the "Inherited *" sections). I'm open to feedbacks and suggestions 😄

Also, I'd like some inputs on how we should show the root classes (gears.object vs wibox.widget vs wibox.widget.base).
The wibox.widget.base.make_widget() function (used as a base for widgets) returns an instance of gears.object monkeypatched with the internal wibox.widget.base.widget properties and additional properties that we once called wibox.widget for docs/common/widget.ldoc...

@Elv13
Copy link
Member

Elv13 commented Mar 21, 2021

Nice work!

I think we should eventually add a commit to remove the "useless" methods from widget.widget.base. Right now we have both the visible property and the get_visible/set_visible methods. The methods are redundant since the gears.object magic turns them into properties.

Beside, I think we can merge this as-is and fix this in other PRs? I am trying to finish my old (over 1 years old...) PR to upgrade the landing page. With both of these merged (and the fix to have fewer methods), I am tempted to get 4.4 out of the door.

@Aire-One
Copy link
Member Author

Oops... Sorry @Elv13, I didn't realized you was asking for this PR to be ready ASAP because of the Travis issue and the migration to GitHub Actions can virtually block releases while we're working on it. Hence, we should do a release while we still have Travis credits.

I don't think it would be nice to have this PR on the release without the additional transition work to complete what I started with 4fee67d.

I also need to fix how I handled inheritance with wibox.widget and wibox.widget.base. And my "ldoc will automatically find inherited properties/methods" method also imply we do some clean up in the documentation comments to have a good result. As you mentioned, some methods are duplicated...

This shouldn't be too much work, and I'm slowly working on it. But I don't think I'll be able to deliver a proper update before Sunday.

So anyway, if we need to make a release now, I think we should skip this PR. If we can wait about 1 more week, I'll do my best to deliver!

@Elv13
Copy link
Member

Elv13 commented Mar 28, 2021

So anyway, if we need to make a release now, I think we should skip this PR. If we can wait about 1 more week, I'll do my best to deliver!

It isn't super urgent, I aim for May-ish. There is a lot of open bugs right now and some of them are totally worth fixing given how often we release stuff

@Aire-One Aire-One force-pushed the feature/ldoc-inheritance-diagram branch from 4fee67d to 0cb0c23 Compare March 28, 2021 17:41
@Aire-One
Copy link
Member Author

I have reworked my code and pushed the usage of @supermodule in most modules.

Looking my "gears.object vs wibox.widget vs wibox.widget.base" issue, I took the initiative to say I was wrong in commit 589908a and there is no such wibox.widget things. Widgets that are based on constructors from wibox.widget.base (e.g. wibox.widget.base.make_widget()) inherits from wibox.widget.base (and wibox.widget.base inherits from gears.object). This is what's the truest if you take a closer look at the code.

wibox.layout was another story, tho!
I skipped to work on the @DOC_fixed_COMMON@ and @interface documentation. The current render we have is good enough I think. Some items are marked as inherited because parents already implement them and some others are marked as native from the class because parents didn't implement them... Maybe a future PR will take care of this interface stuff...

I think we should eventually add a commit to remove the "useless" methods from widget.widget.base. Right now we have both the visible property and the get_visible/set_visible methods. The methods are redundant since the gears.object magic turns them into properties.

I added an ldoc tag @hiden. We can use it to dismiss items from being rendered in the documentation. I wasn't happy to destroy methods documentation even if you want to "force" the usage of gears.object magic. Maybe these @hiden items could be part of an "extendable" section called "See More stuff".

Anyway, I think I reached a point where this PR gives a good/reliable render and is used enough in the documentation to make sense.
Please pull the branch and see for yourself the documentation it generates. As always, I'm open to any feedbacks 😄

@codecov
Copy link

codecov bot commented Mar 28, 2021

Codecov Report

Merging #3288 (b184f95) into master (112dc80) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3288   +/-   ##
=======================================
  Coverage   88.66%   88.66%           
=======================================
  Files         701      702    +1     
  Lines       46643    46668   +25     
=======================================
+ Hits        41354    41377   +23     
- Misses       5289     5291    +2     
Flag Coverage Δ
gcov 75.24% <ø> (-0.02%) ⬇️
luacov 91.47% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
lib/awful/popup.lua 93.14% <ø> (ø)
lib/awful/tooltip.lua 91.95% <ø> (ø)
lib/awful/wibar.lua 80.79% <ø> (ø)
lib/awful/widget/button.lua 96.87% <ø> (ø)
lib/awful/widget/clienticon.lua 84.05% <ø> (ø)
lib/awful/widget/launcher.lua 100.00% <ø> (ø)
lib/awful/widget/layoutbox.lua 100.00% <ø> (ø)
lib/awful/widget/layoutlist.lua 90.78% <ø> (-0.66%) ⬇️
lib/awful/widget/only_on_screen.lua 94.64% <ø> (ø)
lib/awful/widget/prompt.lua 88.23% <ø> (ø)
... and 38 more

docs/config.ld Outdated Show resolved Hide resolved
@Aire-One Aire-One force-pushed the feature/ldoc-inheritance-diagram branch from 0cb0c23 to 8f85667 Compare March 28, 2021 20:45
@Elv13 Elv13 force-pushed the feature/ldoc-inheritance-diagram branch from 8f85667 to 3437e7b Compare March 29, 2021 07:42
@Elv13
Copy link
Member

Elv13 commented Mar 29, 2021

I tried this and it works great! I made a commit with a few more @supoermodule for the wibox based modules.

I also added another commit to ask for your opinion. Feel free to delete it the next time you rebase this is you don't like it. What about laying the Hierarchy/Info/See section horizontally?

image

Individually, they are not very wide. So I think it makes the page a little less intimidating? I am not 100% happy with how it looks, so alternatives are welcome.

Otherwise, everything seems great. If you want to merge this PR as it is and iterate to add more awesomeness, I am totally open to that.

@sclu1034
Copy link
Contributor

Individually, they are not very wide. So I think it makes the page a little less intimidating? I am not 100% happy with how it looks, so alternatives are welcome.

I quite like this one. Definitely less cluttered than the previous layout.
The only thing that bugs me about it, is the fact that each section has a different left margin/padding, but that should be easy enough to adjust.


One general issue I see is the fact that sometimes items are included as inherited when they aren't actually used.
For example, layout.flex and layout.ratio inherit layout.fixed.fill_space. This property is used in layout.fixed:layout, but since both layout.flex and layout.ratio implement their own :layout, they do not use that property (and set it to nil in their constructors).
So the fact that fill_space shows up in the docs for layout.flex and layout.ratio is misleading.

@Aire-One
Copy link
Member Author

(@Elv13 I'm not sure why I had to rebase the whole branch to correctly merge your 2 commits. Did you apply modification on others commits? I can't see differences...)

Individually, they are not very wide. So I think it makes the page a little less intimidating? I am not 100% happy with how it looks, so alternatives are welcome.

I quite like this one. Definitely less cluttered than the previous layout.
The only thing that bugs me about it, is the fact that each section has a different left margin/padding, but that should be easy enough to adjust.

I actually like it too!
This margin/padding issue will definitely not be hard to fix, but the hierarchy diagram will most probably require something similar to margin: -14px and I'm a little lazy to try that now...
Also, I'm concerned about how this 3 columns design will scale on "less wide browsing". I usually have the doc tiled on the left side of my screen. Here is how it looks currently for half my screen (1920x1080, so about 960px wide)

image

One general issue I see is the fact that sometimes items are included as inherited when they aren't actually used.
For example, layout.flex and layout.ratio inherit layout.fixed.fill_space. This property is used in layout.fixed:layout, but since both layout.flex and layout.ratio implement their own :layout, they do not use that property (and set it to nil in their constructors).
So the fact that fill_space shows up in the docs for layout.flex and layout.ratio is misleading.

I think we can fix that by overriding the property with a @property block and hide it with @hidden.

@Aire-One
Copy link
Member Author

One general issue I see is the fact that sometimes items are included as inherited when they aren't actually used.
For example, layout.flex and layout.ratio inherit layout.fixed.fill_space. This property is used in layout.fixed:layout, but since both layout.flex and layout.ratio implement their own :layout, they do not use that property (and set it to nil in their constructors).
So the fact that fill_space shows up in the docs for layout.flex and layout.ratio is misleading.

I think we can fix that by overriding the property with a @Property block and hide it with @hidden.

My implementation to hide a member in the documentation was incompatible with override members. I added a quick fixup commit to use another approach, more flexible (in regard to "override items to hide them"), but more ugly...

Hiding the property with an override in wibox.layout.flex (as I did in my second commit) was even smarter than expected as it also automatically hide it for wibox.layout.ratio. The property in ratio actually comes with the tag @hidden already sets, as it's inherited from flex (i.e. not from fixed).

@sclu1034
Copy link
Contributor

Suggestion to wrap flex-wrap the horizontal sections:

image

The important change is

diff --git a/docs/ldoc.css b/docs/ldoc.css
index a51fb80b..18544e54 100644
--- a/docs/ldoc.css
+++ b/docs/ldoc.css
@@ -522,8 +522,9 @@ pre .url { color: #272fc2; text-decoration: underline; }
 .extra_header_box {
     display: flex;
     flex-direction: row;
+    flex-wrap: wrap;
 }
 
 .extra_header_section {
-    flex: 1;
+    flex-grow: 1;
 }

I also replaced the nested <ul>s with a simpler <div> structure, so my full patch is

diff --git a/docs/ldoc.css b/docs/ldoc.css
index a51fb80b..436dcd9b 100644
--- a/docs/ldoc.css
+++ b/docs/ldoc.css
@@ -505,25 +505,21 @@ pre .url { color: #272fc2; text-decoration: underline; }
 }
 
 /* Inheritance diagram */
-.inheritance .inheritance__level {
-    list-style: none;
+.inheritance {
+    margin-bottom: 15px;
+    margin-left: 15px;
 }
 
-.inheritance .inheritance__level__node::before {
-    content: "↳";
-}
-
-.inheritance .inheritance__level__node--root::before {
-    /* simulate the spacing of the arrow character */
-    content: "   ";
-    white-space: pre;
+.inheritance .inheritance__level > .inheritance__level {
+    margin-left: 30px;
 }
 
 .extra_header_box {
     display: flex;
     flex-direction: row;
+    flex-wrap: wrap;
 }
 
 .extra_header_section {
-    flex: 1;
+    flex-grow: 1;
 }
diff --git a/docs/ldoc.ltp b/docs/ldoc.ltp
index 9ccfff00..1a0c0b7a 100644
--- a/docs/ldoc.ltp
+++ b/docs/ldoc.ltp
@@ -199,12 +199,9 @@
     <h3>Class Hierarchy</h3>
     <div class="inheritance">
 # local function draw_hierary_recursifly(i)
-    <ul class="inheritance__level">
-#   if i == #hierarchy then
-        <li class="inheritance__level__node inheritance__level__node inheritance__level__node--root">
-#   else
-        <li class="inheritance__level__node inheritance__level__node">
-#   end
+    <div class="inheritance__level">
+        <span>
+            <span>↳</span>
 #   local mod = hierarchy[i]
 #   local name = display_name(hierarchy[i])
 #   if mod == module then
@@ -212,13 +209,11 @@
 #   else
             <a href="$(ldoc.ref_to_module(mod))">$(name)</a>
 #   end
-        </li>
+        </span>
 #   if i > 1 then
-        <li>
-#           draw_hierary_recursifly(i - 1)
-        </li>
+#       draw_hierary_recursifly(i - 1)
 #   end
-    </ul>
+    </div>
 # end -- module.tags.supermodule
 # draw_hierary_recursifly(#hierarchy)
     </div>

Aire-One and others added 16 commits April 2, 2021 19:24
This commit adds a new ldoc custom tag `@supermodule`. It has to be
used at the module level. It should refer to the module
supermodules.

This tag can be used multiple time by the same module, but we ignore
other calls (for now?) as (AFAIK) we only use one way inheritance.

This tag is used in the ldoc template to find modules hierarchy and
draw the inheritance tree. It makes it easy to find and navigate to
parents modules.
This commit uses the `@supermodule` tag to recursively find all the
properties from supermodules and add them to the current module
documentation.
For some reasons, sometime `item.inherited` is `false` even if the
item was added to the `all_module_kinds` table by the "hierarchy
lookup" for-loop, and we already force the `inherited` property to be
sets to `true` at this moment.

With this commit, we add a second fail-check condition based on the
`item.baseclass` property to determine if the item is inherited or not
when we do the render.
Add a new ldoc tag `@hidden`. This tag allows us to keep documentation
for magic methods (e.g. `wibox.widget.base:get_visible`) but prevent
it from being part of the documentation used by final users.
For some even more strange reasons than commit 047729a, it seems
we can also have the error that `item.inherited` can be sets to `true`
on items that are not inherited...

I just had this issue with `wibox.widget.imagebox` where properties
were marked as inherited from `wibox.widget.imagebox`. Best way to fix
it is to only trust the check on `item.baseclass`, and completly
dismiss its `inherited` property.
Co-authored-by: Lucas Schwiderski <lucas@lschwiderski.de>
Co-authored-by: Aire-One <Aire-One@users.noreply.github.com>
Add an explicite `@property` tag to the `wibox.layout.flex` doc
comments to override the `fill_space` property from
`wibox.layout.fixed` and mark it as hidden thanks to `@hidden`.
@Aire-One Aire-One force-pushed the feature/ldoc-inheritance-diagram branch from 4c45021 to b184f95 Compare April 2, 2021 18:06
@Aire-One
Copy link
Member Author

Aire-One commented Apr 2, 2021

@sclu1034, I have kept your first diff about flex wrapping. I think nested lists are better to draw trees with a regard to data structure and accessibility, tho, so I dismissed the second part.

@Elv13 I have changed in your extra-header feature the class name to better match BEM naming convention (http://getbem.com/naming/) and I used div instead of span for the extra-header sections because span shouldn't be used as container.

As a side note, I have also clean up the commits history and rebase on current master.

If we don't have more changes request or places where @supermodule and @hidden tags should be added, I think this PR is ready to be merged now. Further improvements (and places where we forgot new tags) can be added later, I guess.

@Elv13 Elv13 merged commit 3dddc2b into awesomeWM:master Apr 5, 2021
@Elv13
Copy link
Member

Elv13 commented Apr 5, 2021

Thanks a lot for this!

@Elv13
Copy link
Member

Elv13 commented Apr 5, 2021

The doc has been regenerated using this. Overall, it seems to work. Some pages like https://awesomewm.org/apidoc/core_components/screen.html will need some fixup, it seems some tag don't close. I also managed to introduce some broken link in the landing page https://awesomewm.org/apidoc/index.html, I will fix that next week

@actionless
Copy link
Member

this class hierarchy thing is really cool 👍

@Aire-One
Copy link
Member Author

Aire-One commented Apr 5, 2021

Some pages like https://awesomewm.org/apidoc/core_components/screen.html will need some fixup, it seems some tag don't close.

@Elv13 I think I closed one <div> tag too much when there is no extra-header for hierarchy... I'll take a look at that now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants