[3647] Add support for diagram style with background customization

CHANGELOG.adoc

@@ -1,8 +1,56 @@
 = Changelog
 
-== 2026.3.0 (work in progress)
+== 2026.5.0
 
-=== Shapes
+=== Pitches
+
+- Measure the performance of Sirius Web based applications
+
+
+=== Architectural decision records
+
+
+
+
+=== Deprecation warning
+
+
+
+
+=== Breaking changes
+
+
+
+
+=== Dependency update
+
+
+
+
+=== Bug fixes
+
+
+
+
+=== New Features
+
+- https://github.com/eclipse-sirius/sirius-web/issues/3647[#3647] [diagram] Add support for diagram style with background customization
+
+
+=== Improvements
+
+- https://github.com/eclipse-sirius/sirius-web/issues/6313[#6313] [doc] Improve the templates used for the functional and technical specifications.
+The functional specification will now use the same naming conventions as the shape up methodology with https://basecamp.com/shapeup/1.5-chapter-06[pitches] instead of shapes (https://basecamp.com/shapeup/1.1-chapter-02[shaping] is the process by which pitches are being created).
+The new template for functional specification is located in `doc/iterations/YYYY-MM/pitches/pitch.adoc`.
+The technical specifications will now rely on a new architectural decision record template located in `doc/adrs/adr.adoc`.
+This new template for ADRs will have several additional requirements compared to the previous one.
+It will require contributors to specify the persons involved in the decision process, to details the qualities expected of the solution, to list the various options considered, to clarify why a specific option has been selected, its advantages and drawbacks, which steps will be taken for the implementation among other things.
+
+
+
+== 2026.3.0
+
+=== Pitches
 
 - Keep details tab open on selection change
 - Add support the for selection dialog that can be confirmed without making a selection
@@ -159,7 +207,7 @@ Trees defined via the view DSL can alternatively provide a tooltip expression vi
 
 == 2026.1.0
 
-=== Shapes
+=== Pitches
 
 - Allow configuration of workbench panels
 - Remove usage of foreign keys between bounded contexts
@@ -449,7 +497,7 @@ Downstream applications can now implement `IUndoRedoIgnoreInputPredicate` to ign
 
 == 2025.12.0
 
-=== Shapes
+=== Pitches
 
 - Add command palette on projects page
 - Add support for indexing models
@@ -697,7 +745,7 @@ The executor typically needs to check the `menuEntryId` of the input to ensure i
 
 == 2025.10.0
 
-=== Shapes
+=== Pitches
 
 - Add support for exporting query result
 - Add support for search history
@@ -941,7 +989,7 @@ We have also added the `IInputDispatcher` which is in charge of dispatching an i
 
 == v2025.8.0
 
-=== Shapes
+=== Pitches
 
 - Add support for diagram customization
 - Add the ability to share the workbench state
@@ -1208,7 +1256,7 @@ The dialog can now display an impact analysis report, but isn't in charge of ret
 
 == v2025.6.0
 
-=== Shapes
+=== Pitches
 
 - Control the views available in a workbench
 
@@ -1422,7 +1470,7 @@ The _ExpandAll_ tool is now a Sirius Web contribution that can be enabled via th
 
 == v2025.4.0
 
-=== Shapes
+=== Pitches
 
 - Add support for edges connected to edges
 - Preserve custom edges rectilinearity
@@ -1655,7 +1703,7 @@ See the ADR 190 for additional details on the goal of this refactoring.
 
 == v2025.2.0
 
-=== Shapes
+=== Pitches
 
 - Add support for a query view
 - Lower the coupling between project and editing context
@@ -1858,7 +1906,7 @@ To achieve that a new concept, `ProjectSemanticData` has been added along with a
 
 == v2025.1.0
 
-=== Shapes
+=== Pitches
 
 
 === Architectural decision records
@@ -1988,7 +2036,7 @@ Downstream applications with a custom explorer that relies on `ExplorerDropTreeI
 
 == v2024.11.0
 
-=== Shapes
+=== Pitches
 
 - Add support for a table widget in form representations
 - Automatically select newly created nodes on diagrams
@@ -2178,7 +2226,7 @@ This will allow specifier to create images that fir perfectly in the project tem
 
 == v2024.9.0
 
-=== Shapes
+=== Pitches
 
 - Add tree representation in the view DSL
 - Add support for object duplication from Explorer
@@ -2318,7 +2366,7 @@ A migration participant has been added to automatically keep compatible all diag
 
 == v2024.7.0
 
-=== Shapes
+=== Pitches
 
 - Add support for text alignment on labels
 - Add support for gantt representation
@@ -2465,7 +2513,7 @@ We cannot rely on the error message recaived from the backend since Cross Origin
 
 == v2024.5.0
 
-=== Shapes
+=== Pitches
 
 - Configurable collapse
 - Add support for EMF models migration
@@ -2630,7 +2678,7 @@ They still support returning an `java.time.Instant` object directly.
 
 == v2024.3.0
 
-=== Shapes
+=== Pitches
 
 - Transform Sirius Web into an extensible platform
 - Facilitate the insertion of elements into a list node
@@ -2840,7 +2888,7 @@ In other scenarios, the default creation position border remains the eastern one
 
 == v2024.1.0
 
-=== Shapes
+=== Pitches
 
 - Add support for Portal representation
 - Add support for Gantt representation
@@ -3031,7 +3079,7 @@ image:doc/screenshots/biggerResizeHandles2.png[Compartment with header without s
 
 == v2023.12.0
 
-=== Shapes
+=== Pitches
 
 - Add support for custom nodes in Diagram representations
 - Add the possibility to specify a size ratio on node.
@@ -3244,7 +3292,7 @@ Node will not be outside of their container, nor on a node header because of a m
 
 == v2023.10.0
 
-=== Shapes
+=== Pitches
 
 - Add tool sections in the View DSL
 - Add support for Precondition Expressions in Tools
@@ -3395,7 +3443,7 @@ These color palettes are accessible in studio projects but are not visible in th
 
 == v2023.8.0
 
-=== Shapes
+=== Pitches
 
 - Add disable / enable concept for widgets
 - Add new custom widget to edit single and multi-valued references
@@ -3546,7 +3594,7 @@ Labels and node list are rendered with css.
 
 == v2023.6.0
 
-=== Shapes
+=== Pitches
 
 - Filter tree based representations
 - Add pages to form in the view DSL

diagram-image-server/package.json

@@ -1,6 +1,6 @@
 {
   "name": "diagram-image-server",
-  "version": "2026.1.6",
+  "version": "2026.3.0",
   "author": "Eclipse Sirius",
   "license": "EPL-2.0",
   "main": "index.mjs",

doc/adrs/adr.adoc

@@ -0,0 +1,97 @@
+:author: lists the author of this document
+:date: YYYY-MM-DD
+:status: {proposed | rejected | accepted | deprecated | superseded by}
+:consulted: lists everyone whose opinions are sought and with whom there is a two-way communication
+:informed: lists everyone who is kept up-to-date on progress in one-way communication
+:deciders: lists everyone involved in the decision
+:pitch: link to the related pitch (if any)
+:issue: link to the related issue
+
+= ADR-XXX - Title of The Architectural Decision Record
+
+== Context and Problem Statement
+
+Describes the context and problem statement in a few sentences.
+One may want to articulate the problem in form of a question or provide an illustrative story that invites to a conversation.
+Links to collaboration boards or issue management systems can go here too.
+
+
+== Decision Drivers
+
+Desired qualities, forces, faced concerns of potential solutions are identified here:
+
+- First criteria used to evaluate a potential solution
+- Second criteria used to evaluate a potential solution
+- Third criteria used to evaluate a potential solution
+
+
+== Considered Options
+
+This section lists the alternatives (or choices) investigated.
+The selected options should be listed first in the end here.
+
+=== First Option
+
+Description of the first option
+
+
+=== Second Option
+
+Description of the second option
+
+
+=== Third Option
+
+Description of the third option
+
+
+== Decision Outcome
+
+In the context of <use case>, facing <concerns> we decided for <option> to achieve <quality>, accepting <downside>.
+
+
+Some examples of justifications are: 
+
+- It is the only option that meets a certain decision driver
+- It resolves a particular force
+- It comes out best when comparing options
+- We applied this design pattern several times with success in the past and we have similar requirements here
+- We performed a proof of concept and the results were convincing
+- We have the relevant skills for this specific approach
+
+
+== Consequences
+
+=== Advantages
+
+Advantages of the selected option.
+
+
+=== Drawbacks
+
+Drawbacks of the selected option such as suspected API breaks, code migration required, database migration required, code to deprecate, new patterns to use, change in dependencies, performance impact, increase in continuous integration time, etc.
+
+
+== More Information
+
+This section should contain additional details on the decision made such as:
+
+=== Implementation
+
+- How this decision should be realized?
+- Which steps should be taken for the implementation?
+  - Should we start frontend first or backend first?
+  - Do we need a temporary capability to disable the feature while it is being developed?
+  - Do we need to perform some refactoring to prepare this work?
+
+
+=== Decision Details
+
+- Additional evidence for the decision outcome (possibly including assumptions made).
+- Details of the team agreement on the decision (including the confidence level).
+- When it should be re-visited
+
+
+=== References
+
+- Links to other decisions and resources might appear in this section as well.