-
Notifications
You must be signed in to change notification settings - Fork 4
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, PlotRegion with background #117
Conversation
R-Abbasi
commented
Mar 25, 2024
•
edited
edited
- set horizontal and vertical gaps around plot region
- set plot region's background color
- set border for the region plot
- fixed image auto resize bug
- added several code improvements
Yes the background now looks the way it should. |
src/menuscpp/DevicesMenu.cpp
Outdated
void SetDevicesMenu(std::map<Omniscope::Id, std::array<float, 3>> &colorMap, | ||
std::optional<OmniscopeSampler> &sampler, | ||
std::vector<std::shared_ptr<OmniscopeDevice>> &devices) { | ||
void SetDevicesMenu(std::map<Omniscope::Id, std::array<float, 3>>& colorMap, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang format ? Why is there a space between the variable and &
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a (good) habit.
The following constructs are identical with the former potentially making that wrong imagination that the value category of both variables are the same while the latter clarifying the ambiguity making their difference clearer.
T& ri, rj;
T &ri, rj;
As for clang format, I'm not a big fan of it since I've faced problems in its output, such as:
- reordering included files (the order of
#include
d files matters) - some undesirable optimizations it caries out ending up in changes in the code
As well as, vs-code or VS 2022 code format seems pretty cool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's okay if you don't like clang-format. We are currently working on an improved version to also check function names and similar elements, so that the C++ standard can be adhered to. You're welcome to incorporate your thoughts here. However, to maintain code structure, we will continue to use the current clang-format file. This also applies to this pull request. Regarding the "&" operator, please utilize the version that clang-format transforms it into.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main point is not my preferences; it's the unwanted consequences that that format may apply - I've encountered them a couple of times in some of the pr
s already. For example, the code works before push
ing but may not on the CI, after applying that format. It can cause easy/hard to find issues.