UI2024: Enable user configurations in Network Settings about dayon HOT 17 CLOSED

I think your clear thoughts on "vendored" instances would be great to have in the descriptive section for the .yaml files (the "philosophy" behind them, not only the how-to)

Here is my suggestion (to save you the pain of updating the documentation) Quick start
section: "via configuration file" :

Configuring Dayon! using configuration file
Since version v11.0.5, the connection parameters can be stored in a configuration YAML file.

This makes it possible to override user settings since the configuration from the YAML is always read and evaluated on start up. Users can make changes inside the application, but these only last until the next start if a YAML configuration is in place.

The primary use case for YAML configurations would for organizations that want to use a self-hosted token server instead of the public token server, or set specific host details and make assisted autoconnecting when started.

The structure of the assisted YAML is extremely simple:

host: "an.example.com"
port: 8080
# autoConnect: false
# tokenServerUrl: "https://example.org/token"

• To make assisted use other token server than the default public token server, assisted.yaml, just uncomment the following line and set the appropriate URL: # tokenServerUrl: "https://example.org/token"
  (Note: make sure to use the same as assistant)
• To prevent the assisted from automatically connecting right after the start, assisted.yaml just uncomment the following line: # autoConnect: false

The assistant also has a YAML configuration file.

• To make assistant use other token server than the default public token server, assistant.yaml, just uncomment the following line and set the appropriate URL: # tokenServerUrl: "https://example.org/token"
  (Note: make sure to use the same as assisted)

The YAML file(s) can be saved under the name assisted.yaml and assistant.yaml either in the Dayon! home directory, in the user directory, or in the same directory as the .jar, resp. .exe file. This order also corresponds to the priority with which they are taken into account in the case of multiple configurations exist. (first one wins)

...and move the section "Automatic connection of the assisted" to the bottom of the page and rephrase it as follows:

Automatic connection of the assisted via command line
The host name or IP address and port of the assistant can be passed via command line parameters, where ah=host or IP address, and ap=port number:

dayon_assisted.sh ah=example.com ap=4242 (Linux/macOS)
dayon.assisted ah=example.com ap=4242 (Linux Snap)
./assisted.sh ah=example.com ap=4242 (Linux Quick Launch)
java -jar dayon.jar ah=example.com ap=4242 (Windows/Linux/macOS)
assisted.exe ah=example.com ap=4242 (Windows Quick Launch)

If the assisted is started with these example parameters, it connects directly to the host "example.com" and port "4242".

from dayon.

As always - thanks ,for your considerations of my ideas.

This and the two other remaining issues are actually my last suggestions, as it seems I cannot come up with any more potential improvements to this great software.There have been a steep development his past weeks and I am quite excited at how it has turned out!

Some context regarding this feature request is that I have setup a new permanent public RVS. This is my donation to the project and its users. You can test it by using tokenServerUrl: "https://dayon.helioho.st/rvs/"

• This additional RVS provides redundancy as a simple security measure. (just in case either of the two public RVS fail, there would still be another to choose as fallback.) It also shows others how simple it actually is to set up an RVS to use. (I know Dayon! is positioned for helping friends and family, but I see a genuine case also for more professional scenarios. This is a way of making it easier for them to adopt this great solution and grow the user base)
• My starting point for this feature was actually how to make the .yaml config opportunities more visible and user-friendly (as an example I was initially not aware of the autoconnecting to an IP address, which is quite a smart way to not need to depend on an external RVS at all.
• Overall - making config changes for Assisted would be a lot swifter for Assistant (rather than navigating to appropriate folder of Assisted to copy/create/edit assisted.yaml outside of the app).

In the coming days I will look at the new web pages in Swedish and provide suggested adjustments to the wording (if needed),

from dayon.

Wow, thank you!
An alternative RVS for redundancy surely is a great thing to have!

Concerning the .yaml files, I'm not so sure if this would be the best way to go for the suggested integration into the user interface.
As all other settings end up in the .properties files, which is also the standard way for Java application to persist their settings/parameterization while .yaml files are very popular among cloud native apps. So I'll prefer to keep the .yaml files "read only", just to offer a backwards compatible way to override connection related parameters.

To cut a long story short: I'll start implementing the integration into the UI as proposed, but will use the existing properties files to store the settings.

from dayon.

Almost there
Assistant:

Assisted:

from dayon.

No, the default is "read only".

As it's implemented now, all functionality from the .yaml files remains unchanged, thus it will still be possible to override "everything" by placing individual yaml configuration files.

The consequence of this is that the configuration from the yamls is (always) read and evaluated on start up.
The user can adjust the connection settings, but these only last until the next start of the application if a yaml-configuration is in place.

I'd prefer to keep those two configuration paths as separated as possible, because it could quickly become confusing.

The primary use case for the yamls would be "vendored" instances, which should use a custom RVS by default.
While the configuration via the UI would rather serve use cases, when the assistant instructs the assisted to use a specific RVS or to switch to another RVS due to an outage.

I didn't implement the "Do not use Token Server" option, because I thought that one can simply not use the feature, if he/she/it doesn't want to.

from dayon.

Thanks again, I'll make those suggested changes as soon as I get to it.
I was considering to shorten or split up the quickstart page, as it keeps growing constantly - but i have shied away from the effort so far.
I already added the section to the README.md, but maybe the list of the available public token servers should also end up on the - you might have guessed it - quickstart page ;)

from dayon.

Well, I started restructuring the quickstart and settings pages. But it will take some time until it's done.
While going through the lines, which in some cases are more than 10 years old, I even spotted a minor bug: the counters don't have a strictly deterministic order :)

from dayon.

This would definitely simplify the usage of custom RVS. But I'm not sure if it justifies the effort for the implementation.
I don't know if people even really have a need for this. Who has the motivation to run a custom RVS which has to be communicated to all parties - if there is one that can be used for free?

from dayon.

Excellent! As you have understood already, I do not know enough programming. Your suggestion is a perfect solution to getting it right!

from dayon.

Looking great!

from dayon.

Q: the default box looks like it is editable.

Just to clarify my suggestion, just in case: I think it should be "read only" so the user always can revert back to it if needed.

Perhaps the default could be overwritten in .yaml like before (for backward compaitibility), and then be visible there (i.e. if .yaml contains "dayon.helioho.st/rvs/" then that is visible in "default box" inside app)

Or perhaps .yaml files are no longer needed with this enhancement?

Just a note, you understand all this so much better 👍

from dayon.

Thanks for the good explanation, makes a lot of sense ❤️

from dayon.

Idea: perhaps add a new short section at the bottom of How to run a custom rendez-vous server (RVS)

Public token servers

Below you find a list of available public token servers that are free to use.
Would you like to contribute and add your RVS to the list? let me know!

Check the availability of a token server by clicking on its link. If it shows the right version number it is active.
https://fensterkitt.ch/dayon/
https://dayon.helioho.st/rvs/

from dayon.

I like it!

Perhaps Quickstart could be reorganized (and split) as follows, as this would not require any new texts or images:

Note: the numbering etc. below is only to give you readability, I imagine regular headline formats etc.

Preparing & Connecting

1. Connecting

• Assistant computer
  (a) generate and copy token (add sentence:
  "If you do not recive a token - make sure Dayon! is whitelisted in your firewall"
  (b) alternative: Show IP and copy
  (c) press play

section "Now you can ask the assisted to connect"

• Assisted computer
  (a) press play
  (b) fill in token
  (c) alternative: select tab + fill in IP address

section "You're now connected and monitoring the remote computer."

add new sentence: "Note: If you are unable to connect by following the instructions above, you should check that you have the right settings" (settings=link to the suggested new page: Settings - see further down)

2. Managing the Session

• Assistant computer
  (a) fit screen
  (b) maintain aspect ratio
  (c) control mode
  (d) clipboard transfers
  (e) send special keys to assisted

  • [win] or [cmd] key press
  • send [ctrl] key press

  (f) take screenshot of assisted
  (g) reset screen capture (trash bin),
  suggested: "the reset screen capture (trash bin icon) clears all cached screen data and reloads a new screen capture from assisted."
  (h) start an online meeting

section "Statistics Counters" moved from Support Page

Suggested new page: Settings (placed between Quick Start and Download in the Top Menu)

Settings & Configurations

1. Settings

• Assistant computer
  (a) screen capture config
  (b) compression config
  (c) connection settings (the new version you are working on)
  (d) Language (or inside Look & Feel? sorry, I forgot if it is coming back or was dropped)

• Assisted computer
  (a) UAC settings (Windows only?)
  (b) connection settings (the new version you are working on)

2. Automatic connection of the assisted via command line
   (new suggested text earlier in this thread)

3. Configuring Dayon! using configuration file
   (new suggested text earlier in this thread)

4. Public token servers
   (new suggested text earlier in this thread)

To keep the number of web pages down, simply delete the web page Feedback and adjust the opening statement on the web page Support as follows (if you like it)

Support

Your feedback is more than welcome! Post your question or open a new issue on GitHub.

from dayon.

UI2024: connection settings

I just realized that since .yaml files overwrite any user settings this would be good to let the user know:

Perhaps when starting the connection setting function in the app, it should check if it finds any .yaml files in the designated folders.

If it does, it would show a pop up window stating something like "Warning: a configuration file has been found. Any changes made will only last until the next start of the application."

(I believe this would reduce frustration for users that have not read those YAML sections online before using the app.)

from dayon.

Good that they get a rework then. Thanks for your efforts!

from dayon.

UI extensions is included in release v14.0.0, the restructuring of the documentation is ongoing.

from dayon.