[Bug] Geolocate-controll styling

[CommanderStorm]

Describe the bug
The geolocatecontroll does not respect our colorscheme.

To Reproduce
Steps to reproduce the behavior:

1. Tap the geolocatecontroll
2. See ugly cyan

Expected behavior
I would expect the locate me button to have TUM-relevant styling.

Screenshots

Additional context
Not a high-priority bug

[Frittenteller]

Can you assign me to the issue? I want to try

[Marius1501]

Hello is the issue still relevant? If yes could you assign me to the issue? Thanks 👍🏻

[octycs]

Yes, it's still open. Since there hasn't been any activity since some months, I think it's save to reassign to you.

[Marius1501]

Do I have to change only the color of the button or do you expect something more?

[CommanderStorm]

After clicking on the button, there is also an overlay in the same colour. Both should be included (if possible).
The main point why this is an issue is, that neither me nor @octycs had the time to look at which of the colors looks best in this context.

We have a wide array of colors already in use, but also these new colors TUM just dropped:

(if you have a color, which looks good in this context and is not on our prevous roster, this is fine too 😉)

[Marius1501]

Hello, I have an issue when I want to start gulp I get this error.

What am I doing wrong?

[CommanderStorm]

I have just tested successfully it on my machine.

Could you include more of the errormessage?

FYI: Our Windows compatibility is probably not the best, since we both use some flavor of Linux. Sorry about that.
I am going to set up a Windows environment and try to replicate this.
In the meantime, you could try using WSL.

[CommanderStorm]

I noticed that we are quite unclear at times what our exect dev environemnt is.
Sorry about that. We will improve this.

Okay. I got WSL working with a few hickups:
Follow https://learn.microsoft.com/de-de/windows/wsl/install to get WSL

Inside WSL:

• We want to update our caches:

  sudo apt update && sudo apt upgrade

• get node via following: https://learn.microsoft.com/en-us/windows/dev-environment/javascript/nodejs-on-wsl
• (server only) get rust via following: https://rustup.rs
• Go to the path where you cloned NavigaTUM

  cd /mnt/c/Users/Frank/...
  

• We assume that python3 is called python. Ubuntu does not agree with this assumption. We can fix this via (alias python=python3) or write python3 instead of python in our docs.
• the rest is documented in the respective folders😉

[Marius1501]

Ok thank you very much! The webclient is working fine now, but now I have a problem when I run the server.

I get this error message.

[CommanderStorm]

Thank you for your patience (I was organizing a regatta, so I did not have time last week to look into where our docs are failing us).
I will do a PR improving the setup with the things we learned in this issue in the next few days. I have realized that what I thought about our docs being good is not at all accurate.

There are three options to get the API (all are mostly equivalent)

Using our API

Firstly (for completeness), running the webclient does not require you running your server:

If you want to only run the webclient locally, you can skip the "Data" and "Server" steps above and edit the webclient configuration to use the public API as is described in the webclient documentation.

This refers to https://github.com/TUM-Dev/navigatum/tree/main/webclient#testing

Docker

Also note, that you can use Docker to run our API and Meili (our search provider):

docker network create navigatum-net
docker run -it --rm -p 7700:7700 --name search --network navigatum-net ghcr.io/tum-dev/navigatum-mieli-search:main
docker run -it --rm -p 8080:8080 --network navigatum-net -e MIELI_SEARCH_ADDR=search ghcr.io/tum-dev/navigatum-server:main

For Meili this is even the recomended way 😉

native WSL

Apparently WSL has a few other quirks which we did not notice on our machines, due to those steps being done by our (@octycs and my) distros.

On the server side:
Note: pkg-config openssl libssl-dev is installed because required by OpenSSL

sudo apt install build-essential pkg-config openssl libssl-dev libsqlite3-dev

On the data side:
Currently, developing data requires a newer version of python than WSL-Ubuntu ships with…
I cannot recommend trying this, as this seems sketchy on many levels.
You can download the compiled downloads from nav.tum.sexy/cdn as documented here
I have to do some investigation, if this works better if done natively on Windows.

On another Other note:

• If run into any other issues which we dont document, please let us know.
• FYI: Vue3 Migration #200 will simplify the workflow by a lot, so this dev-workflow is not here to stay, but that PR is massive and not yet fully working (we are missing details, feedback, and the docs so major parts of the app) 😉

[Marius1501]

I am very sorry that I am bothering you again, but I am a bit frustrated. Everything in the webclient documenation is working now. But I am not sure how to use the public API. I am not able to execute the command openapi-format ./openapi.yaml --output ./openapi.yaml. I hope you can help me and I hope that I can start then with coding. 😄 Thank you very much in advance! 👍🏻

[octycs]

I just tried it with the public API and you're right, it doesn't work because of CORS :(

According to the message in Firefox the server needs to send Access-Control-Allow-Credentials: true as well.

[octycs]

Do you have an idea @CommanderStorm how to solve this? We cannot just add the credentials header on the production build, because it conflicts with allow_any_origin. I am thinking about removing the lang cookie from the API.

(There is a different solution, but I am not sure whether we should implement it: The server can just always copy the value of the Host request header to the Allowed-Origin response header)

[CommanderStorm]

Do you have an idea @CommanderStorm how to solve this? We cannot just add the credentials header on the production build, because it conflicts with allow_any_origin. I am thinking about removing the lang cookie from the API.

Yea.. you are probably right: switching to the query params ist probably best.
The amount of pain CORS has caused us is was top high.

(There is a different solution, but I am not sure whether we should implement it: The server can just always copy the value of the Host request header to the Allowed-Origin response header)

This ist one hell of a Hacky solution. Lets Switch to query params, since I dont See a strong reason, why sticking with Cookies would be better. (I still am going to Look into how Clean this would be, but I suspect, that solution 1 is better)

Timeline for this fix is this weekend.

@Marius1501: I am terribly sorry about the Problems you encountered, our current state of documentation ist not acceptible and I really am ashamed of the problems you encountered. I sadly was unable to improve upon These issues in the last weeks, because the start of the Semester ist always really stressfull, because of SET.
If you want, I am going to buy you something at C2/... or you can get some specialty Stickers at the MPI Student council (in the Wall there ist a compartment labeled with "Frank Elsinga")

[Marius1501]

That is very kind! I am really relieved that it is not my fault. 😄 But I want to work on this issue, though. Because it is just a small style change I would test the code in a local project. Then I would change the real code like in my local project. I hope this is fine for you. 👍🏻

[Marius1501]

I changed the user location dot color. I hope this is fine. I have a problem with changing the color of the geolocation-button because I am not able to change the svg-icon. The link below is the part of the Mapbox source code where the geolocation-button ist styled. Do you have an idea how I get access to it? Thank you in advance! 😃

mapbox-gl-js/src/css/mapbox-gl.css (Line 250 to 370).