Re: RFR: JDK-8277420: Provide a way to copy the hyperlink to a doc element to the clipboard [v2]
On Mon, 23 May 2022 19:09:41 GMT, Hannes Wallnöfer wrote: >> This is a CSS/JavaScript only change to implement copy-to-clipboard >> functionality for all headers (`h1` - `h6`) that have an `id` attribute >> associated with them. The following element-attribute patterns are supported >> (using `` as an example): >> >> - `` (generated by javadoc) >> - `` (commonly used) >> - `` (legacy) >> >> The change includes a consolidation of the CSS styles used to render >> copy-to-clipboard buttons, of which we have now three kinds: for snippets, >> for the link on the search page, and for headers. There is now a base CSS >> class called "copy" that defines the styles shared by all copy-to-clipboard >> buttons, and additional CSS properties for the concrete "subclasses". >> >> API docs generated with this change can be viewed here (top level files and >> java.base module): >> http://cr.openjdk.java.net/~hannesw/8277420/api.03/ > > Hannes Wallnöfer has updated the pull request incrementally with one > additional commit since the last revision: > > Fix jquery selector for anchor within header Code: * Your JavaScript code looks very readable to me, and I don't know JavaScript; nice. * Don't forget to update the copyright years. UI: * Consider using a different icon for the button that copies a link. From what I've seen, icons depicting chain links are typical ( e.g. https://graphicdesign.stackexchange.com/questions/132106/what-is-the-most-intuitive-and-obvious-copy-link-icon ) * When the header button appears, the text on the page shifts a bit. Look closely and you'll see it. Don't know if it could be fixed easily, though. Looks good. - Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8817
Re: RFR: JDK-8277420: Provide a way to copy the hyperlink to a doc element to the clipboard [v2]
On Mon, 23 May 2022 19:09:41 GMT, Hannes Wallnöfer wrote: >> This is a CSS/JavaScript only change to implement copy-to-clipboard >> functionality for all headers (`h1` - `h6`) that have an `id` attribute >> associated with them. The following element-attribute patterns are supported >> (using `` as an example): >> >> - `` (generated by javadoc) >> - `` (commonly used) >> - `` (legacy) >> >> The change includes a consolidation of the CSS styles used to render >> copy-to-clipboard buttons, of which we have now three kinds: for snippets, >> for the link on the search page, and for headers. There is now a base CSS >> class called "copy" that defines the styles shared by all copy-to-clipboard >> buttons, and additional CSS properties for the concrete "subclasses". >> >> API docs generated with this change can be viewed here (top level files and >> java.base module): >> http://cr.openjdk.java.net/~hannesw/8277420/api.03/ > > Hannes Wallnöfer has updated the pull request incrementally with one > additional commit since the last revision: > > Fix jquery selector for anchor within header Ensure TestSnippetUnnamedPackage passes before integrating. - PR: https://git.openjdk.java.net/jdk/pull/8817
Re: RFR: JDK-8268422: Find a better way to select releases in "New API" page
On Tue, 17 May 2022 08:57:54 GMT, Hannes Wallnöfer wrote:
>> test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java line 1089:
>>
>>> 1087: content = null;
>>> 1088: } else {
>>> 1089: name = outputDir + "/" + file;
>>
>> I'm trying to understand the merit of this, since the output directory is
>> often just `out` or `api` isn't it? Don't you want the test method name in
>> there, for increased resolution?
>
> For test classes containing multiple test methods the output directory is
> actually the best way to identify which run of javadoc generated the output.
> If a test were to do multiple runs of javadoc with the same output directory
> I would certainly consider it a serious bug. Also, a single test method could
> easily do multiple runs of javadoc (I'm not sure we do that in our test
> suite, but I wouldn't be too surprised). Adding the output directory
> disambiguates the file name which is already there, making it easy to locate
> the file itself and the code that generated it.
OK; just verify it doesn't break existing tests!
-
PR: https://git.openjdk.java.net/jdk/pull/8657
Re: RFR: JDK-8268422: Find a better way to select releases in "New API" page
On Thu, 26 May 2022 23:36:29 GMT, Jonathan Gibbons wrote: >> For test classes containing multiple test methods the output directory is >> actually the best way to identify which run of javadoc generated the output. >> If a test were to do multiple runs of javadoc with the same output directory >> I would certainly consider it a serious bug. Also, a single test method >> could easily do multiple runs of javadoc (I'm not sure we do that in our >> test suite, but I wouldn't be too surprised). Adding the output directory >> disambiguates the file name which is already there, making it easy to locate >> the file itself and the code that generated it. > > OK; just verify it doesn't break existing tests! > I'm trying to understand the merit of this, since the output directory is > often just `out` or `api` isn't it? Don't you want the test method name in > there, for increased resolution? I guess the simple filename of the output directory is often `out` or `api`, but the filename relative to the current directory is (or should be) unique. - PR: https://git.openjdk.java.net/jdk/pull/8657
Re: RFR: JDK-8268422: Find a better way to select releases in "New API" page
On Wed, 11 May 2022 16:42:14 GMT, Hannes Wallnöfer wrote: > This is a conceptually simple change, but it has a few ramifications that > make it at least look a bit bigger than it is. > > At the core, this adds a new method to the `Table` class that allows to > generate tables with multiple categories but omit the generation of table > tabs. This is used in the "New API" and "Deprecated API" pages to render the > release selectors as a global row of checkboxes that control release > information for all tables in the page. Also, the element name and release > columns in those pages are now sortable by clicking on the table headers. > > Output generated with this change is available here: > > http://cr.openjdk.java.net/~hannesw/8268422/api.06/new-list.html > http://cr.openjdk.java.net/~hannesw/8268422/api.06/deprecated-list.html > > Now to the details and aforementioned ramifications: > > - Since I added new functionality to the table class I thought it woudl be a > good occasion to remove some other functionality that was never really used > by our code. This includes the possibility to set the table tab and striped > row styles. We always use the default styles for these, and if somebody > wanted to change the look of the styles the way to go would be to change the > style definitions in the stylesheets rather then the style names. This change > made the inclusion of a table-specific script obsolete, so you'll see some > removals of `table.needsScript()` and `table.getScript()` in unrelated code. > - `SummaryListWriter`, the base class for the New API and Deprecated API > pages, gets a few new protected methods that are overridden in subclasses to > generate the extra content as needed. I think the solution is suboptimal and > a bit noisy. The protected classes have generic names such as > `getExtraContent` and the parent class is not really aware of the different > releases, since one subclass never displays multi-release information > (Preview API), one does sometimes (Deprecated API) and one does always (New > API). I think we could come up with a nicer solution, but I think it's not > terrible and didn't want to delay integration too much. > - We have yet more JavaScript for global table category selection and > sortable table columns as well as new CSS classes, including inlined SVGs for > the sortable column icons. I tried to keep the additions as small and clean > as possible and added a short comment for each function. > - The changes in `TestNewApiList.java` are huge. I couldn't have made those > changes without improving the output of `JavadocTester` by adding the output > directory to the test name. This change makes it much easier to read jtreg > output for tests with many similar but slightly different checks. I probably > should have done this a long time ago! The text blocks in testNewApiList.java are a bit overwhelming. Perhaps we could (separately) find a way to improve that later on. - Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8657
