action command prompts #1661

pciavald · 2021-04-08T05:58:18Z

Implements support for action:prompt and action:notification

UnchartedBull · 2021-04-09T13:52:20Z

the socket service shouldn't be aware of the promptService. This should rather be handled by the event service and should be pushed through the eventSubject. This will then be received by the event-service to which the prompt-component should then subscribe. I think we can then also get rid of the prompt-service, since this should rather be fullscreen error, right?

I didn't had time to check out the notification service error today unfortunately, will do this tomorrow.

Edit: If the prompt-service is needed than this should subscribe directly to the event-subject.

pciavald · 2021-04-11T07:47:03Z

fullscreen error sound correct as a base for the prompts, i can add the buttons in there. Did you have a chance to take a look? that is our last blocker, the rest is improvement

pciavald · 2021-04-11T07:50:21Z

I can't see any reference to fullscreen errors in the code, is it something you're working on? Maybe in that case it would be better named fullscreen messsage that can be an error, printer notification or prompt.

UnchartedBull · 2021-04-11T22:24:32Z

Ah no that was more of a question on how stuff from the actions_command_prompt should be displayed. If it completely seizes printer operation in all cases it should be a fullscreen thing (like the sleep screen), otherwise it should be similar to notifications.

In the second case it would also make more sense to extend the notification component, instead of creating a new one.

pciavald · 2021-04-12T08:10:03Z

I think actually it makes sense to extend the notification component in both cases, i'll try it now

pciavald · 2021-04-12T12:30:40Z

@UnchartedBull I don't see how i can pass the prompt through the event service without heavy modification, as it needs at least a title and a list of choices. I will keep the notification service in the socket service until a better way to do it is described.

UnchartedBull · 2021-04-12T13:06:53Z

Create another interface in event.model.ts (UserPrompt i.e.), update the Subject to return either PrinterEvent or UserPrompt. Abstract function definition would look like this:

abstract getEventSubscribable(): Observable<PrinterEvent | UserPrompt>

Check what type the input is in event-service and act accordingly. Ideally this would be in two methods (handlePrinterEvent and handleUserPrompt), which would be called from the subscribe function. Move the logic / call of notification service to the handleUserPrompt function. This would then also allow the removal of prompt-service all-together and also allows the import of the NotificationService in the SocketService.

…ls and clarifying notification roles

pciavald · 2021-04-13T11:39:13Z

i've started from scratch, can you check the new architecture ?

UnchartedBull

Yes this looks really good! Definitely the right way to go here I think. There are some minor things, most of them are just me being curious though :D. It also would be great if you could attach a screenshot on how the choices thing looks like :)

Once the last few kinks are ironed out this is ready to be merged. I originally planed on releasing v3 on Friday, could easily postpone to Monday or Tuesday though, if this PR should make it into v3.

UnchartedBull · 2021-04-13T21:38:14Z

src/app/event.service.ts

+  // https://stackoverflow.com/questions/14425568/interface-type-check-with-typescript
+  // https://stackoverflow.com/questions/8511281/check-if-a-value-is-an-object-in-javascript/8511350#8511350
+  private isPrinterNotification(object: any): object is PrinterNotification {


Maybe another way of doing this would be to check whether the received message is NOT of type int (which would indicate that it's an enum, thus PrinterEvent). It should work (haven't tested it though), but might be a bit cleaner.

I wouldn't switch the logic around though, as the default should be handle PrinterEvent. Alternatively you could check whether the received message is of type object.

UnchartedBull · 2021-04-13T21:40:44Z

src/app/event.service.ts

+      // event is action:notification
+      // this.notificationService.setInfo(
+      //   $localize`:@@printer-information:Printer information`,
+      //   messages[event.message] || event.message
+      // );
+      // TODO: annoying as a notification
+      // should be put with an autoclear timeout in the bottom-right statusline


I think it still should be a notification, just to keep everything consistent. If this isn't too important it might be a good idea to introduce a fourth notification type with a white strip and just set a timeout here to clear the notification after 5s (is that enough time?).

What do you think of that?

I need to retest what exactly was being sent, but AFAIR it was every heat enable/disable message (not always coherent with the user actions) and all changes of % being broadcasted, really cluttering information. We have been using it for a month without these and it seems on-point.

UnchartedBull · 2021-04-13T21:44:02Z

src/app/notification/notification.component.html

+
+<div
+  class="notification-prompt"
+  *ngIf="notification.choices?.length > 0"


Wouldn't it be enough to check whether notification.choices exist here?

this is just in case an empty list is sent, we would not want to display a prompt without choices

UnchartedBull · 2021-04-13T21:48:58Z

src/app/notification/notification.component.ts

+    this.http
+      .post(
+        this.configService.getApiURL('plugin/action_command_prompt'),
+        { command: 'select', choice: index },
+        this.configService.getHTTPHeaders()
+      )
+      .pipe(
+        catchError(error =>
+          this.notificationService.setError($localize`:@@error-answer-prompt:Can't answer prompt!`, error.message),
+        ),
+      )
+      .subscribe();
+  }


this should be in system-service (or another service if there's one that's better fitting) since it won't be compatible with Klipper / other interfaces.

From now on all communication with OctoPrint should be behind an abstract service with a generic interface to enable easy integration of other printer software.

UnchartedBull · 2021-04-13T21:51:34Z

src/app/services/socket/socket.octoprint.service.ts

+    ];
+
+    plugins.forEach(plugin =>
+      plugin.check(pluginMessage.plugin.plugin) && plugin.handler(pluginMessage.plugin.data)


That definitely looks complicated (which isn't bad). Just curious: Will call this both check methods from the plugins array? Seems like a nice way to do this, since it's easily extendable 👍

Ok I think I understood it. Correct me if I'm wrong:

This will go through top to bottom and call the check method with the plugin string. If the check message returns true it will call the handler in the same object, thus handle the message. Otherwise it will just fall-through until it either matches or reaches the end of the array. Really elegant way of handling this 👍

stale · 2021-06-02T15:41:09Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

pciavald · 2021-11-23T18:12:34Z

I am sorry to announce that I do not have the work power to maintain all our changes in compliance with upstream requirements. This feature has been published to our repo CosmoDash.

pciavald · 2021-12-12T10:15:31Z

The code on this branch was in working state last time I checked so it should be pretty easy to finish up and merge !

pciavald marked this pull request as draft April 8, 2021 05:58

UnchartedBull mentioned this pull request Apr 8, 2021

action commands support #1624

Closed

pciavald added 3 commits April 13, 2021 12:02

change setNotification to setInfo conforming to standard logging leve…

ffee138

…ls and clarifying notification roles

implement printernotification socket event emitter

1ad7051

implement printernotification prompt

ba2a3a5

pciavald force-pushed the action-commands branch from 3e930a1 to ba2a3a5 Compare April 13, 2021 11:35

pciavald added 2 commits April 13, 2021 20:00

handle prompts correctly

2c69c5b

Merge branch 'upstream' into action-commands

242e395

UnchartedBull reviewed Apr 13, 2021

View reviewed changes

pciavald added this to the v3.1.0 milestone May 3, 2021

Merge branch 'main' into action-commands

b9eb29c

stale bot added the stale Stale issue label Jun 2, 2021

stale bot closed this Jun 5, 2021

pciavald removed the stale Stale issue label Jun 5, 2021

UnchartedBull reopened this Jun 7, 2021

UnchartedBull added the enhancement New feature or request label Jun 9, 2021

UnchartedBull modified the milestones: v3.1.0, v2.3.0 Jul 28, 2021

pciavald closed this Nov 23, 2021

jneilliii mentioned this pull request Dec 12, 2021

M600 not prompting #2498

Closed

UnchartedBull mentioned this pull request Jan 18, 2022

Action commands and printer notifications #2586

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

action command prompts #1661

action command prompts #1661

pciavald commented Apr 8, 2021 •

edited

Loading

UnchartedBull commented Apr 9, 2021 •

edited

Loading

pciavald commented Apr 11, 2021

pciavald commented Apr 11, 2021

UnchartedBull commented Apr 11, 2021

pciavald commented Apr 12, 2021

pciavald commented Apr 12, 2021

UnchartedBull commented Apr 12, 2021

pciavald commented Apr 13, 2021

UnchartedBull left a comment

UnchartedBull Apr 13, 2021

UnchartedBull Apr 13, 2021

pciavald May 12, 2021

UnchartedBull Apr 13, 2021

pciavald May 12, 2021

UnchartedBull Apr 13, 2021

UnchartedBull Apr 13, 2021

UnchartedBull Apr 13, 2021

stale bot commented Jun 2, 2021

pciavald commented Nov 23, 2021

pciavald commented Dec 12, 2021

action command prompts #1661

action command prompts #1661

Conversation

pciavald commented Apr 8, 2021 • edited Loading

UnchartedBull commented Apr 9, 2021 • edited Loading

pciavald commented Apr 11, 2021

pciavald commented Apr 11, 2021

UnchartedBull commented Apr 11, 2021

pciavald commented Apr 12, 2021

pciavald commented Apr 12, 2021

UnchartedBull commented Apr 12, 2021

pciavald commented Apr 13, 2021

UnchartedBull left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stale bot commented Jun 2, 2021

pciavald commented Nov 23, 2021

pciavald commented Dec 12, 2021

pciavald commented Apr 8, 2021 •

edited

Loading

UnchartedBull commented Apr 9, 2021 •

edited

Loading