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

[Enhancement] QP Getters #21171

Merged
merged 4 commits into from
Sep 25, 2023
Merged

[Enhancement] QP Getters #21171

merged 4 commits into from
Sep 25, 2023

Conversation

elpekenin
Copy link
Contributor

@elpekenin elpekenin commented Jun 8, 2023

Description

Currently you have to always query every piece of data, even if you only wanted one of them.

Soi, I find myself writing a little bit of boilerplate even if i just wanted to check the display's width to check if a text can fit on it.

uint16_t           width;
uint16_t           height;
painter_rotation_t rotation;
uint16_t           offset_x;
uint16_t           offset_y;
qp_get_geometry(device, &width, &height, &rotation, &offset_x,  &offset_y);

Note: While looking at the code i saw that you can pass NULL pointers to the function, which was not documented, i added it.


So, with the current implementation we can actually do

uint16_t width;
qp_get_geometry(device, &width, NULL, NULL, NULL, NULL);

.... but i find this code much less friendly, specially for beginners, thus the new API allows to simply

uint16_t width = qp_get_width(device);

While presserving the old API as a convenience wrapper to all of these getters

PS1: I know this adds some duplication and may make code harder to maintain (longer codebase), not ideal

PS2: Perhaps it could be done the other way around, with new getters calling the "everything" one and returning the value we want, however this would lead to needing many changes if a new parameter is added that can be queried (all the get_* would need an extra NULL to the call). And i feel like breaking the logic into smaller function is a better idea anyway

Types of Changes

  • Core
  • Bugfix
  • New feature
  • Enhancement/optimization
  • Keyboard (addition or update)
  • Keymap/layout/userspace (addition or update)
  • Documentation

Issues Fixed or Closed by This PR

Checklist

  • My code follows the code style of this project: C, Python
  • I have read the PR Checklist document and have made the appropriate changes.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have tested the changes and verified that they work and don't break anything (as well as I can manage).

@drashna drashna requested review from tzarc and a team June 11, 2023 07:11
@drashna drashna requested a review from a team July 3, 2023 19:10
@tzarc tzarc merged commit a360900 into qmk:develop Sep 25, 2023
@elpekenin elpekenin deleted the feature/qp_getters branch September 25, 2023 13:24
mechlovin pushed a commit to mechlovin/qmk_firmware that referenced this pull request Oct 25, 2023
christrotter pushed a commit to christrotter/qmk_firmware that referenced this pull request Nov 28, 2023
zgagnon pushed a commit to zgagnon/qmk_firmware_waterfowl that referenced this pull request Dec 15, 2023
future-figs pushed a commit to future-figs/qmk_firmware that referenced this pull request Dec 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants