[Enhancement] - Document how to use Visual Studio Code for add-on development using openHAB inside a docker container.

[pgfeller]

During the work on the huesync binding I learned that it is very convenient to use a docker container with a openHAB instance to debug the binding you're working on.

This allows you to work on a development machine without the need to install openHAB directly on it (I do not want/need it on that device). It also allows you to work next to a productive instance and/or update/reset/change the server environment easely.

The setup is simple - but still requires some knowledge - therefore I propose to add information about this possibility and how to set it up to VSCode.

I could update the documentation during my work on the binding if you would like to have this.
@stefan-hoehn ➡️ In that case you can assign this issue to me.

[stefan-hoehn]

I looked into our docs where this would probably fit best.

IMHO, the place to put it would be

https://next.openhab.org/docs/developer/#setup-the-development-environment

where a also found an issue we could improve: if you click on one of the IDEs, ie. VSCODE it forwards you to

https://next.openhab.org/docs/developer/ide/vscode.html

which could never be reached nor found via the menu on the left.

With the new submenu option like in

we should add these as well first:

I would then first provide a PR for that. WDYT?

[pgfeller]

We may consider/discuss if we add the .vscode folder to the .gitignore file to simplify the work with vscode (avoid IDE configuration in commits).

bundles/**/.vscode

openhab/openhab-addons@3baf75d

[lsiepel]

I have been using vscode now for some years and never had issues with this, but obviously it also won;t harm, so if you create a PR we can add it.

[pgfeller]

Indeed - it is not difficult to use; the thing that I have in mind is to point out that a binding can be handled as isolated project (as on "older" machines the full repo is a big heavy) - and then also some configuration adjustments are not necessary.

Additionaly I use a docker container(s) with different versions to run the OH runtime and to load the binding. This is very convinient for testing and there's no need to install OH on the machine you develop (my laptop in this case). Setup and versions are very easy to manage that way - but it needs some special configuration options of karaf and the correct configuration of the vscode debug task for such a setup to run smoothly.

Again - no rocket sience - but it took my a while to have the idea and to find out how to configure a nice build/setup. For example it runs and fixes the code formating - as I had many CI build fails due to code formatting errors.

Unfortunately the docu is not the first on my TODO list ... first I would like to finish hue sync and then find a solution for the jellyfin problematic (as this affects my setup ...). But: I'm slow - but I do not forget ... (actually, I use/make notes - as my 🧠 is not 20 anymore).

---

Off topic: As I know you also feel limited by the number of emjis supported by unicode, I recommend the following page:

https://www.nerdfonts.com

😉