escet merge requestshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests2021-11-09T06:05:18Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/183Draft: Resolve "SVG viewer save as suggested file name/path doesn't work as e...2021-11-09T06:05:18ZFerdie ReijnenDraft: Resolve "SVG viewer save as suggested file name/path doesn't work as expected"Closes #221Closes #221v0.4Ferdie ReijnenFerdie Reijnenhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/255Draft: #111 Generate railroad diagrams during build rather than committing th...2022-01-19T17:12:30ZFerdie ReijnenDraft: #111 Generate railroad diagrams during build rather than committing them to Git repoCloses #111Closes #111v0.5https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/257Draft: Resolve "Railroad diagrams should not use `java.awt` drawing functiona...2022-01-21T07:00:28ZAlbert HofkampDraft: Resolve "Railroad diagrams should not use `java.awt` drawing functionality for graphics"Closes #293Closes #293v0.5Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/256#111 Generate railroad diagrams during build rather than commiting them to gi...2022-03-19T11:03:24ZFerdie Reijnen#111 Generate railroad diagrams during build rather than commiting them to git repo.Closes #111Closes #111v0.5https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/271Draft: #316 Introduce small common position class in scanning and parsing2022-04-10T10:04:17ZAlbert HofkampDraft: #316 Introduce small common position class in scanning and parsingTo avoid a forced connection between parsing a text file and having to import EMF, a very simple `CommonPosition` class is introduced without additional dependencies if so desired.
I have no errors, and I can build it locally.
The numbe...To avoid a forced connection between parsing a text file and having to import EMF, a very simple `CommonPosition` class is introduced without additional dependencies if so desired.
I have no errors, and I can build it locally.
The number of files that it touches is somewhat insane, but changes are generally easy.
A perhaps somewhat tricky part is whether I made the switch from `CommonPosition` to `Position` always at the right spot. At times I made life easy by adding an overload to a commonly called function, such as error reporting.
What may be incomplete are the manifest dependencies of some plugins, perhaps some `position.metamodel` bundle imports are no longer required.
Closes #316v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/278#271 Add asciidoc file checker2022-04-17T09:48:26ZAlbert Hofkamp#271 Add asciidoc file checkerApplication that performs a few additional checks on asciidoc files.
Addresses #271Application that performs a few additional checks on asciidoc files.
Addresses #271v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/294Draft: #344 Add Design Structure Matrix (DSM) clustering2022-05-09T07:42:17ZAlbert HofkampDraft: #344 Add Design Structure Matrix (DSM) clusteringDSM clustering is a stepping stone in multilevel synthesis ( #318 ), yet is also useful on its own.
For this reason I added the application as well. We apparently have no common tools documentation so I created a project for it, not sure...DSM clustering is a stepping stone in multilevel synthesis ( #318 ), yet is also useful on its own.
For this reason I added the application as well. We apparently have no common tools documentation so I created a project for it, not sure if that is sane at all, nor do I know what files to add and changes to add.
Closes #344v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/555#567 Unable to run CIF simulation in stand-alone mode using ./bin/cifsim2023-04-23T19:11:49ZPatrick van Berkel#567 Unable to run CIF simulation in stand-alone mode using ./bin/cifsimThis pull request implements a possible solution to the braking dependency to the Eclipse Workbench environment and workspace location for stand-alone application which implement dark mode.
### Support Dark mode
To be able to run the s...This pull request implements a possible solution to the braking dependency to the Eclipse Workbench environment and workspace location for stand-alone application which implement dark mode.
### Support Dark mode
To be able to run the stand-alone application it need to be able to do this without relying on the Eclipse theming facility. This however causes some issues because the OS mode (Dark or Light) also affects the color display by SWT. This means the stand-alone application still needs to change its colors based on the OS mode. For MacOS and Linux this can be solved as SWT supports the `org.eclipse.swt.widgets.Display#isSystemDarkTheme()` method. On Windows, however, this does not work as I would expect. SWT will only show Light theme even when it detects Windows is set to Dark Mode.
In more detailed words. See [SWT OS.setTheme()](https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/win32/org/eclipse/swt/internal/win32/OS.java#L2235):
``` c
// eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/org/eclipse/swt/internal/win32/OS.java
/*
* On Windows, there is no OS API for dark theme yet, and this method only
* configures various tweaks. Some of these tweaks have drawbacks. The tweaks
* are configured with defaults that fit Eclipse. Non-Eclipse applications are
* expected to configure individual tweaks instead of calling this method.
* Please see <code>Display#setData()</code> and documentation for string keys
* used there.
*/
```
One solution could be to introduce platform specific code in `EclipseThemeUtils` class.
``` java
import org.eclipse.swt.widgets.Display;
public static boolean isDarkThemeInUse() {
if (PlatformUI.getWorkbench()) {
// Running inside Eclipse UI.
IThemeEngine themeEngine = PlatformUI.getWorkbench().getService(IThemeEngine.class);
ITheme theme = themeEngine.getActiveTheme();
return theme != null && theme.getId().equals(ThemeEngine.E4_DARK_THEME_ID);
} else if (System.getProperty("os.name").contains("Windows")) {
// Running stand-alone on windows
return false;
} else {
// Running stand-alone on MacOS or Linux
return Display.isSystemDarkTheme();
}
}
```
An other solution which does not require platform specific code is to dynamically detect the mode based on the background color of the parent widget and determine if is dark or light.
This makes the code more independent from both the system mode and the Eclipse theme itself. The cost is a additional argument in all the color selection code in ESCET applications which need to able to run in stand-alone mode.
This second option in implemented in this Pull Request.
### Support running without a workspace
As described in the issue the addition of support for the Dark theme also introduced a dependency to the workspace location when running in stand-alone mode. The scripts which execute the stand-alone applications do, however not specify a workspace location.
One way to solve this is to add the -data argument to the scripts. A possible location could be the most recent workspace location used by the eclipse application, which is stored in "`{eclipse dir}./configuration/.settings/org.eclipse.ui.ide.prefs`". This file is not present after initial initialization, which means selecting a default location.
An others solution is to prevent remove the runtime dependency on this workspace location. In the current implementation the stand-alone application needs to know the workspace location to determine the theme related preference stored by Eclipse. This preference is used to detect runtime changes to the Eclipse theme. In the current implementation the stand-alone applications do not rely on the theme selected by Eclipse as it does not use it's `ThemeEngine` to apply a theme to SWT.
As such changes to this Eclipse preferences are not of interest when an ESCET application is running in stand-alone mode. This runtime dependency can be removed by disabling the subscription to the changes of this preference when workspace is not defined.
``` java
private void register() {
if (EclipseThemeUtils.isPlatformIntstanceSet()) { // preferences not available.
EclipseThemeUtils.getEclipseThemePreferences().addPreferenceChangeListener(this);
}
}
```
This second option in implemented in this Pull Request.
### Startup error for all `eventbased` stand-alone application.
While testing I found that all `cif.eventbased` applications fail when running in stand-alone mode.
```
> bin/cifsynthanalys -h
!ENTRY org.eclipse.osgi 4 0 2023-04-14 08:53:16.917
!MESSAGE Application error
!STACK 1
OSGi bundle "org.eclipse.escet.cif.eventbased.apps" not found.
```
I found-out that this is caused an invalid plugin name in the stand-alone startup scripts. These scripts currently seem to name the package (`org.eclipse.escet.cif.eventbased.apps`) instead of the plugin (`org.eclipse.escet.cif.eventbased`).
This Pull Request changed this for the following `./bin/*` scripts.
```
cifabstr, cifctrlchk, cifdfamin, ciflngeqv, cifncchk, cifnfadfa, cifobschk, cifprod, cifproj, cifsupsynth, cifsynthanalys, ciftrim, ciftrimchk
```
### Eclipse cifsynthanaly closing immediately.
Currently the Synthesis Analysis Application end immediately after the creation of the UI causing the application and UI to close.
As the UI thread `ControlEditor` does not expose the Thread is use its method called `isAvailable()` to monitor the GUI.
``` java
while (editor.isAvailable()) {
ThreadUtils.sleep(500);
}
```
# Code demonstrating issues with Dynamic retheming in SWT:
[TestDynamicChangesToSWTSettings.java](/uploads/41b756a9ff87e4e77d3241b23244ae52/TestDynamicChangesToSWTSettings.java)v0.10