[GH-ISSUE #420] Non-intrusive availability detection #1309

Closed
opened 2026-02-28 12:03:40 +03:00 by kerem · 8 comments
Owner

Originally created by @majkinetor on GitHub (May 17, 2023).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/420

Originally assigned to: @VShawn on GitHub.

Availability detection occupies center part of the screen, is on top, and there is no way to minimize it or terminate it once started. When troubleshooting server disconnection this leads to bad user experience that I just witnessed. Also there is popup at the end that you must OK.

Possible solutions:

  • Not making it on top, or putting MUCH smaller window in the screen corner (next to tray for example)
  • Remove separate popup, make OK button integral part of the first window (and allow ESC)
  • Or best, remove multiple popups and keep single one, add new availability tests to it and put it in the corner of the screen on top but allow it to be minimized
details

image

Use this instead:

| Availability detection      x _ |
|        Server     Result
|    1. Server 1     error      [⟳]  (red color)
|    2. Server 2     ok         [⟳]   (green color)
|    3. Server 3     3...2...   [⟳]    (no color)
| Total 3, 1 ok 1 error 1 running

In single run mode this window should autoclose if test is OK (same as now) and stay open on error. In bulk mode it should not close automatically.

This will go nicely with bulk testing we are plannning to do.

Originally created by @majkinetor on GitHub (May 17, 2023). Original GitHub issue: https://github.com/1Remote/1Remote/issues/420 Originally assigned to: @VShawn on GitHub. Availability detection occupies center part of the screen, is on top, and there is no way to minimize it or terminate it once started. When troubleshooting server disconnection this leads to bad user experience that I just witnessed. Also there is popup at the end that you must OK. Possible solutions: - Not making it on top, or putting MUCH smaller window in the screen corner (next to tray for example) - Remove separate popup, make OK button integral part of the first window (and allow ESC) - Or best, remove multiple popups and keep single one, add new availability tests to it and put it in the corner of the screen on top but allow it to be minimized <details><summary>details</summary> ![image](https://github.com/1Remote/1Remote/assets/85767/6315bc5e-91fb-4afd-953a-0f0a0e6bb212) Use this instead: ``` | Availability detection x _ | | Server Result | 1. Server 1 error [⟳] (red color) | 2. Server 2 ok [⟳] (green color) | 3. Server 3 3...2... [⟳] (no color) | Total 3, 1 ok 1 error 1 running ``` In single run mode this window should autoclose if test is OK (same as now) and stay open on error. In bulk mode it should not close automatically. This will go nicely with bulk testing we are plannning to do. </details>
kerem 2026-02-28 12:03:40 +03:00
Author
Owner

@VShawn commented on GitHub (May 18, 2023):

You found the place where I was being lazy during development :)

The point is, I don't want this popup to show in the taskbar, so the only way to remind people is to keep this window always on top. Otherwise, it might fall into background and no one would notice it.

putting MUCH smaller window in the screen corner

Putting the window in the center is the easiest option because it avoids position calculation issues with multiple displays. Perhaps adding the ability to drag the window (yes, I was being lazy here too LOL) could solve the problem

<!-- gh-comment-id:1552679086 --> @VShawn commented on GitHub (May 18, 2023): You found the place where I was being lazy during development :) The point is, I don't want this popup to show in the taskbar, so the only way to remind people is to keep this window always on top. Otherwise, it might fall into background and no one would notice it. > putting MUCH smaller window in the screen corner Putting the window in the center is the easiest option because it avoids position calculation issues with multiple displays. Perhaps adding the ability to drag the window (yes, I was being lazy here too LOL) could solve the problem
Author
Owner

@majkinetor commented on GitHub (May 18, 2023):

You found the place where I was being lazy during development :)

I always do 😄 , somehow I detect bugs in few seconds always.

The point is, I don't want this popup to show in the taskbar, so the only way to remind people is to keep this window always on top. Otherwise, it might fall into background and no one would notice it.

Just keep a small toaster next to a tray, I think that would be OK even with on top window. Here is more detailed mockup:

image

We will have option pending depending on number of testing threads (but we could go with 5-10 by default). This is example of bulk test, single connection test works the same just 1 connection and auto closes if OK (or better, it doesn't show at all if ok, but shows on err).

Perhaps adding the ability to drag the window (yes, I was being lazy here too LOL) could solve the problem

It should be on good spot to start with, user shouldn't generally mess with it. Tray is perfect option for that IMO and it should be small anyway, currently its too big

<!-- gh-comment-id:1552716613 --> @majkinetor commented on GitHub (May 18, 2023): > You found the place where I was being lazy during development :) I always do 😄 , somehow I detect bugs in few seconds always. > The point is, I don't want this popup to show in the taskbar, so the only way to remind people is to keep this window always on top. Otherwise, it might fall into background and no one would notice it. Just keep a small toaster next to a tray, I think that would be OK even with _on top_ window. Here is more detailed mockup: ![image](https://github.com/1Remote/1Remote/assets/85767/2e8444da-b747-41b9-a838-d7a4f5dcc43d) We will have option _pending_ depending on number of testing threads (but we could go with 5-10 by default). This is example of bulk test, single connection test works the same just 1 connection and auto closes if OK (or better, it doesn't show at all if ok, but shows on err). > Perhaps adding the ability to drag the window (yes, I was being lazy here too LOL) could solve the problem It should be on good spot to start with, user shouldn't generally mess with it. Tray is perfect option for that IMO and it should be small anyway, currently its too big
Author
Owner

@VShawn commented on GitHub (Jun 2, 2023):

image

image

is this ok?

<!-- gh-comment-id:1573253323 --> @VShawn commented on GitHub (Jun 2, 2023): ![image](https://github.com/1Remote/1Remote/assets/10143738/20acf540-03b4-4ed9-b745-11bd066c90c3) ![image](https://github.com/1Remote/1Remote/assets/10143738/3e639551-f0ae-420a-b032-1f027fc49fc9) is this ok?
Author
Owner

@majkinetor commented on GitHub (Jun 2, 2023):

Some comments

  • Numbers
    For example in title - Availability test ok: 1 err: 2
  • There is enough space to show connetion name, otherwise, it will be hard to know which connection is it particularly with IP case. Alternativelly, clicking on server can focus connection in main window
  • Use standard colors: green is good, red is error.

image

<!-- gh-comment-id:1573358347 --> @majkinetor commented on GitHub (Jun 2, 2023): Some comments - Numbers For example in title - `Availability test ok: 1 err: 2` - There is enough space to show connetion name, otherwise, it will be hard to know which connection is it particularly with IP case. Alternativelly, clicking on server can focus connection in main window - Use standard colors: green is good, red is error. ![image](https://github.com/1Remote/1Remote/assets/85767/f8c9b762-066c-4f7c-905f-3c40c3248f1f)
Author
Owner

@VShawn commented on GitHub (Jun 2, 2023):

For example in title - Availability test ok: 1 err: 2

it is none use here, this view is for available test before connection start, once any connect success, I will kill other ping tasks and close this pop and start connection, so user will not see any err connection.

This design make sense when address manual selectior is implemented.

I will take other comments, It may takes about my two days free time to achieve all UI effects:)

<!-- gh-comment-id:1573463336 --> @VShawn commented on GitHub (Jun 2, 2023): > For example in title - Availability test ok: 1 err: 2 it is none use here, this view is for available test before connection start, once any connect success, I will kill other ping tasks and close this pop and start connection, so user will not see any err connection. This design make sense when address manual selectior is implemented. I will take other comments, It may takes about my two days free time to achieve all UI effects:)
Author
Owner

@majkinetor commented on GitHub (Jun 2, 2023):

You should never close this window if there is any error, in any case.

This design make sense when address manual selectior is implemented.

But user can still run tag or use multi connect in which case behavior should be the same - close it if all is good, leave it open otherwise.

<!-- gh-comment-id:1573872276 --> @majkinetor commented on GitHub (Jun 2, 2023): You should never close this window if there is any error, in any case. > This design make sense when address manual selectior is implemented. But user can still run tag or use multi connect in which case behavior should be the same - close it if all is good, leave it open otherwise.
Author
Owner

@majkinetor commented on GitHub (Jun 6, 2023):

Comments on latest beta:

  1. Why did you create a separate window for each connection. The original idea was to have 1 dedicated window for this and add/remove connections to be tested in it. This way you have single interface for both bulk test and single test. The list was ment to keep items in until it is closed manually. So if I run 1 connection, it fails, then run another one, it fails again, I would have 2 failed items in the list. If I run the same connection 2 times it would just refresh existing item. If I close the window, entire list is gone. I thought this was obvious from the screenshots that always contained multiple connections (so single one was special case). When I bulk connect, I never see multiple connections now, but multiple windows.
  2. What is the point of minimize button, currently it just hides the window with no option to restore it

Its certainly better then before. The problem is, you introduce special cases (single vs multiple connections) , and good intreface avoids that.

details

image

<!-- gh-comment-id:1579081023 --> @majkinetor commented on GitHub (Jun 6, 2023): Comments on latest beta: 1. Why did you create a separate window for each connection. The original idea was to have **1 dedicated window** for this and add/remove connections to be tested in it. This way you have single interface for both bulk test and single test. The list was ment to keep items in until it is closed manually. So if I run 1 connection, it fails, then run another one, it fails again, I would have 2 failed items in the list. If I run the same connection 2 times it would just refresh existing item. If I close the window, entire list is gone. I thought this was obvious from the [screenshots](https://github.com/1Remote/1Remote/issues/420#issuecomment-1573358347) that always contained multiple connections (so single one was special case). When I bulk connect, I never see multiple connections now, but multiple windows. 2. What is the point of minimize button, currently it just hides the window with no option to restore it Its certainly better then before. The problem is, you introduce special cases (single vs multiple connections) , and good intreface avoids that. <details><summary>details</summary> ![image](https://github.com/1Remote/1Remote/assets/85767/c21549a6-4f33-42ca-b433-5df004e96687) </details>
Author
Owner

@VShawn commented on GitHub (Jun 7, 2023):

This window is a address switcher, and the task is to test the connection speed of each address of 1 SERVER, return the fastest one. If the connection fails, notify the server that there is no available address. It's not for showing the status of several servers.

↓ find the fastest address from here
image

  1. it make sense providing independent detection windows for each connection. This is just an automatic address switcher, not a address sniffer, If the connection is success, this window will automatically close within 1 second instead of requiring manual closing. Closing in 1 second means it cannot be used to display the ping status of the next connection.
  2. I don't want import another window controller for this small feature. The current design is the simple: exit automatically on success, stay on failure. The design you provided is complex: on failure -> check if there is the same error message in the window -> if not, create a new one -> if yes, overwrite it; On success -> check if there are further ping requirements. If not, close window(or hide window?); if yes, wait for it, and locks should be added to avoid concurrency issues since there only one message Window.
  3. yes minimize button just for hide the window while close button is for cancel the available detection task.
  4. Bulk open a large number of connections is rarely used. and the worst-case is displaying a bunch of available detection windows, which can be tolerated.
<!-- gh-comment-id:1579779759 --> @VShawn commented on GitHub (Jun 7, 2023): This window is a address switcher, and the task is to test the connection speed of each address of **1 SERVER**, return the fastest one. If the connection fails, notify the server that there is no available address. It's not for showing the status of several servers. ↓ find the fastest address from here ![image](https://github.com/1Remote/1Remote/assets/10143738/d8221133-53df-43a2-82b4-7920ee5bd2a6) 1. it make sense providing independent detection windows for each connection. This is just an automatic address switcher, not a address sniffer, If the connection is success, this window will automatically close within 1 second instead of requiring manual closing. Closing in 1 second means it cannot be used to display the ping status of the next connection. 2. I don't want import another window controller for this small feature. The current design is the simple: exit automatically on success, stay on failure. The design you provided is complex: on failure -> check if there is the same error message in the window -> if not, create a new one -> if yes, overwrite it; On success -> check if there are further ping requirements. If not, close window(or hide window?); if yes, wait for it, and locks should be added to avoid concurrency issues since there only one message Window. 3. yes minimize button just for hide the window while close button is for cancel the available detection task. 4. Bulk open a large number of connections is rarely used. and the worst-case is displaying a bunch of available detection windows, which can be tolerated.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/1Remote#1309
No description provided.