Your plugin can open a dialog at any point with LrDialogs.presentModalDialog() or .message(), even if the plugin is running in background.
If you want to use the operating system's notification mechanism, your plugin could invoke a command-line program. A quick Google suggests:
Yes, that is true.
My problem was more about how to do it from my server to Lightroom.
We could do polling : every X minutes send a REST request to my server to see if I need to show notification
But it means that I send tons of request to my server. Not very efficient.
Any clue on this?
More often than not, the actual fraction of network bandwidth and CPU consumed by the polling would be negligible. Trying to avoid polling is understandable, but properly designed polling usually doesn't have a practical impact.
To avoid polling, your plugin could open a long-running HTTP request to the server, and the server only replies when it has something to say.
Thank you John for your reply.
Do you have any example to get a properly designed polling?
Or for a long-running HTTP?
Thank you so much for your help,
Re polling, I haven't implemented anything in the LR context with HTTP. But as a thought experiment, suppose your plugin sent a request once a minute to your server, and usually the response was "Nothing available". For a single client, the increase in CPU on client and server and bandwidth wouldn't be measurable, I think. But as you increase the number of clients, it might turn into a real cost on the server. But a modern Web server can handle ten small requests/second without blinking an eye.
Re a long-running HTTP request, HTTP 1.1 connections are by default persistent, but they time-out after inactivity (based on default settings of most Web servers, I think). So you'd either have to change the default setting on your Web server or have the plugin send application-level keep-alive messages when there's no activity. Sending keep-alive messages would still be less expensive in CPU and bandwidth than polling HTTP requests, since you wouldn't have the overhead of the three-way handshake of opening and then closing TCP connections.