templated algorithms (like string::Parse) should show the template arguments in the Box on canvas

I think templated algos should show its template params on the algorithm canvas.

User can't possibly remember which template specialization he put on the canvas.

changed milestone to %BP

added C-webui P-high T-feature labels

changed title from templated algorithms (like string::Parse) to templated algorithms (like string::Parse) should show the template arguments in the Box on canvas

mentioned in issue #65 (closed)

Do you prefer prefix like this? Or should it be for example just "string::Parse"?

What I meant was that it should show template parameter, not fully qualified names. i.e. "string::Parse @Automaton" should somehow visualize both "Parse" (as it does now) and "@Automaton".

(edit: Perhaps without the at-sign)

TBH I'm not sure where those names you show in the picture come from, I don't think we have string::LinearString<>::Parse algorithm. Or do we?

However, it might be good if we somehow found a way to show fully qualified name as well because we have some duplicates (i.e. if you put automaton::simplify::Trim and grammar::simplify::Trim algorithms on the canvas, they both show Trim (AFAIK)).

But that's probably for another issue?

Oh, I thought that the fully qualified name indicates the parameter. I think I don't fully understand what this template parameters is, should it be visualized for example above the name?

We have string::LinearString<>::Parse, you can find it under raw -> Parse, I was playing with the name string and template params atributes in the code and the screenshot is the result.

It is definitely for another issue, but I'm not sure if using fullly qualified name on all of the boxes is a good idea, I think we could show the fully qualified name here #57 (closed) just to keep the boxes readable.

I think I don't fully understand what this template parameters is

I will try to clarify:

The algorithms in the list are sorted by fully qualified name of the class implementing the algorithm. I.e., ALT algorithm automaton::simplify::Trim is a C++ class in ALT called Trim in the namespace automaton::simplify. The algorithm menu in the WebUI categorizes the algorithms (their implementation classes) by the namespaces. You can find automaton::simplify::Trim in the menu under automaton -> simplify.

Some classes are parametrized, for instance string::Parse class (class Parse under string namespace) can be parametrized with type automaton::Automaton, grammar::Grammar, etc. In the corresponding C++ code you would refer to the class as to string::Parse<automaton::Automaton> (or something like that). If you look into the algorithm list, these "template parameters" are shown with the @ as individual overloads (The @ notation is taken from the CLI (cc @travnja3) -- if you want to parse automaton from the string, you just write execute string::Parse @automaton::Automaton <input>.

The essence of the issue is that if you want to parse an automaton from the text you'd place string -> Parse -> @Automaton box on the canvas. But if you do so, the box on the canvas does not show the information that is is actually an automaton parsing box. It will say just Parse which is really bad. Consider you were parsing an automaton successfully but now you want to parse a regexp and you leave this automaton parsing box in the graph. You will (amazingly) fail with the error Evaluation of algorithm string::Parse failed. Parse callback not registered. because you input a regexp into the automaton parser but you don't know that it's an automaton parser.

Also (just thinking out loud): I'm leaving for discussion between you and @travnja3 whether we should list individual templated algorithms as overloads (current status) or whether we should use one overload only and let user select the template parameters from some dropdown menu (either in the algorithm list or on the canvas). I don't care; actually both LGTM.

We have string::LinearString<>::Parse, you can find it under raw -> Parse, I was playing with the name string and template params atributes in the code and the screenshot is the result.

See above. This is not actually string::LinearString<>::Parse but raw::Parse<string::LinearString<object::Object>>.

It is definitely for another issue, but I'm not sure if using fullly qualified name on all of the boxes is a good idea, I think we could show the fully qualified name here #57 (closed) just to keep the boxes readable.

Yeah, I thought about some checkbox showing it or perhaps an icon on the box that you can click and it will show you the "detail" of the box. It's not something crucial IMHO. It's just a detail that'd be nice to be addressed with a simple short code. You can open another issue if you want (no need to). I'm willing to implement it on my own (again, discuss with @travnja3).

Thanks for the clarification:)

@travnja3 overloads list: From the user's point of view, I like the idea with just one overload and selecting template parameter on the canvas (showing template parameter under the name with a possibility to change it). But I am not sure how much complicated the implementation would be.

fully qualified name: I would leave it in a scope of #57 (closed) and show fully qualified name with other details after clicking on some icon.

First of all, thank you @peckato1 for a nice summary. Indeed the issue with an already placed Parse box is that it does not present anyhow what it parses. The proposed two approaches from that point of view are equivalent. However, the dropdown menu on the already placed box could be more practical (at the same time, it would require a bit more coding). Similarly, the dropdown menu in the algorithm selection area would nicely decrease the amount of displayed information-

The template parameter on, for instance, string::Parse is technically a part of the name so it should be always visible.

I propose something like this (I'm also a bit in favour of selecting the parser subcategory in the canvas (the 'v' is the representation of the dropdown menu):

+-------------------------+
|  string::Parse          |
|                         |
|  automaton::Automaton v |
+-------------------------+

Finally:-D

I just realized that the algorithm box (Node component in Node.tsx) renders in raw svg. I'm not sure how to "inject" MUI Dropdown menu there.

Then we should just display the subcategory and maybe implement the dropdown menu in the algorithm selection area?

Maybe we can experiment with https://stackoverflow.com/questions/6538918/can-i-embed-html-into-an-html5-svg-fragment ? Unsupported in IE but that does not bother me.

Tried to experiment with the dropdown menu in <foreignObject> element with some static values. The implementation will be more complex than implementation of the selection in the algorithm list, but it's more user friendly and the reduction of the algorithm list is a big plus.

mentioned in commit b49a57ef

mentioned in merge request !34 (merged)

mentioned in commit 00159363

mentioned in commit 5c893477