Some docs updates

[ovalkonia]

Description

Just some updates smaaall update for docs.

Usage

N/A

Showcase

N/A

Additional Notes

N/A

Checklist

Please make sure you can check all the boxes that apply to this PR.

• All widgets I've added are correctly documented.
• I added my changes to CHANGELOG.md, if appropriate.
• The documentation in the docs/content/main directory has been adjusted to reflect my changes.
• I used cargo fmt to automatically format all code before committing

[w-lfchen]

the docs for widgets are automatically generated, but i don't know how magic vars are handled from a glance, it seems to be similar, look at the @desc and @prop comments

your checkboxes are missing spaces in order to work properly: - [ ] is an unchecked one, the space between the brackets is required ^^

some questions i'd like to raise:

• does this export every variable or only the used ones?
• if it exports every variable, is there a noticeable time increase when starting eww? that could be annoying

[ovalkonia]

I don't think you can check whether a script uses a certain environmental variable. So it only exports the magic constants since they don't change and it only needs to be done once - when the server gets initialized, just like the GDK_BACKEND variable.

Therefore, no slowdowns should be present. Right now there are only three magic constants: EWW_CONFIG, EWW_CMD and EWW_EXECUTABLE They are defined with the define_magic_constants macro. If any more get added in the future, they will be automatically exported as well.

Thank you for the info about the docs. I will mark the pr as draft until I update them

[w-lfchen]

i mixed up magic constants and variables, my bad.

this seems reasonable to me, with little performance overhead then since there's just some strings being thrown around and transformed, compared to the entire application this probably won't make a difference whatsoever.

it might be worthwhile to look into updating the docs to mention that the last 3 magic vars are in fact constant

[ovalkonia]

Well, I tried my best with the docs (I don't have enough willpower to figure out gen-docs.ts)

[w-lfchen]

minor wording suggestion, you should be able to simply apply this
apart from that i don't see any issues with this, but i have not tested it.

[w-lfchen]

one more typo that i just noticed (would be nice if you could just fix that one as well):

eww/crates/eww/src/config/inbuilt.rs

Line 33 in b3dbfad

// @desc EWW_TEMPS - Heat of the components in Celcius

Celcius -> degree Celsius

[w-lfchen]

thank you <3
i'll just quickly test this, one sec

[w-lfchen]

while this is a simple export, we should make it useful. EWW_CMD currently does not work when invoked as one would expect.

i suspect that the cause for this is the two paths in the command being quoted.

the other variables work and can be used as expected.

also, adding this requires eww to remain single-threaded according to the set_env docs. i don't know whether this could cause issues.

[ovalkonia]

Interesting, EWW_CMD works fine for me, as shown on the screenshot provided in the showcase. Can you provide some more info so that I can reproduce the issue?

set_env call shouldn't be an issue. It is already used to set the GDK_BACKEND environmental variable just a couple of lines below, so I guess that's ok

[w-lfchen]

i phrased that a bit confusingly. echo works fine, but consider the following:
(defpoll test :interval "1s" "$EWW_CMD update foo=bar")
one would expect this to work (there could be a more complicated script here obviously). however, this is not the case.
since i think this is a reasonable assumption to make, it should work

[ovalkonia]

Got it, that's kinda weird. Without the quotes it indeed works. Although, when I paste the value with quotes manually, it still works. Don't really understand how it works now, but I will look into it

[ovalkonia]

So the problem here is that bash interprets quotes literally, as if I was trying to do '"eww"' or something like that, which fails of course.

Two other variables are not quoted since you can quote them and escape possible whitespaces yourself. You can't do that with EWW_CMD, so it's quoted for you. At least, that's what I think.

What I could do is change the format of EWW_CMD to escape whitespaces with \ instead of quotes (I can't, doesn't work). Although, it isn't all that pretty. Is there a better approach?

[w-lfchen]

i love bash so much /s
i'll look into an idea i just had

[w-lfchen]

from my admittedly limited testing, this works.
are there issues with this approach?

[w-lfchen]

Suggested change

	format!("\"{}\" --config \"{}\"",
	format!("{} --config {}",

[ovalkonia]

Yeah, that's what I thought, BUT. Try cloning eww into a folder named eww with spaces for example. It doesn't work for me. The path is just cut from the first space to the end. These are kind of things that make want not to deal with bash ever again(

[w-lfchen]

yeah true, i forgot about that, nvm

[hypernova7]

Why not use single quotes

[ovalkonia]

Same problems as with double quotes

[ovalkonia]

Since it seems to be a dead end with the environmental variables, thought I would revert those changes and leave just the docs update.

[w-lfchen]

i think exporting the two working variables shouldn't do any harm, so we could still export those

but with the current state, i guess this can just be merged

[ovalkonia]

Yeah, it just kinda doesn't feel right. I really doubt that someone uses EWW_EXECUTABLE or EWW_CONFIG. EWW_CMD makes the most sense, yet it doesn't work. Sure, you can construct EWW_CMD using the other two, but meh. So maybe it would be better to come back to this later