Hide popup window

Hello!

I'm using the urlload command to pull info from a website, and then use a regular expression to get exactly what I want, but I'd like to get rid of the popup window shown by the urlload command.

I put the command inside a {note: preview=no}, and it hides the urlload, but it still shows the result from the regular expression.

I'd just like it to apply the snippet without any popups. Would that be possible? Or are there any plans to implements this?

Thank you

No, it is not possible. We don't have plans implementing it.

Hi @Charlie , just to add some more details: urlload needs to fetch data from another remote server. There will always be some delay between triggering your shortcut and seeing the response. The clearest way to communicate this delay is to show the popup window like you currently see. This also allows you to double check that the response you got from the remote server is correct.

Hope this helps!

I get that the nature of http requests is sometimes sluggish and the user experience will be less than ideal without some feedback. However, consider a few other options such as in place text animation; three dots repeating, or a subtle tone.

There are use cases where there is no need to communicate anything except the outcome of the process. In fact, the outcome is the only thing that certain automations should disclose.

Lastly, consider the case where the HTTP request is into a socket-layer real-time streaming network with 10ms latency. In this case, urlload will always be instant; the dialog is simply additional friction, distraction, and a drag on the process from the user's perspective.

Please, at least consider the option of suppressing the dialog because in some cases, it is counter-productive, and Text Blaze is all about hyper-productivity, right?

Thanks Bill for your detailed comment. Your suggestion makes sense :slight_smile:

In your specific case, what is the full snippet? Is it just sending a message into a socket-layer connection. Can you copy and paste it here to share it with me?

I would love to share that particular snippet, but it's a touchy area that involves client data. But, imagine any HTTP POST going to something like this. It's just a proxy for communicating with our SlipStream real-time layer. Using such a gateway we can monitor highway locations and edge devices. Imagine this scenario - a Text Blaze snippet that always retrieves the current traffic flow at a given location. Think \\tf and a pick list of locations. This would make it possible for our team to pull in traffic data to any web app, Slack, email, etc. this is an example where the dialogs are helpful. But the communications mechanism is the same and some commands require zero interaction.

You might ask - well, why not just query these appliances through an HTTP REST interface? The answer is nuanced but the underlying reason - there are no REST interfaces in our machine vision highway analytics systems; it's all real-time messaging with sub-100ms performance and all without the security constraints and risks of REST.

Yes, and sometimes those messages cause other data to be retrieved. As much as I love Text Blaze, those dialogs stand in the way of an elegant solution from time to time. :wink:

import express from 'express';
import WebSocket from 'ws';
import http from 'http';
import path from 'path';
import faker from 'faker';

const app = express();
const port = 3000;
const server = http.createServer(app);
const wss = new WebSocket.Server({ server });

wss.on('connection', (ws: WebSocket) => {
  console.log('establish websocket connection');
  ws.on('message', (message) => {
    console.log('received: %s', message);
  });
});

app.get('/client/:id', (req, res) => {
  res.sendFile(path.resolve(__dirname, `./public/client-${req.params.id}.html`));
});

app.get('/external-api', (req, res) => {
  wss.clients.forEach((client) => {
    if (client.readyState === WebSocket.OPEN) {
      client.send(faker.internet.email());
    }
  });
  res.sendStatus(200);
});

server.listen(port, () => console.log(`http server is listening on http://localhost:${port}`));

Alright, thanks Bill :slight_smile: I'll think about it, but no promises yet. There's a lot of moving parts behind this popup window, and I'll need to make sure we address everything around it.

Will keep you posted!

1 Like