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

Assorted issues and ideas #21

Open
6 of 11 tasks
ollpu opened this issue Apr 12, 2021 · 1 comment
Open
6 of 11 tasks

Assorted issues and ideas #21

ollpu opened this issue Apr 12, 2021 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@ollpu
Copy link

ollpu commented Apr 12, 2021

These apply to the experiment branch.

  • .with_min .with_max should be .with_min_max or .with_range. (should never need to set them separately) initial value on the same go too?
  • x, y, w, h should be fetched at once when drawing
  • percentage is not % (new layout addresses this though?)
  • errors reading CSS or invalid rules should provide some kind of feedback
  • label (i.e. text) auto height/width would be really nice
  • set_font_color corresponds to color in CSS?
  • explain propagation enum variants with docs. other things too. these are directly visible from rust-analyzer
  • events being "unique" by default..is a little deceptive?
  • idea: debug trace events (set a flag, maybe an identifier, it then prints details on the propagation and which entities it is sent to)
  • CheckItem is missing on_checked and on_unchecked
  • CSS parser does not like having spaces around the child selector, A > B
@geom3trik
Copy link
Owner

  1. This is referring to the spinbox widget right? I think this is a good idea and I personally prefer .with_range. Eventually other widgets like sliders and knobs should conform to the same api.
  2. Also a good idea. I'll create a method in state.data to get the bounding box of a widget in one go, something like .get_bounds perhaps?
  3. I'm not sure what you mean by this. Though I'm guessing it's because percentage values are between 0 and 1.0 (or more) rather than 0 and 100. Which I will admit is not really intuitive and should be changed.
  4. Yes, I agree, there definitely needs to be some errors for css invalid rules. In fact the whole css parsing part needs a rework really.
  5. This is definitely a feature I want to add but I'm undecided how best to do it. Currently all text size info comes from femtovg but I didn't want incorporate femtovg into the layout algorithm for auto sizing, so I need to look into the best way to do this. Also not clear is at what stage this should be done because at some point I plan to add localization which will alter the text in a label and thus alter the auto width/height.
  6. Yes it does. It should probably be renamed to .set_color or perhaps the 'css' should be changed to font-color. We should also think of a different name than css because some of the properties aren't really css. But then having the files as .css does help for editor autocomplete and extensions like the ones that show you the specificity of a rule.
  7. Docs is definitely something that needs work throughout the whole lib and should be a priority before the next release. Certainly the events and propagation types should be labelled.
  8. How so? Do you think events should be non-unique by default?
  9. This is a very good idea. I will look into adding this.

@geom3trik geom3trik self-assigned this Apr 12, 2021
@geom3trik geom3trik added the enhancement New feature or request label Apr 12, 2021
geom3trik added a commit that referenced this issue Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants