Code to reproduce this issue:

A->A.method()

https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html#operator-break

Please first create the DSL and have it reviewed together with me.

We will release a version from this repo, then add that as mermaid's dependency and open a smaller PR.

In our current implementation, we use the following syntax to control the style for both comments and messages. However, it would be good (?) that we could control them separately.

// [red] comments
A.method

The proposed solution:

1. <red> controls comment only;
2. (red) controls message only;
3. [red] controls both comment and message.

A.method1 {
    // comment
    @return B->C: Self Async
}

Correct behaviour: tag - v2.0.38.

Wrong behaviour: tag - v3.15.4

Acceptance criteria

Must

• Double click to start editing, Enter or losing focus to save the new value.
• Escape special characters.

Nice to have

• Allow editing stereotype

There is a bit of a problem when rendering line 15 ( "space in name"->"bg color".syncMethod(from, to) ):

Sample DSL code: src/demo1.js：

// comments at the beginning should be ignored
title This is a title
@Lambda <<stereotype>> ParticipantName
group "B C" {@EC2 B @ECS C}
"bg color" #FF0000
@Starter("OptionalStarter")
new B
ReturnType ret = ParticipantName.methodA(a, b) {
  // Customised style for RESTFul API - \`POST /order\` <br>
  ReturnType ret2 = selfCall() {
    B.syncCallWithinSelfCall() {
      ParticipantName.rightToLeftCall()
      return B
    }
    **_"space in name"->"bg color".syncMethod(from, to)_**
  }
  // A comment for alt
  if (condition) {
    // A comment for creation
    ret = new CreatAndAssign()
    "ret:CreatAndAssign".method(create, and, assign)
    // A comment for async self
    B->B: Self Async
    // A comment for async message
    B->C: Async Message within fragment
    new Creation() {
      return from_creation
    }
    return "from if to original source"
    try {
      new AHasAVeryLongNameLongNameLongNameLongName() {
        new CreatWithinCreat()
        C.rightToLeftFromCreation() {
          B.FurtherRightToLeftFromCreation()
        }
      }
    } catch (Exception) {
      self {
        return C
      }
    } finally {
      C: async call from implied source  
    }
    =====divider can be anywhere=====
  } else if ("another condition") {
    par {
      B.method
      C.method
    }
  } else {
    // A comment for loop
    forEach(Z) {
      Z.method() {
        return Z
      }
    }
  }
}

Sample code

//[red] note that both comment and `method` are red
A.method {
  //[red] note only comment is red. Self message should also be red
  selfMessage
}

WIP

Code to reproduce this issue:

// Issue #88
A->A.method {
  // [bold, red]Issue #89
  B:async message
}

This issue may be related to #88 .

There are two types of shortcut keys: Navigation and Operation.

Navigation

Commonly, the active selection is emphasized in a certain way. For instance, the subsequent diagram employs a ring for highlighting.

The sequence of selection should naturally align with the visual arrangement of the elements, enabling user navigation via arrow keys.

Operation

It is a lot more complex. Here are some ideas:

• Start editing: select and start typing or double click
• Complete editing: Enter
• Discard editing: ESC
• Text wrap: Shift_Enter (DSL update needed)
• If participant is in editing mode, clicking Tab will going into next participant and enters editing mode; if that is the last participant, create a new participant

Value

ZenUML DSL is designed to be intuitive. However, due to the complexity of nature of sequence diagram, it is hard for users to grasp all syntax quickly.

Tooltips is to provide in-context help to end users. Those tooltips can be display at the bottom of the canvas. It can also link to our documents specifically created for the component.

Components

Next steps

Provide more information include typical syntax in the tooltip.

// [red, bold]
A.method()

Should render the message in red and message text in bold. It must only style the current message and should not have impact on its children or siblings.

We can do a lot more with this syntax.
tailwind css and s

hortcuts can be used:

text-red-900
text-red
red
font-bold
bold

Icons are used in sequence diagrams to represent certain elements (e.g. Actor) or to add notes for clarification(e.g. Boundary, or Entity), show that an participant belongs to a type (e.g. Service).

In ZenUML, we use the following syntax to link an icon to a participant:

@IconName participantName

We already support a list of icons. This issue is to add more icons to the support list.

Checklist

• Add the support of icons in the below list
• Create a page to document all supported icons - ZenUml/docs#11

They have been split into groups so we don't have to finish all in one release.

Primary participant types

1. Client
2. Server
3. Browser
4. Service
5. Controller
6. API (Application Programming Interface)
7. UI (User Interface)
8. Mobile
9. ExternalSystem

Secondary participant types

1. Application
2. LoadBalancer
3. Network
4. Cache
5. WebServer
6. MessageQueue
7. Scheduler
8. Gateway
9. AuthenticationService
10. MailServer

Common applications and services

1. GitHub
2. Docker
3. GitLab
4. Jenkins
5. PostgreSQL
6. MongoDB
7. Kubernetes
8. Apache Kafka
9. Elasticsearch
10. Auth0
11. Redis

This is to understand how often a feature is used. Features are listed here: https://zenuml.atlassian.net/wiki/spaces/Doc/pages/518848513/Sequence+diagram+syntax.

Currently when you click Zoom in or out button, the button will move away.

Moved to here from ZenUml#435

I'm importing mermaid-zenuml into a kotlinjs project, and get an error when passing it to registerExternalDiagrams:

r2 is not a function', message: 'detector2 is not a function', hash: 'TypeError', error: TypeError: detector2 is not a function
    at detectType (webpack-internal:///../../node_modules/me…}error: TypeError: detector2 is not a function
    at detectType (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:2420:22)
    at getDiagramFromText (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:3724:17)
    at Object.render$1 [as render] (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:6044:18)
    at eval (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:6346:18)
    at new Promise (<anonymous>)
    at performCall (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:6345:31)
    at executeQueue (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:6314:15)
    at eval (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:6361:5)
    at new Promise (<anonymous>)
    at render (webpack-internal:///../../node_modules/mermaid/dist/mermaid-934d9bea.js:6344:10)hash: "TypeError"message: "detector2 is not a function"str: "detector2 is not a function"[[Prototype]]: Objectconstructor: ƒ Object()hasOwnProperty: ƒ hasOwnProperty()isPrototypeOf: ƒ isPrototypeOf()propertyIsEnumerable: ƒ propertyIsEnumerable()toLocaleString: ƒ toLocaleString()toString: ƒ toString()valueOf: ƒ valueOf()__defineGetter__: ƒ __defineGetter__()__defineSetter__: ƒ __defineSetter__()__lookupGetter__: ƒ __lookupGetter__()__lookupSetter__: ƒ __lookupSetter__()__proto__: (...)get __proto__: ƒ __proto__()set __proto__: ƒ __proto__()

Dumping out what I'm registering to console.log right before the call, I get:

{id: 'zenuml', detector: ƒ, loader: ƒ}
detector : (txt) => { return /^\s*zenuml/.test(txt); }
id : "zenuml"
loader :  async () => {…}
[[Prototype]] : Object

...so I'm pretty sure it's not a case of mangled names.

Is https://www.npmjs.com/package/@mermaid-js/mermaid-zenuml up to date enough?

One note is that I had to mangle the import path to get a clean module mapping:

@JsModule("@mermaid-js/mermaid-zenuml/dist/mermaid-zenuml.core.mjs")
@JsNonModule
external val ZenUML: ExternalDiagram

https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html#operator-critical

Please first create the DSL and have it reviewed together with me.

Currently, the core renderer will always render a simple diagram with only one participant ZenUML. It is a workaround. In the future, it should show a loading icon.

The following DSL renders an empty diagram instead of a proper diagram with empty title.

title
A.method()

Duration Constraint

A constraint on a duration.

#Notion
A duration constraint on a sequence diagram may be show by drawing a vertical line with open arrowheads at both ends between the vertical position of two events. An expression for the duration is placed in braces over the center of the arrow. The constraint may also be shown as a text expression in braces.

Source: https://www.oreilly.com/api/v2/epubs/0321245628/files/0321245628_ch14lev1sec193_image01.jpeg

Consider this simple HTML page. Adding the ZenUML diagram affects rendering of the <h1> element: the font changes and the text becomes small.

It seems that the <style> added by the JS is affecting the entire page? Am I doing something wrong here?

<!DOCTYPE html>
<html lang="en">

<head>
</head>

<body>
  <h1>H1 Header</h1>

  <pre class="mermaid">
    zenuml
        Alice->John: Hello John, how are you?
        John->Alice: Great!
        Alice->John: See you later!
  </pre>

  <script type="module">
    import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs';
    import zenuml from 'https://cdn.jsdelivr.net/npm/@mermaid-js/[email protected]/dist/mermaid-zenuml.esm.min.mjs';
    await mermaid.registerExternalDiagrams([zenuml]);
  </script>
</body>

</html>

It's changes the default style of a webpage.

As shown in the below diagram, the Lifeline would have been visible under the participant box if the participant box had a transparent background.
This make it difficult for theme designers to design a them with transparent participant background.

Code to reproduce:

ALPN as _ALongParticipantName_MustUseAs_
A

A -> A: message with 'From' defined, and pre-declared

A ->B.check{
  if (condition){
    C.method
  }
}

Note that the code is very carefully crafted to reproduce this issue.

Acceptance criteria

Must

• Double click to start editing, Enter or losing focus to save the new value.
• Escape special characters.
• In scope: sync messages, async messages, creation, return

A.method1 {
    B->B: Self Async
}

This is a regression issue possibly introduced by #98. However, the related PR fixed a lot of other issues and this case is rare and less impactful. I have created this issue to track it.

Chrome:

Safari:

Context

Emojis are considered characters on the web and in digital text. They are encoded as part of the Unicode standard. In Unicode, emojis have their own code points, just like letters, numbers, and special characters. For example, the emoji 😊 has the Unicode code point U+1F60A.

When you include an emoji in a text message, email, tweet, or any other form of digital text, it is treated as a single character, even though it may visually appear more complex than a letter or number. However, it’s worth noting that some emojis are made up of multiple Unicode code points, such as emojis that combine a base emoji with a skin tone modifier.

The syntax :unicorn: (🦄) is a type of shortcode used by certain platforms and applications to represent emojis. This particular syntax, where an emoji is represented by a short string of text enclosed in colons, is commonly used in Slack, GitHub, Discourse, and some other communication and collaboration tools.

Syntax in ZenUML

To support ZenUML, we will add emoji support to the following areas:

1. Participant Name
2. Message including parameters
3. Conditions for Alt and Loop fragment
4. Divider notes
5. Comments

Syntax must support two ways of embedding emojis: 1. use the emoji directly; 2. use shortcut.

Participant Name

Participant declaration

:unicorn:OrderService

Considerations

The main challenge in implementing this is to resolve ambiguity between an emoji and an async message which also use :.

An async message is like: A->B:async message. An emoji can be used like :unicorn:A->:butterfly:B: :cry: some more messages.

Background

When the DSL was first designed, it was heavily inspired by main stream OO languages such as Java, C++. In those languages, it is the case. The reason is explained (thanks to GPT) in comments below.

Syntax

// @fieldName FieldValue

Example:

// @author MrCoder
// @last-update 2023/07/11
// @description Order submitting process

Rendering

1. Meta data SHOULD be rendered as a table at the right bottom corner.
2. It MUST NOT be overlayed on top of messages or lifelines.

Example:

DSL:

title FireWeb on LaraSite Backend

FireWeb -> LaraSite.save(token, diagram) {
  FirebaseIdProvider.authenticate(token)
  save(diagram)
  return diagram_link
}

You can view the diagram at here.

So there is less distraction.

This card is to revert this commit: 861c706.

The above commit increases the minimum direct gap between Participants from an aesthetic standpoint. Horizontal space is a very scarce resource in sequence diagrams compared to vertical space. Our layout algorithm should try to minimize the horizontal width as much as possible. Only when the number of Participants is less than or equal to three, should consider enhancing the aesthetic by increasing the width.

Scope

1. Viewing Only
2. For branches and messages

Nice to have

1. Persisting toggles

Context

When viewing a Sequence Diagram, sometimes, some details (be it messages, fragments or branches) become distractions. Users may want to temporarily hide it.

We have already implemented this on fragments.

Related Issues

ZenUml/jetbrains-zenuml#212