escet issueshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues2024-03-26T17:00:16Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/795Windows Defender SmartSreen window on first-time startup of ESCET2024-03-26T17:00:16ZMartijn GoordenWindows Defender SmartSreen window on first-time startup of ESCETWhen I was testing out the changes for !841, I run that version (downloaded from https://ci.eclipse.org/escet/job/ESCET%20build/job/MR-841/3/) on the Windows Server we are using within Rijkswaterstaat. With this new version, I got a Wind...When I was testing out the changes for !841, I run that version (downloaded from https://ci.eclipse.org/escet/job/ESCET%20build/job/MR-841/3/) on the Windows Server we are using within Rijkswaterstaat. With this new version, I got a Windows Defender SmartScreen window on the first-time startup of this ESCET version. See screenshot below. Only after clicking `More info` will there be the button `Run anyway` to start ESCET. After this first time, this window doesn't pop-up any longer.
![Screenshot_2024-03-26_at_11.38.08](/uploads/fd5a8705ed9797c364369805206e312a/Screenshot_2024-03-26_at_11.38.08.png)
I'm used to seeing such a screen on my MacBook, but this was the first time seeing it on a Windows machine. We are running Windows Server 2019 Standard, Version 1809.
Can another Windows user confirm whether they get this message with the latest ESCET version (maybe check for the upcoming release candidate)? If this is something new for Windows, we should include additional instructions on our download page.v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/793Add ESCET logo to ESCET IDE launchers for Linux and macOS2024-03-26T13:05:43ZDennis HendriksAdd ESCET logo to ESCET IDE launchers for Linux and macOSWe added it for the Windows launcher in #791.
Next steps:
* [ ] For Linux, we need an XPM icon. Add the icon to the `misc/escet-logo` folder and to the product.
* [ ] For macOS, we need an ICNS icon. Add the icon to the `misc/escet-logo...We added it for the Windows launcher in #791.
Next steps:
* [ ] For Linux, we need an XPM icon. Add the icon to the `misc/escet-logo` folder and to the product.
* [ ] For macOS, we need an ICNS icon. Add the icon to the `misc/escet-logo` folder and to the product.
Both should contain the ESCET logo in various resolutions.
See also:
* https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/840#note_1986938 for how it looks on Windows.
* https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/840#note_1986935 for the formats the Windows icon contains.
* https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/840#note_1986942 for some ideas on which tools to use to make the icons for Linux/macOS.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/791Use ESCET logo in relevant places2024-03-26T07:22:21ZDennis HendriksUse ESCET logo in relevant placesWe're close to having a logo in #777. Once we have it, we should use it in the appropriate places. For now, I foresee the following places:
- [x] ESCET website (!838)
- ESCET logo on ESCET home page.
- ESCET favicon for the ESCET st...We're close to having a logo in #777. Once we have it, we should use it in the appropriate places. For now, I foresee the following places:
- [x] ESCET website (!838)
- ESCET logo on ESCET home page.
- ESCET favicon for the ESCET static website pages (the yellow pages), like already there for CIF, etc.
- ESCET favicon for the ESCET general toolkit documentation and the development documentation, like already there for other docsets.
- Add icons in the site selector dropdown (the one from the top bar, on the very left enty of that bar, to select different websites ESCET/CIF/etc).
- [x] ESCET IDE (!840)
- Change the splash screen image.
- Change the about screen image.
- Change the welcome screen image.
- Change the icon of the ESCET perspective.
- Change the 'feature image'.
- Change the 'window images'.
- Add an executable icon (for Windows). We currently don't have one yet, and thus get the generic Eclipse icon.
- [x] Project website / PMI
- [x] Add the logo to https://projects.eclipse.org/projects/technology.escet. See also https://www.eclipse.org/projects/handbook/#promoting-project-logo.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/721Show build id and progress on ESCET IDE splash screen2024-03-14T08:35:21ZDennis HendriksShow build id and progress on ESCET IDE splash screenWe do not currently show the progress on the splash screen. We also do not show the build id.
Splash screen documentation, including showing progress information:
* Some basic information: https://www.davidpace.de/adding-custom-splash-s...We do not currently show the progress on the splash screen. We also do not show the build id.
Splash screen documentation, including showing progress information:
* Some basic information: https://www.davidpace.de/adding-custom-splash-screens-for-eclipse-products/
* Some official documentation: https://wiki.eclipse.org/Platform-releng/Updating_Branding
Information about showing the build id:
* Example: https://git.eclipse.org/c/platform/eclipse.platform.git/tree/platform/org.eclipse.sdk/plugin_customization.ini
* Forum post: https://www.eclipse.org/forums/index.php/t/164911/https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/722Eclipse ESCET IDE help rendering broken on Windows 112024-03-10T15:33:03ZDennis HendriksEclipse ESCET IDE help rendering broken on Windows 11I get the following for our v2.0-RC1 release on Windows 11:
![image](/uploads/be054d882335d89256e8b5741bfe06d4/image.png)
A colleague pointed out to me that there may be an issue with the Eclipse internal browser. Apparently it refuses...I get the following for our v2.0-RC1 release on Windows 11:
![image](/uploads/be054d882335d89256e8b5741bfe06d4/image.png)
A colleague pointed out to me that there may be an issue with the Eclipse internal browser. Apparently it refuses to load scripts and style sheets.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/38Improve AsciiDoc-generated documentation HTML style2024-03-10T08:30:02ZDennis HendriksImprove AsciiDoc-generated documentation HTML styleWe now generate multi-page HTML from HTML files generated by AsciiDoctor (#36). We want to improve the HTML style of the generated HTML pages:
* [ ] Custom stylesheet:
* [x] Make a custom AsciiDoctor stylesheet, based on the default A...We now generate multi-page HTML from HTML files generated by AsciiDoctor (#36). We want to improve the HTML style of the generated HTML pages:
* [ ] Custom stylesheet:
* [x] Make a custom AsciiDoctor stylesheet, based on the default AsciiDoctor stylesheet. (!750)
* [ ] Style it more like the ESCET website:
* [x] Switch to sans serif font. (!750)
* [ ] Ensure the chosen font makes it easy to distinguish l/1, 0/O, etc.
* [x] Give the different docsets a color scheme more similar to their corresponding website. (!750)
* [x] Fix styling issues:
* [x] Literal text in tables doesn't have a gray background as outside tables. (!750)
* [x] Fix `kbd` style issue (#395). (!750)
* [ ] Styling improvements:
* [~] No section anchor links in HTML output, even though enabled. (was solved a while ago)
* [~] Reduce the large vertical spacing between lines, especially for code blocks. (doesn't seem present anymore)
* [~] Use slightly darker code block background to make it pop out a bit more. (doesn't seem needed anymore)
* [~] Link style in general could be improved. (no idea anymore what was meant here)
* [~] Justify text. (tried it, but it looks ugly)
* [~] Improve table style. (no idea anymore what was meant here)
* [x] Hover over code block shows e.g. 'CHI' in capitals. (!750)
* [ ] Let browser decide column widths. Use `\[%autowidth.stretch\]` or `\[%autowidth\]` for tables (not recognized by docbook converter used for PDF generation). Or, just override the column width with CSS to be automatic.
* [x] Distinguish internal vs external links. (!750)
* [x] Don't wrap code blocks, but show a scrollbar instead. Do still wrap inline literal text. (!750)
* [x] Improve `menu` and `btn` macro styles. (!750)
* [x] TOC structure/styling improvements:
* [x] Put a symbol before each TOC item. The current indentation doesn't make it very clear what are different pages, especially with longer and wrapping section names. (!750)
* [x] Make TOC interactive with collapse/expand (fold/unfold) interactivity. The current TOC of the CIF documentation is very long, so navigating is becomes cumbersome and users use page search to find things. Going to another page you lose where you are. It is then cumbersome to go to a sibling page, for instance. (!750)
* [x] Fix TOC highlighting and expanding for current section on a page (rather than the entire page). (!759)
* [x] Fix TOC links for virtual sections (non-page, non-section ones). They are wrappers only in the TOC. Not actual sections on the pages themselves. Typically they are italic/bold texts, with or without an id to link to. (!761)
* [x] Ensure that virtual TOC entries are taken into account for breadcrumbs. (!763)
* [x] Animate TOC collapse/expand. (!767)
* [x] Generated JS code needs a license header. (!794)
* [x] Syntax highlighting: (#740)
* [~] Enable syntax highlighting, for built-in languages. (was solved a while ago)
* [x] Enable syntax highlighting, for Eclipse ESCET languages, so syntax coloring for Chi, CIF, SeText, ToolDef, console, SVG, BNF, etc.
* [ ] PDF styling:
* [ ] Reconsider whether we want to keep the PDF output at all. Does anybody use it? It takes a long time to render during builds.
* [ ] Enable PDF section numbers for all sections, even though not in the TOC (for all levels).
* [ ] Let PDF renderer decide table column widths by itself.
* [ ] Use recommended syntax highlighter, Rouge. See also #740.
* [x] Code improvements:
* [x] `AsciiDocHtmlModifier` has two times `Renamed` that should be `Rename` in comments. (!768)
**Old ideas**
* **Bootstrap theme**
* *Old text*:
The idea would be to base the documentation on [Bootstrap](https://getbootstrap.com/) if possible, to match the static website pages. It is also generally nicer and more modern. We could look whether there are any AsciiDoc Bootstrap-based themes/styles.
The approach could be to:
* First switch to a new theme/style.
* And then fine-tune that global style to our own liking. These can happen incrementally, with one or a few changes per branch. E.g., adding syntax highlighting can be separate from table styles, for instance.
This would be in line with https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/373#note_828292.
* *Rejected*:
I investigated this, but the AsciiDoctor skins that are based on Bootstrap don't have a TOC, etc. I think it is better to stay close to the default theme, but customize that to be more like the ESCET website. I've experimented with this over the past days, and it works quite well.
* **Inspiration other websites**
* *Old text*:
Some inspiration can be obtained here:
* https://cstweb.wtb.tue.nl/4tc00/index.html
* https://cstweb.wtb.tue.nl/cif/trunk-r9682/lang/tut/index.html (no longer online)
Also, compare styling to old Sphinx/RST HTML styling.
* *Rejected*:
The new idea is to take inspiration from the ESCET website itself. And from online sources, but not necessarily only the ones listed here.
* **Official Eclipse fonts**
* *Old text*:
Eclipse officially uses Libre Franklin as website font, see https://www.eclipse.org/legal/documents/eclipse_foundation_branding_guidelines.pdf
* *Rejected*:
We don't have to use the same font. It is probably best to stick with a well-known universally-used webfont, that renders similarly across platforms and browsers.
* **Deeper nested headings**
* *Old text*:
Currently no styling for 'h7' to 'h9' tags (we have no h10). Only 'h1' through 'h6' are official HTML and have styling. Not needed if we do multi-HTML output first.
* *Rejected*:
AsciiDoc and HTML don't support 'h7' and further'. Also, we don't need it anymore, as we have multi-page HTML now.
* **Old TOC ideas**
* *Old text*:
Bootstrap seems to support folding nav sidebars, see e.g. https://getbootstrap.com/docs/5.1/components/navs-tabs/. Not sure whether this requires completely generating different HTML from the AsciiDoc sources or not.
Ensure that for longer TOCs and with multi-html page output (see #36) the TOC scrolls to the currently visible HTML page. And maybe even to the correct section.
* *Rejected*:
The idea is not to use Bootstrap anymore. Scrolling is not necessary if the TOC is by default collapsed except for the 'trail' to the currently shown page. Then the TOC is so short that it fits on most screens most of the time, as there are not many root items, and the expanded items are not that numerous.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/754Disable 'linked resources' feature2024-01-29T20:43:43ZDennis HendriksDisable 'linked resources' featureScreenshot:
![image](/uploads/e0df74dd056110b7336dd805171fefbd/image.png)
You get this when you drag a file or folder on to a project or folder in the the Project Explorer or Package Explorer.
This dialog is not very intuitive to end ...Screenshot:
![image](/uploads/e0df74dd056110b7336dd805171fefbd/image.png)
You get this when you drag a file or folder on to a project or folder in the the Project Explorer or Package Explorer.
This dialog is not very intuitive to end users. They likely don't realize what linked resources are. Linked resources are probably also not supported by all our tooling either, they have various subtleties, etc. Let's disable them. It can of course be re-enabled manually by users.
Todo:
* Disable in ESCET IDE.
* Disable in development environment.v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/748Eclipse ESCET IDE help only partially honors stylesheets2024-01-27T13:31:15ZDennis HendriksEclipse ESCET IDE help only partially honors stylesheetsEclipse ESCET general toolkit documentation on the website:
![website](/uploads/121b9d43a58c2928a90431dac558014d/website.png)
Eclipse ESCET general toolkit documentation in the Eclipse ESCET IDE. Notice the lack of yellow colors, but t...Eclipse ESCET general toolkit documentation on the website:
![website](/uploads/121b9d43a58c2928a90431dac558014d/website.png)
Eclipse ESCET general toolkit documentation in the Eclipse ESCET IDE. Notice the lack of yellow colors, but the presence of the external link icon (both are in our custom CSS styling):
![ecilpse-help-in-eclipse](/uploads/2745d4de102ef513eb5744bc79cd6122/ecilpse-help-in-eclipse.png)
Eclipse ESCET general toolkit documentation in the browser, but served by the local server running in Eclipse, the same one that shows the help within Eclipse. Notice the yellow colors, etc:
![eclipse-help-in-browser](/uploads/241db872afb1de61e5ecf33c549282f2/eclipse-help-in-browser.png)
I don't know what is causing this problem. It may or may not be the same cause as for #722.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/740Syntax highlighting for ESCET-languages in AsciiDoc-generated documentation2024-01-26T09:20:24ZDennis HendriksSyntax highlighting for ESCET-languages in AsciiDoc-generated documentationSplit off from #38, to address syntax highlighting specifically.
**Tasks**
* [x] Choose which syntax highlighter to use.
* [x] Enable chosen syntax highlighter, if not configured already. (!774)
* [x] Enable or make all scanners/lexers...Split off from #38, to address syntax highlighting specifically.
**Tasks**
* [x] Choose which syntax highlighter to use.
* [x] Enable chosen syntax highlighter, if not configured already. (!774)
* [x] Enable or make all scanners/lexers/languages we need. (!774)
**Languages**
Languages we currently use for `source` blocks:
* Non-ESCET: bnf, c, console, html, java, javascript, markdown, properties, shell, svg (= xml)
* ESCET: chi, cif, dsm, raildiagram, setext, tooldef
* Some have no language, which [is valid](https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-highlighter/#disable-source-highlighting).
* Note that `console` and `shell` [are different](https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-highlighter/#shell-vs-console).
**General info**
General AsciiDoctor information about syntax highlighting:
* https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-highlighter/
* Explains how to enable syntax highlighting, what syntax highlighters are available/supported, etc.
**Syntax highlighters**
Possible [syntax highlighting solutions](https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-highlighter/#available-source-highlighters) supported by AsciiDoctor:
| Highlighter | Supported by |
| ------------ | ------------------------------------------ |
| CodeRay | Asciidoctor, AsciidoctorJ, Asciidoctor PDF |
| highlight.js | Asciidoctor, AsciidoctorJ, Asciidoctor.js |
| Pygments | Asciidoctor, Asciidoctor PDF |
| Rouge | Asciidoctor, AsciidoctorJ, Asciidoctor PDF |
**Solution 1: CodeRay**
* Pros:
* Supports AsciiDoctorJ/**HTML** and **PDF**.
* Cons:
* Highlights only 22 **languages**. It has C, HTML, Java, JavaScript, and XML (for SVG). It lacks BNF, console, Markdown, properties and shell.
* CodeRay is **old**. The [website](http://coderay.rubychan.de/) looks ancient. As of 2024-01-11, the [last release](https://github.com/rubychan/coderay/releases) was on 2020-05-30, almost 4 years ago. And the [last commit](https://github.com/rubychan/coderay/commits/master/) was in 2022, but only build-related change etc.
* Its use is now [**discouraged** by AsciiDoctor PDF](https://docs.asciidoctor.org/pdf-converter/latest/syntax-highlighting/), which recommends Rouge.
* I can't find how to **add your own** language [scanner](http://coderay.rubychan.de/doc/CodeRay/Scanners/Scanner.html) and make CodeRay find it. I did find that it supports [plugins](http://coderay.rubychan.de/doc/CodeRay/PluginHost.html), but I didn't find information on how that works.
Conclusion: CodeRay is old, and there seems to be no information on how to add your own language. If we could find such documentation, CodeRay could be reconsidered.
**Solution 2: highlight.js**
* Pros:
* Supported for AsciiDoctorJ/**HTML**.
* [Last release](https://github.com/highlightjs/highlight.js/releases) was just a few months ago (2023-10-09). [Last commit](https://github.com/highlightjs/highlight.js/commits/main/) was only 2 days ago. Seems very much **alive**.
* It highlights [242 **languages**](https://github.com/highlightjs/highlight.js/blob/main/SUPPORTED_LANGUAGES.md), including all the non-ESCET ones that we use.
* It seems to have quite extensive [**documentation**](https://highlightjs.readthedocs.io/en/latest/index.html) (for the current version).
* A quick experiment showed that it is **easy to add** a new language and activate it in the generated HTML page.
* highlight.js **can be reused** for HTML that is not generated by AsciiDoc, such that the to-be-contributed **SBE course**, which also has a lot of CIF model snippets that would benefit from highlighting (#742).
* Cons:
* Not supported for **PDF**.
* The version used by AsciiDoctor is **version 9**, which is [**end of life** and end of support](https://github.com/highlightjs/highlight.js/issues/2877). I [reported it to AsciiDoctorJ](https://github.com/asciidoctor/asciidoctorj/issues/1258), but they consider it a problem of AsciiDoctor. AsciiDoctor [has an issue](https://github.com/asciidoctor/asciidoctor/issues/3976) for it open for 3 years. I [asked them](https://github.com/asciidoctor/asciidoctor/issues/3976#issuecomment-1890454918) to consider the upgrade, but they [responded](https://github.com/asciidoctor/asciidoctor/issues/3976#issuecomment-1890482401) by putting the burden on me to do the work. It seems we may be stuck on version 9, for which the documentation is also not online anymore.
* If we provide highlight.js version 11, the **[callouts](https://docs.asciidoctor.org/asciidoc/latest/verbatim/callouts/) don't work** anymore. However, we don't use them anyway, so that is not a big problem.
* Notes:
* AsciiDoctor repo has in `asciidoctor-main/lib/asciidoctor.rb` a fixed version `HIGHLIGHT_JS_VERSION = '9.18.3'`, which is then used to construct base URLs in `lib/asciidoctor/syntax_highlighter/highlightjs.rb` using `base_url = doc.attr 'highlightjsdir', %(#{opts[:cdn_base_url]}/highlight.js/#{HIGHLIGHT_JS_VERSION})`. This means we need to **upgrade by ourselves**. This should be **easy** though, as we can provide our own folder for it. We likely want this anyway, as then we get a fixed version, and the generated documentation doesn't rely on a working Internet connection (for syntax highlighting at least).
Conclusion: Can be used for the SBE course as well. Adding our own newer version than AsciiDoctor ships seems easy. We'd have to live with no highlighting in PDF output.
**Solution 3: Pygments**
* Pros:
* Supported for **PDF**.
* Cons:
* Not supported by AsciiDoctorJ/**HTML**.
Conclusion: Given that it can't be used for HTML output, I didn't check it further.
**Solution 4: Rouge**
* Pros:
* Supported for AsciiDoctorJ/**HTML** and **PDF**.
* It is the [**preferred** syntax highlighter](https://docs.asciidoctor.org/pdf-converter/latest/syntax-highlighting/) of AsciiDoctor PDF.
* It highlights [219 **languages**](https://github.com/rouge-ruby/rouge/blob/master/docs/Languages.md), including all non-ESCET languages we use, except for BNF.
* Its [last release](https://github.com/rouge-ruby/rouge/releases) was only a few months ago (2023-10-25), and its [last commit](https://github.com/rouge-ruby/rouge/commits/master/) only six days ago. It seems very much **alive**.
* It has extensive [**documentation**](https://rouge-ruby.github.io/docs/).
* It is [clearly explained](https://rouge-ruby.github.io/docs/file.LexerDevelopment.html) how to **add your own** lexer for your own language. A quick experiment shows that it is **easy to add** your own lexer to the Rouge repo. They [**welcome** you submitting](https://rouge-ruby.github.io/docs/file.LexerDevelopment.html#how-to-submit) your own lexer for including in Rouge.
* Cons:
* Rouge only supports loading lexers bundled with Rouge, **not external ones**. I reported this as [an issue](https://github.com/rouge-ruby/rouge/issues/2020). I don't like this, as when we change a language (add a keyword), we first need a new Rouge release before we can highlight the new keyword in our own documentation. It **makes us dependent** on new Rouge releases.
* Rouge performs the highlighting during the compilation. This will **add to build times**. It will also be done for every build, wasting CPU cycles. (This unlike highlight.js, which only performs the highlighting in the user's browser, and only for actually visited pages.)
* Rouge is a full scanner, and the **code must be valid**. Some of our code snippets have things like `...` in it to indicate omitted parts. That can't be lexed until we add all such exceptions to the lexer. (For highlight.js you only specify what is to be highlighted.)
* Notes:
* It is possible to load custom Ruby Gems with the AsciiDoctor Maven Plugin, using the `gemPaths` option (see [here](https://docs.asciidoctor.org/maven-tools/latest/plugin/goals/process-asciidoc/)). It is also shown with an example in [this issue](https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/109). It seems this way we could load Gems even from a local directory in our repo. Whether we can override `rouge` that way, I'm **not sure though**, as it is meant to load extra plugins, not override existing plugins.
Conclusion: Seems well-supported and alive. But, they don't response to our issue. And we would be dependent on Rouge release cycle (given the lack of contributed lexers), and we'd have to add all non-compliant syntax exceptions to the lexer as well.
**Conclusion**
The easy solution for now is to just go for highlight.js. We can change what we need. We have to live then with no highlighting in PDF output, but that is not the main output anyway.
Addresses #38v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/395Line break between special AsciiDoc element and period2024-01-05T15:47:05ZMartijn GoordenLine break between special AsciiDoc element and periodApparently a line break can be inserted between the ASCIIDOC element `kbd` and a period. This results in a weird looking sentence in the documentation, where the period is alone on a single line. There might be more examples in the docum...Apparently a line break can be inserted between the ASCIIDOC element `kbd` and a period. This results in a weird looking sentence in the documentation, where the period is alone on a single line. There might be more examples in the documentation (but I haven't looked for them yet).
![Screenshot_2022-07-05_at_09.15.49](/uploads/c7468aaa6faa1e9d21c2c967c6c1b912/Screenshot_2022-07-05_at_09.15.49.png)v3.0Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/720ESCET startup screen upside down on macOS 14 (Sonoma)2023-12-21T22:03:48ZMartijn GoordenESCET startup screen upside down on macOS 14 (Sonoma)When starting up ESCET, the [splash image](product/org.eclipse.escet.product.branding/splash.bmp) is shown before the pop-up window asking for the workspace. After choosing an appropriate workspace, this splash image is shown again until...When starting up ESCET, the [splash image](product/org.eclipse.escet.product.branding/splash.bmp) is shown before the pop-up window asking for the workspace. After choosing an appropriate workspace, this splash image is shown again until the full Eclipse window is shown. (If a default workspace is selected, still two splash windows are used by Eclipse.)
On my MacBook Pro, the second splash image is shown upside down (mirrored along x-axis) and inappropriately cropped.
![Screenshot_2023-12-21_at_11.16.28](/uploads/a6de96a9e9b6c161d90865c56e3f467f/Screenshot_2023-12-21_at_11.16.28.png)
I get this behavior for all ESCET versions all the way back to v0.2. And my suspicion is that this is Eclipse platform related.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/1Initial contribution2023-11-06T19:51:43ZDennis HendriksInitial contributionOur first commit must be the initial contribution.Our first commit must be the initial contribution.v0.1Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/27Update developer documentation with information on committers and contributor...2023-10-30T09:31:07ZDennis HendriksUpdate developer documentation with information on committers and contributors can collaborateWe should update the developer documentation to explain how the committers can work with contributors:
- How go get a merge request from a contributors fork into your own Git repository. See e.g. https://docs.gitlab.com/ee/user/project/m...We should update the developer documentation to explain how the committers can work with contributors:
- How go get a merge request from a contributors fork into your own Git repository. See e.g. https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#checkout-merge-requests-locally-through-the-head-ref
- How to add commits as a committer to a contributors merge request to address review comments.
- How contributors can update their forked repository when the official Eclipse ESCET GitLab repo is updated. See e.g. https://forum.gitlab.com/t/refreshing-a-fork/32469/2. Section 'Git CLI' would be good to try. Section 'GitLab Repository Mirror' won't work, as it requires admin rights on the Eclipse Foundation GitLab.
- How committers and contributors can work together, allowing both the contributor and committer to add new commits. See also https://www.eclipse.org/lists/escet-dev/msg00105.html
- How to manually check whether contributors have an ECA on file, just in case of issues with the automatic checks. I.e. use the ECA Validation Tool at https://accounts.eclipse.org/user/eca.
- `CONTRIBUTING.asciidoc` in the Git repo root mentions https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests, which contributors can't use, as they need to create a merge request from their own fork. This is confusing information.
- ...v0.3Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/662Exit code 23 and 24 should not restart command line applications2023-10-12T10:54:57ZDennis HendriksExit code 23 and 24 should not restart command line applicationsThis behavior was introduced when fixing our command line scripts in !656 for #89. The special handling of exit codes 23 and 24 is a feature of the Eclipse launcher. We asked about disabling this special handling on the Equinox forum: ht...This behavior was introduced when fixing our command line scripts in !656 for #89. The special handling of exit codes 23 and 24 is a feature of the Eclipse launcher. We asked about disabling this special handling on the Equinox forum: https://www.eclipse.org/forums/index.php/mn/msg/1113735/1/on/0/?SQ=8c6bc00c7709967220cd9710cad81cc8. Ideally, we get a way to disable it, such that we can always return the proper exit code, and not have some exit codes restart the application.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/89Linux command line scripts show JVM UI popup upon failure2023-10-05T22:07:04ZDennis HendriksLinux command line scripts show JVM UI popup upon failureAt https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/73#note_10795, @ahofkamp notes:
> An error in execution like `cd bin; ./cif2cif` throws an error due to missing arguments (which is correct). It also pops up a graphical...At https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/73#note_10795, @ahofkamp notes:
> An error in execution like `cd bin; ./cif2cif` throws an error due to missing arguments (which is correct). It also pops up a graphical window from the VM saying it failed with the execution options and flags details. You have to close that window manually before the prompt returns. As such the `bin` programs are useless for automagic use in their current form.v2.0Patrick van BerkelPatrick van Berkelhttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/623Eclipse ESCET shows 'PulseSetupClient.app' popup on first launch on macOS2023-08-08T07:28:12ZDennis HendriksEclipse ESCET shows 'PulseSetupClient.app' popup on first launch on macOSFrom https://www.eclipse.org/lists/escet-dev/msg00536.html:
>>>
When I opened ESCET v.10-RC1 and did the usual security stuff on my Macbook, I suddenly got a popup on “PulseSetupClient.app”. I have never seen this particular application...From https://www.eclipse.org/lists/escet-dev/msg00536.html:
>>>
When I opened ESCET v.10-RC1 and did the usual security stuff on my Macbook, I suddenly got a popup on “PulseSetupClient.app”. I have never seen this particular application before.
![image](/uploads/50b3a09c69e053b0afc9b7b259c637ab/image.png)
ESCET seems to run fine without running this app.
>>>
From https://www.eclipse.org/lists/escet-dev/msg00537.html:
>>>
The EclipseESCET-v0.10-RC1-aarch64 version runs fine on my (M1 Mac) system, no additional popups.
>>>
From https://www.eclipse.org/lists/escet-dev/msg00538.html:
>>>
I also don't get that on Windows. I don't have a macOS to test with. I Googled '+eclipse PulseSetupClient' and didn't find anything (useful). Just Googling 'PulseSetupClient' I found this post: https://macsecurity.net/view/505-pulse-secure-app-will-damage-your-computer-mac-popup. It seems to talk about a VPN app (slightly different name though), and something with certificates. Are you sure it is not some VPN app that you have that coincidentally gave the popup at the time you tried the ESCET release?
>>>
From https://www.eclipse.org/lists/escet-dev/msg00539.html:
>>>
I also didn’t find much when I googled for this particular application, especially in connection with Eclipse. So I agree with you it probably is some form of coincidence that it popped up while also dealing with the usual security messages of running an new ESCET application (also given that Bert didn’t experience this on his Mac).
>>>
From https://www.eclipse.org/lists/escet-dev/msg00542.html:
>>>
The strange “PulseSetupClient.app” is definitely triggered by starting the ESCET application for the first time. I just installed v0.10 and I got this popup again. So I don’t deem it a coincidence any more.
Let me see whether I can find a someone in the office that uses also a MacBook with Intel and is available to do a test.
>>>https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/570The 'dsmclustering' script in the product has no executable bit2023-04-28T10:20:36ZDennis HendriksThe 'dsmclustering' script in the product has no executable bitIt has a different name than the other scripts. We need to add this one as well.It has a different name than the other scripts. We need to add this one as well.v0.10Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/102Consider moving documentation sources closer to related code2022-12-23T08:18:34ZDennis HendriksConsider moving documentation sources closer to related codeThis issue is now separated from #73. #73 is about the documentation set structure, i.e. the different documentation sets that are built and thus produce e.g. a PDF.
Here we want to discuss whether it would be good, and possible, to mov...This issue is now separated from #73. #73 is about the documentation set structure, i.e. the different documentation sets that are built and thus produce e.g. a PDF.
Here we want to discuss whether it would be good, and possible, to move documentation sources closer to their related code. Thus, can we put e.g. the rail diagram generator documentation sources in the rail diagram generator plugin, regardless of it being part of some documentation set.
There is some relevant discussion from #73 that applies to *this* issue.
**First introduction of the issue**
> At https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/46#note_9818, the following was mentioned:
>
> > The documentation *sources* of this plugin got moved to the doc corner. I know we did that before, and for languages I think it makes sense, as the tool collection is large, and often you need combined tools to get useful results. You want to describe all tools in one document, rather then each tool separately.
> >
> > I am not entirely sure it makes sense for the more stand-alone tools. A distribution of this plugin now has no docs at all (no sources of the docs and no generated doc files). The 'docs' plugin has doc sources for tools that don't exist there.
>
> The 'this plugin' relates to the rail diagram generator (documentation).
**This discussion relates to the documentation set discussion, as that can also help to bring documentation somewhat closer to the code**
> * The Eclipse ESCET documentation includes too much.
> * [...]
> * Move the `common` documentation to a separate 'common' documentation set (in the `common` directory), similar to the Chi, CIF, etc documentation. That way it is closer to the plugins that it applies to.
>
> This leads to a few more documentation sets. But it would be more structured like the directory structure that we have, and would be 'closer to the source'. It would also fit the intended audience better.
>
> We could make separate documentation sets for the application framework, rail diagram generator, etc that are part of \`common, but that would lead to a lot of documentation sets, some of which may be very small.
**Here it was identified that indeed we're discussing two things (which are now two separate issues)**
> I like the general direction you're taking.
>
> Your discussion seems to use "documentation" in 2 different forms imho. One form is the source code, the *.asciidoc files. The other form are the generated viewable *.html or *.pdf files.
>
> I am not sure why you don't want to move the *documentation sources* to the plugin if it makes sense.
(While definitely keeping plugins that generate viewable versions as a collection of files in one place too, as a larger document with all related material together is useful for a reader.)
>
> That is, with a Git checkout, the documentation builder has access to everything, so why do we stick documentation sources of a single document in a single directory?
>
> The trick here is likely to find a good balance between keeping code and its documentation together as much as possible, while not scattering document sources across all plugins just because it discusses a few things of a plugin.
**Possible concern with versions/qualifiers vs content/hashes**
> I like your idea of just including the sources from the separate plugins into the larger documentation sets. The common documentation plugin could have the general documentation sources and include the sources of the application framework from the application framework plugin. I had actually not considered this before.
>
> However, one of the concerns with taking sources from various plugins is that the plugin version qualifier (the last part of the version) is determined by the last Git commit date. If you take files from other plugins (say B and C) to build your own plugin (say A), I'm not sure whether that's taken into account for the plugin version of plugin A. If not, then the version may not be updated, while the built contents is, and thus the JAR will have different content for the same version of the plugin. That could cause all kinds of issues when updating plugins to newer versions, when combining update sites, etc etc. We've faced these issues in the past.
>
> I hope that adding a dependency from A to B and C will help to take their changes into account as well. If that works, we could take sources from other plugins. If that doesn't work, I fear we have to prevent taking sources from other plugins to prevent difficult to diagnose/resolve issues.
>
> I wanted to check this anyway, as the idea is for the other issue about the railroad diagram generator to take the config file from the plugin and put it in the documentation. We would face similar issues there. I'll test it to see how it behaves. Maybe there is configuration that affects it that we can configure as well.
> I experimented to see whether we can include sources from other plugins to build documentation plugins. I did the following:
>
> - A dependency of the ESCET documentation on the railroad diagram generator.
> - Including the railroad diagram generator in the common feature (just to be sure it is in a feature, in case not including it in a feature is a problem).
> - Committed a change in the ESCET documentation plugin, at time X.
> - Committed a change in the railroad diagram generator plugin, at a later time Y > X.
> - Performed a full build locally.
>
> Ideally both the ESCET documentation plugin and the railroad diagram generator get the 'qualifier' part of their version numbers set to something derived from Y. In practice, the railroad diagram generator gets Y as that is the last commit in that plugin, and the ESCET documentation gets X as that is the last commit in that plugin. It seems dependencies have no effect on qualifiers for the 'jgit' timestamp provider. The source code at https://github.com/eclipse/tycho/blob/master/tycho-extras/tycho-buildtimestamp-jgit/src/main/java/org/eclipse/tycho/extras/buildtimestamp/jgit/JGitBuildTimestampProvider.java seems to confirm this, as I can't find anything in the code that seems to take dependencies into account. Only the last commit of the basedir of the project is taken into account.
>
> To some degree this makes sense to me, as typically dependencies are what you use to execute the plugin at runtime. In such cases you wouldn't want any minor change in dependencies and dependencies of dependencies to cause a version increase. However, it would be practical to consider build-time dependencies, and do consider them in determining the version. For features, this functionality is provided by the build-qualifier-aggregator goal of the tycho-packaging plugin, see https://www.eclipse.org/tycho/sitedocs/tycho-packaging-plugin/build-qualifier-aggregator-mojo.html. However, as far as I can find, this is only available for features.
>
> I'll explore further.
> One way to resolve all this, is to use fixed qualifiers, rather than different ones for each plugin/feature/etc based on Git timestamps. If we determine for a release the Git timestamp of the release tag, we could base the qualifier for all plugins, features and products on that timestamp, such that they are all based on the same timestamp and thus qualifier. Essentially, we'd be using the 'maximum' of all individual qualifiers for all plugins/features/etc. It would lead to 'unnecessary' qualifier increases, but would solve all the issues we have. Given that we update the major/minor/micro version for a release anyway, they are already unique and the qualifier seems to have reduced value anyway. For non-release builds (dev builds), we could keep the Git-based timestamp as we have now, as IMHO there the 'same version implies same content and hash' rule is less important. But in principle there is no reason we can't use the same strategy as for releases there as well.
> Sounds good to me. I agree that development builds are mostly for sanity checking of the code, and not really intended for use to derive other work on. Having not exactly stable qualifiers shouldn't be much of a problem.
> I've created #92 for the version/qualifier changes. Let's discuss that further there. Then this issue can focus on the documentation set structure.
**SeText documentation**
If we can include sources from other plugins, it makes sense to spread the documentation sources even more, over several SeText plugins. We can then also easily include it in the developer documentation set, rather than having a separate documentation set.https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/483Update macOS download instructions to Ventura (macOS 13) version2022-12-21T15:48:49ZMartijn GoordenUpdate macOS download instructions to Ventura (macOS 13) versionApple has reworked the System Settings menu with the Ventura (macOS 13) version update. These changes should be reflected on the dowload page of ESCET.Apple has reworked the System Settings menu with the Ventura (macOS 13) version update. These changes should be reflected on the dowload page of ESCET.v0.9Martijn GoordenMartijn Goordenhttps://gitlab.eclipse.org/eclipse/escet/escet/-/issues/32Customize product welcome screen2022-12-19T08:05:33ZDennis HendriksCustomize product welcome screenCustomize the product welcome screen:
* Add links to Eclipse help
* Add links to website
* Add links to release notes
* Add links to documentation
* Add links to import examplesCustomize the product welcome screen:
* Add links to Eclipse help
* Add links to website
* Add links to release notes
* Add links to documentation
* Add links to import examplesv0.8Dennis HendriksDennis Hendriks