Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some docs updates #1179

Merged
merged 9 commits into from
Oct 11, 2024
Merged

Some docs updates #1179

merged 9 commits into from
Oct 11, 2024

Conversation

ovalkonia
Copy link
Contributor

@ovalkonia ovalkonia commented Aug 29, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@ovalkonia ovalkonia marked this pull request as draft August 30, 2024 08:18
@w-lfchen
Copy link
Contributor

w-lfchen commented Aug 30, 2024

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 ovalkonia marked this pull request as ready for review August 30, 2024 14:26
@ovalkonia
Copy link
Contributor Author

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

@ovalkonia ovalkonia changed the title Export magic constants during server initialization Export magic constants during server initialization and some docs updates Aug 30, 2024
Copy link
Contributor

@w-lfchen w-lfchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

docs/src/magic-vars.md Outdated Show resolved Hide resolved
@w-lfchen
Copy link
Contributor

w-lfchen commented Aug 30, 2024

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

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

Celcius -> degree Celsius

@w-lfchen
Copy link
Contributor

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

Copy link
Contributor

@w-lfchen w-lfchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

ovalkonia commented Aug 30, 2024

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
Copy link
Contributor

w-lfchen commented Aug 30, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

ovalkonia commented Aug 30, 2024

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?

@ovalkonia ovalkonia marked this pull request as draft August 30, 2024 17:30
@w-lfchen
Copy link
Contributor

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

Copy link
Contributor

@w-lfchen w-lfchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

"EWW_CONFIG_DIR" => DynVal::from_string(eww_paths.get_config_dir().to_string_lossy().into_owned()),

// @desc EWW_CMD - eww command running in the current configuration, useful in event handlers. I.e.: `:onclick "${EWW_CMD} update foo=bar"`
// @desc EWW_CMD (Magic constant) - eww command running in the current configuration, useful in event handlers. I.e.: `:onclick "${EWW_CMD} update foo=bar"`
"EWW_CMD" => DynVal::from_string(
format!("\"{}\" --config \"{}\"",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah true, i forgot about that, nvm

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use single quotes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same problems as with double quotes

@ovalkonia ovalkonia changed the title Export magic constants during server initialization and some docs updates Some docs updates Sep 6, 2024
@ovalkonia
Copy link
Contributor Author

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

@ovalkonia ovalkonia marked this pull request as ready for review September 6, 2024 19:44
Copy link
Contributor

@w-lfchen w-lfchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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

@elkowar elkowar merged commit 9a7e699 into elkowar:master Oct 11, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants