init lvgl code
1475
LVGL.Simulator/lvgl/docs/CHANGELOG.md
Normal file
46
LVGL.Simulator/lvgl/docs/CODE_OF_CONDUCT.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team using the [contact form](https://lvgl.io/about). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
|
||||
|
||||
[homepage]: http://contributor-covenant.org
|
||||
[version]: http://contributor-covenant.org/version/1/4/
|
||||
124
LVGL.Simulator/lvgl/docs/CODING_STYLE.md
Normal file
@@ -0,0 +1,124 @@
|
||||
# Coding style
|
||||
|
||||
## File format
|
||||
Use [misc/lv_templ.c](https://github.com/lvgl/lvgl/blob/master/src/misc/lv_templ.c) and [misc/lv_templ.h](https://github.com/lvgl/lvgl/blob/master/src/misc/lv_templ.h)
|
||||
|
||||
## Naming conventions
|
||||
* Words are separated by '_'
|
||||
* In variable and function names use only lower case letters (e.g. *height_tmp*)
|
||||
* In enums and defines use only upper case letters (e.g. *e.g. MAX_LINE_NUM*)
|
||||
* Global names (API):
|
||||
* start with *lv*
|
||||
* followed by module name: *btn*, *label*, *style* etc.
|
||||
* followed by the action (for functions): *set*, *get*, *refr* etc.
|
||||
* closed with the subject: *name*, *size*, *state* etc.
|
||||
* Typedefs
|
||||
* prefer `typedef struct` and `typedef enum` instead of `struct name` and `enum name`
|
||||
* always end `typedef struct` and `typedef enum` type names with `_t`
|
||||
* Abbreviations:
|
||||
* Only words longer or equal than 6 characters can be abbreviated.
|
||||
* Abbreviate only if it makes the word at least half as long
|
||||
* Use only very straightforward and well-known abbreviations (e.g. pos: position, def: default, btn: button)
|
||||
|
||||
## Coding guide
|
||||
* Functions:
|
||||
* Try to write function shorter than is 50 lines
|
||||
* Always shorter than 200 lines (except very straightforwards)
|
||||
* Variables:
|
||||
* One line, one declaration (BAD: char x, y;)
|
||||
* Use `<stdint.h>` (*uint8_t*, *int32_t* etc)
|
||||
* Declare variables where needed (not all at function start)
|
||||
* Use the smallest required scope
|
||||
* Variables in a file (outside functions) are always *static*
|
||||
* Do not use global variables (use functions to set/get static variables)
|
||||
|
||||
## Comments
|
||||
Before every function have a comment like this:
|
||||
|
||||
```c
|
||||
/**
|
||||
* Return with the screen of an object
|
||||
* @param obj pointer to an object
|
||||
* @return pointer to a screen
|
||||
*/
|
||||
lv_obj_t * lv_obj_get_scr(lv_obj_t * obj);
|
||||
```
|
||||
|
||||
Always use `/*Something*/` format and NOT `//Something`
|
||||
|
||||
Write readable code to avoid descriptive comments like:
|
||||
`x++; /*Add 1 to x*/`.
|
||||
The code should show clearly what you are doing.
|
||||
|
||||
You should write **why** have you done this:
|
||||
`x++; /*Because of closing '\0' of the string*/`
|
||||
|
||||
Short "code summaries" of a few lines are accepted. E.g. `/*Calculate the new coordinates*/`
|
||||
|
||||
In comments use \` \` when referring to a variable. E.g. ``/*Update the value of `x_act`*/``
|
||||
|
||||
### Formatting
|
||||
Here is example to show bracket placing and using of white spaces:
|
||||
```c
|
||||
/**
|
||||
* Set a new text for a label. Memory will be allocated to store the text by the label.
|
||||
* @param label pointer to a label object
|
||||
* @param text '\0' terminated character string. NULL to refresh with the current text.
|
||||
*/
|
||||
void lv_label_set_text(lv_obj_t * label, const char * text)
|
||||
{ /*Main brackets of functions in new line*/
|
||||
|
||||
if(label == NULL) return; /*No bracket only if the command is inline with the if statement*/
|
||||
|
||||
lv_obj_inv(label);
|
||||
|
||||
lv_label_ext_t * ext = lv_obj_get_ext(label);
|
||||
|
||||
/*Comment before a section*/
|
||||
if(text == ext->txt || text == NULL) { /*Bracket of statements start inline*/
|
||||
lv_label_refr_text(label);
|
||||
return;
|
||||
}
|
||||
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Use 4 spaces indentation instead of tab.
|
||||
|
||||
You can use **astyle** to format the code. Run `code-formatter.sh` from the `scrips` folder.
|
||||
|
||||
#### pre-commit
|
||||
|
||||
[pre-commit](https://pre-commit.com/) is a multi-language package manager for pre-commit hooks.
|
||||
See the [instalation guide](https://pre-commit.com/#installation) to get pre-commit python package
|
||||
installed into your development machine.
|
||||
|
||||
Once you have `pre-commit` installed you will need to [set up the git hook scripts](https://pre-commit.com/#3-install-the-git-hook-scripts) with:
|
||||
```console
|
||||
pre-commit install
|
||||
```
|
||||
|
||||
now `pre-commit` will run automatically on `git commit`!
|
||||
|
||||
##### Hooks
|
||||
|
||||
The `format-source` local hook (see `.pre-commit-config.yaml`) runs **astyle** on all the staged source and header
|
||||
files (that are not excluded, see `exclude` key of the hook configuration) before entering the commit message,
|
||||
if any file gets formatted by **astyle** you will need to add the change to the staging area and run `git commit` again.
|
||||
|
||||
The `trailing-whitespace` hook fixes trailing whitespaces on all of the files.
|
||||
|
||||
##### Skipping hooks
|
||||
|
||||
If you want to skip any particular hook you can do so with:
|
||||
```console
|
||||
SKIP=name-of-the-hook git commit
|
||||
```
|
||||
|
||||
##### Testing hooks
|
||||
|
||||
It's no necessary to do a commit to test the hooks, you can test hooks by adding the files into the staging area and run:
|
||||
```console
|
||||
pre-commit run name-of-the-hook
|
||||
```
|
||||
300
LVGL.Simulator/lvgl/docs/CONTRIBUTING.md
Normal file
@@ -0,0 +1,300 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/CONTRIBUTING.md
|
||||
```
|
||||
|
||||
# Contributing
|
||||
|
||||
## Introduction
|
||||
|
||||
Join LVGL's community and leave your footprint in the library!
|
||||
|
||||
There are a lot of ways to contribute to LVGL even if you are new to the library or even new to programming.
|
||||
|
||||
It might be scary to make the first step but you have nothing to be afraid of.
|
||||
A friendly and helpful community is waiting for you. Get to know like-minded people and make something great together.
|
||||
|
||||
So let's find which contribution option fits you the best and help you join the development of LVGL!
|
||||
|
||||
Before getting started here are some guidelines to make contribution smoother:
|
||||
- Be kind and friendly.
|
||||
- Be sure to read the relevant part of the documentation before posting a question.
|
||||
- Ask questions in the [Forum](https://forum.lvgl.io/) and use [GitHub](https://github.com/lvgl/) for development-related discussions.
|
||||
- Always fill out the post or issue templates in the Forum or GitHub (or at least provide equivalent information). It makes understanding your contribution or issue easier and you will get a useful response faster.
|
||||
- If possible send an absolute minimal but buildable code example in order to reproduce the issue. Be sure it contains all the required variable declarations, constants, and assets (images, fonts).
|
||||
- Use [Markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) to format your posts. You can learn it in 10 minutes.
|
||||
- Speak about one thing in one issue or topic. It makes your post easier to find later for someone with the same question.
|
||||
- Give feedback and close the issue or mark the topic as solved if your question is answered.
|
||||
- For non-trivial fixes and features, it's better to open an issue first to discuss the details instead of sending a pull request directly.
|
||||
- Please read and follow the <a href="https://github.com/lvgl/lvgl/blob/master/docs/CODING_STYLE.md">Coding style</a> guide.
|
||||
|
||||
## Pull request
|
||||
|
||||
Merging new code into the lvgl, documentation, blog, examples, and other repositories happen via *Pull requests* (PR for short).
|
||||
A PR is a notification like "Hey, I made some updates to your project. Here are the changes, you can add them if you want."
|
||||
To do this you need a copy (called fork) of the original project under your account, make some changes there, and notify the original repository about your updates.
|
||||
You can see what it looks like on GitHub for LVGL here: [https://github.com/lvgl/lvgl/pulls](https://github.com/lvgl/lvgl/pulls).
|
||||
|
||||
To add your changes you can edit files online on GitHub and send a new Pull request from there (recommended for small changes) or
|
||||
add the updates in your favorite editor/IDE and use git to publish the changes (recommended for more complex updates).
|
||||
|
||||
### From GitHub
|
||||
1. Navigate to the file you want to edit.
|
||||
2. Click the Edit button in the top right-hand corner.
|
||||
3. Add your changes to the file.
|
||||
4. Add a commit message on the bottom of the page.
|
||||
5. Click the *Propose changes* button.
|
||||
|
||||
### From command line
|
||||
|
||||
The instructions describe the main `lvgl` repository but it works the same way for the other repositories.
|
||||
1. Fork the [lvgl repository](https://github.com/lvgl/lvgl). To do this click the "Fork" button in the top right corner.
|
||||
It will "copy" the `lvgl` repository to your GitHub account (`https://github.com/<YOUR_NAME>?tab=repositories`)
|
||||
2. Clone your forked repository.
|
||||
3. Add your changes. You can create a *feature branch* from *master* for the updates: `git checkout -b the-new-feature`
|
||||
4. Commit and push your changes to the forked `lvgl` repository.
|
||||
5. Create a PR on GitHub from the page of your `lvgl` repository (`https://github.com/<YOUR_NAME>/lvgl`) by clicking the *"New pull request"* button. Don't forget to select the branch where you added your changes.
|
||||
7. Set the base branch. It means where you want to merge your update. In the `lvgl` repo both the fixes and new features go to `master` branch.
|
||||
8. Describe what is in the update. An example code is welcome if applicable.
|
||||
9. If you need to make more changes, just update your forked `lvgl` repo with new commits. They will automatically appear in the PR.
|
||||
|
||||
### Commit message format
|
||||
The commit messages format is inspired by [Angular Commit Format](https://gist.github.com/brianclements/841ea7bffdb01346392c).
|
||||
|
||||
The following structure should be used:
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
```
|
||||
|
||||
Possible `<type>`s:
|
||||
- `fix` bugfix in the source code.
|
||||
- `feat` new feature
|
||||
- `arch` architectural changes
|
||||
- `perf` changes that affect the performance
|
||||
- `example` anything related to examples (even fixes and new examples)
|
||||
- `docs` anything related to the documentation (even fixes, formatting, and new pages)
|
||||
- `test` anything related to tests (new and updated tests or CI actions)
|
||||
- `chore` any minor formatting or style changes that would make the changelog noisy
|
||||
|
||||
`<scope>` is the module, file, or sub-system that is affected by the commit. It's usually one word and can be chosen freely.
|
||||
For example `img`, `layout`, `txt`, `anim`. The scope can be omitted.
|
||||
|
||||
`<subject>` contains a short description of the change:
|
||||
- use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
- don't capitalize the first letter
|
||||
- no dot (.) at the end
|
||||
- max 90 characters
|
||||
|
||||
`<body>` optional and can be used to describe the details of this change.
|
||||
|
||||
`<footer>` shall contain
|
||||
- the words "BREAKING CHANGE" if the changes break the API
|
||||
- reference to the GitHub issue or Pull Request if applicable.
|
||||
|
||||
Some examples:
|
||||
```
|
||||
fix(img): update size if a new source is set
|
||||
```
|
||||
|
||||
```
|
||||
fix(bar): fix memory leak
|
||||
|
||||
The animations weren't deleted in the destructor.
|
||||
|
||||
Fixes: #1234
|
||||
```
|
||||
|
||||
```
|
||||
feat: add span widget
|
||||
|
||||
The span widget allows mixing different font sizes, colors and styles.
|
||||
It's similar to HTML <span>
|
||||
```
|
||||
|
||||
```
|
||||
docs(porting): fix typo
|
||||
```
|
||||
|
||||
## Developer Certification of Origin (DCO)
|
||||
|
||||
### Overview
|
||||
|
||||
To ensure all licensing criteria are met for every repository of the LVGL project, we apply a process called DCO (Developer's Certificate of Origin).
|
||||
|
||||
The text of DCO can be read here: [https://developercertificate.org/](https://developercertificate.org/).
|
||||
|
||||
By contributing to any repositories of the LVGL project you agree that your contribution complies with the DCO.
|
||||
|
||||
If your contribution fulfills the requirements of the DCO no further action is needed. If you are unsure feel free to ask us in a comment.
|
||||
|
||||
### Accepted licenses and copyright notices
|
||||
|
||||
To make the DCO easier to digest, here are some practical guides about specific cases:
|
||||
|
||||
#### Your own work
|
||||
|
||||
The simplest case is when the contribution is solely your own work.
|
||||
In this case you can just send a Pull Request without worrying about any licensing issues.
|
||||
|
||||
#### Use code from online source
|
||||
|
||||
If the code you would like to add is based on an article, post or comment on a website (e.g. StackOverflow) the license and/or rules of that site should be followed.
|
||||
|
||||
For example in case of StackOverflow a notice like this can be used:
|
||||
```
|
||||
/* The original version of this code-snippet was published on StackOverflow.
|
||||
* Post: http://stackoverflow.com/questions/12345
|
||||
* Author: http://stackoverflow.com/users/12345/username
|
||||
* The following parts of the snippet were changed:
|
||||
* - Check this or that
|
||||
* - Optimize performance here and there
|
||||
*/
|
||||
... code snippet here ...
|
||||
```
|
||||
|
||||
#### Use MIT licensed code
|
||||
As LVGL is MIT licensed, other MIT licensed code can be integrated without issues.
|
||||
The MIT license requires a copyright notice be added to the derived work. Any derivative work based on MIT licensed code must copy the original work's license file or text.
|
||||
|
||||
#### Use GPL licensed code
|
||||
The GPL license is not compatible with the MIT license. Therefore, LVGL can not accept GPL licensed code.
|
||||
|
||||
## Ways to contribute
|
||||
|
||||
Even if you're just getting started with LVGL there are plenty of ways to get your feet wet.
|
||||
Most of these options don't even require knowing a single line of LVGL code.
|
||||
|
||||
Below we have collected some opportunities about the ways you can contribute to LVGL.
|
||||
|
||||
### Give LVGL a Star
|
||||
|
||||
Show that you like LVGL by giving it star on GitHub!
|
||||
<!-- Place this tag in your head or just before your close body tag. -->
|
||||
<script async defer src="https://buttons.github.io/buttons.js"></script>
|
||||
<!-- Place this tag where you want the button to render. -->
|
||||
<a class="github-button" href="https://github.com/lvgl/lvgl" data-icon="octicon-star" data-size="large" data-show-count="true" aria-label="Star lvgl/lvgl on GitHub">Star</a>
|
||||
|
||||
This simple click makes LVGL more visible on GitHub and makes it more attractive to other people.
|
||||
So with this, you already helped a lot!
|
||||
|
||||
### Tell what you have achieved
|
||||
|
||||
Have you already started using LVGL in a [Simulator](/get-started/platforms/pc-simulator), a development board, or on your custom hardware?
|
||||
Was it easy or were there some obstacles? Are you happy with the result?
|
||||
Showing your project to others is a win-win situation because it increases your and LVGL's reputation at the same time.
|
||||
|
||||
You can post about your project on Twitter, Facebook, LinkedIn, create a YouTube video, and so on.
|
||||
Only one thing: On social media don't forget to add a link to `https://lvgl.io` or `https://github.com/lvgl` and use the hashtag `#lvgl`. Thank you! :)
|
||||
|
||||
You can also open a new topic in the [My projects](https://forum.lvgl.io/c/my-projects/10) category of the Forum.
|
||||
|
||||
The [LVGL Blog](https://blog.lvgl.io) welcomes posts from anyone.
|
||||
It's a good place to talk about a project you created with LVGL, write a tutorial, or share some nice tricks.
|
||||
The latest blog posts are shown on the [homepage of LVGL](https://lvgl.io) to make your work more visible.
|
||||
|
||||
The blog is hosted on GitHub. If you add a post GitHub automatically turns it into a website.
|
||||
See the [README](https://github.com/lvgl/blog) of the blog repo to see how to add your post.
|
||||
|
||||
Any of these help to spread the word and familiarize new developers with LVGL.
|
||||
|
||||
If you don't want to speak about your project publicly, feel free to use [Contact form](https://lvgl.io/#contact) on lvgl.io to private message to us.
|
||||
|
||||
### Write examples
|
||||
As you learn LVGL you will probably play with the features of widgets. Why not publish your experiments?
|
||||
|
||||
Each widgets' documentation contains examples. For instance, here are the examples of the [Drop-down list](/widgets/core/dropdown#examples) widget.
|
||||
The examples are directly loaded from the [lvgl/examples](https://github.com/lvgl/lvgl/tree/master/examples) folder.
|
||||
|
||||
So all you need to do is send a [Pull request](#pull-request) to the [lvgl](https://github.com/lvgl/lvgl) repository and follow some conventions:
|
||||
- Name the examples like `lv_example_<widget_name>_<index>`.
|
||||
- Make the example as short and simple as possible.
|
||||
- Add comments to explain what the example does.
|
||||
- Use 320x240 resolution.
|
||||
- Update `index.rst` in the example's folder with your new example. To see how other examples are added, look in the [lvgl/examples/widgets](https://github.com/lvgl/lvgl/tree/master/examples/widgets) folder.
|
||||
|
||||
### Improve the docs
|
||||
|
||||
As you read the documentation you might see some typos or unclear sentences. All the documentation is located in the [lvgl/docs](https://github.com/lvgl/lvgl/tree/master/docs) folder.
|
||||
For typos and straightforward fixes, you can simply edit the file on GitHub.
|
||||
|
||||
Note that the documentation is also formatted in [Markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
|
||||
|
||||
### Report bugs
|
||||
As you use LVGL you might find bugs. Before reporting them be sure to check the relevant parts of the documentation.
|
||||
|
||||
If it really seems like a bug feel free to open an [issue on GitHub](https://github.com/lvgl/lvgl/issues).
|
||||
|
||||
When filing the issue be sure to fill out the template. It helps find the root of the problem while avoiding extensive questions and exchanges with other developers.
|
||||
|
||||
### Send fixes
|
||||
The beauty of open-source software is you can easily dig in to it to understand how it works. You can also fix or adjust it as you wish.
|
||||
|
||||
If you found and fixed a bug don't hesitate to send a [Pull request](#pull-request) with the fix.
|
||||
|
||||
In your Pull request please also add a line to [`CHANGELOG.md`](https://github.com/lvgl/lvgl/blob/master/CHANGELOG.md).
|
||||
|
||||
### Join the conversations in the Forum
|
||||
It feels great to know you are not alone if something is not working. It's even better to help others when they struggle with something.
|
||||
|
||||
While you were learning LVGL you might have had questions and used the Forum to get answers. As a result, you probably have more knowledge about how LVGL works.
|
||||
|
||||
One of the best ways to give back is to use the Forum and answer the questions of newcomers - like you were once.
|
||||
|
||||
Just read the titles and if you are familiar with the topic don't hesitate to share your thoughts and suggestions.
|
||||
|
||||
Participating in the discussions is one of the best ways to become part of the project and get to know like-minded people!
|
||||
|
||||
### Add features
|
||||
If you have created a cool widget, or added useful feature to LVGL feel free to open a new PR for it.
|
||||
We collect the optional features (a.k.a. plugins) in [lvgl/src/extra](https://github.com/lvgl/lvgl/tree/master/src/extra) folder so if you are interested in adding a new features please use this folder.
|
||||
The [README](https://github.com/lvgl/lvgl/blob/master/src/extra/README.md) file describes the basics rules of contribution and also lists some ideas.
|
||||
|
||||
For further ideas take a look at the [Roadmap](/ROADMAP) page. If you are interested in any of them feel free to share your opinion and/or participate in the implementation.
|
||||
|
||||
Other features which are (still) not on the road map are listed in the [Feature request](https://forum.lvgl.io/c/feature-request/9) category of the Forum.
|
||||
|
||||
When adding a new features the followings also needs to be updated:
|
||||
- Update [lv_conf_template.h](https://github.com/lvgl/lvgl/blob/master/lv_conf_template.h)
|
||||
- Add description in the [docs](https://github.com/lvgl/lvgl/tree/master/docs)
|
||||
- Add [examples](https://github.com/lvgl/lvgl/tree/master/examples)
|
||||
- Update the [changelog](https://github.com/lvgl/lvgl/tree/master/docs/CHANGELOG.md)
|
||||
|
||||
### Become a maintainer
|
||||
|
||||
If you want to become part of the core development team, you can become a maintainer of a repository.
|
||||
|
||||
By becoming a maintainer:
|
||||
- You get write access to that repo:
|
||||
- Add code directly without sending a pull request
|
||||
- Accept pull requests
|
||||
- Close/reopen/edit issues
|
||||
- Your input has higher impact when we are making decisions
|
||||
|
||||
You can become a maintainer by invitation, however the following conditions need to met
|
||||
1. Have > 50 replies in the Forum. You can look at your stats [here](https://forum.lvgl.io/u?period=all)
|
||||
2. Send > 5 non-trivial pull requests to the repo where you would like to be a maintainer
|
||||
|
||||
|
||||
If you are interested, just send a message (e.g. from the Forum) to the current maintainers of the repository. They will check if the prerequisites are met.
|
||||
Note that meeting the prerequisites is not a guarantee of acceptance, i.e. if the conditions are met you won't automatically become a maintainer.
|
||||
It's up to the current maintainers to make the decision.
|
||||
|
||||
### Move your project repository under LVGL organization
|
||||
Besides the core `lvgl` repository there are other repos for ports to development boards, IDEs or other environment.
|
||||
If you ported LVGL to a new platform we can host it under the LVGL organization among the other repos.
|
||||
|
||||
This way your project will become part of the whole LVGL project and can get more visibility.
|
||||
If you are interested in this opportunity just open an [issue in lvgl repo](https://github.com/lvgl/lvgl/issues) and tell what you have!
|
||||
|
||||
If we agree that your port fit well into the LVGL organization, we will open a repository for your project where you will have admin rights.
|
||||
|
||||
To make this concept sustainable there a few rules to follow:
|
||||
- You need to add a README to your repo.
|
||||
- We expect to maintain the repo to some extent:
|
||||
- Follow at least the major versions of LVGL
|
||||
- Respond to the issues (in a reasonable time)
|
||||
- If there is no activity in a repo for 1 year it will be archived
|
||||
27
LVGL.Simulator/lvgl/docs/ROADMAP.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Roadmap
|
||||
|
||||
This is a summary for planned new features and a collection of ideas.
|
||||
This list indicates only the current intention and it can be changed.
|
||||
|
||||
## v8.2
|
||||
See [#2790](https://github.com/lvgl/lvgl/issues/2790)
|
||||
|
||||
## Ideas
|
||||
- Reconsider color format management for run time color format setting, and custom color format usage. (Also [RGB888](https://github.com/lvgl/lvgl/issues/1722))
|
||||
- Make gradients more versatile
|
||||
- Image transformations matrix
|
||||
- Switch to RGBA colors in styles
|
||||
- Consider direct binary font format support
|
||||
- Simplify `group`s. Discussion is [here](https://forum.lvgl.io/t/lv-group-tabindex/2927/3).
|
||||
- lv_mem_alloc_aligned(size, align)
|
||||
- Text node. See [#1701](https://github.com/lvgl/lvgl/issues/1701#issuecomment-699479408)
|
||||
- CPP binding. See [Forum](https://forum.lvgl.io/t/is-it-possible-to-officially-support-optional-cpp-api/2736)
|
||||
- Optimize font decompression
|
||||
- Need static analyze (via coverity.io or something else)
|
||||
- Support dot_begin and dot_middle long modes for labels
|
||||
- Add new label alignment modes. [#1656](https://github.com/lvgl/lvgl/issues/1656)
|
||||
- Support larger images: [#1892](https://github.com/lvgl/lvgl/issues/1892)
|
||||
- Curved text on path
|
||||
- Variable binding improvements like Redux?
|
||||
- Functional programming support, pure view? See [here](https://www.freecodecamp.org/news/the-revolution-of-pure-views-aed339db7da4/)
|
||||
- Circle layout. See [#2871](https://github.com/lvgl/lvgl/issues/2871)
|
||||
98
LVGL.Simulator/lvgl/docs/_ext/lv_example.py
Normal file
@@ -0,0 +1,98 @@
|
||||
import os
|
||||
|
||||
from docutils import nodes
|
||||
from docutils.parsers.rst import Directive, directives
|
||||
from docutils.parsers.rst.directives.images import Image
|
||||
from sphinx.directives.code import LiteralInclude
|
||||
|
||||
|
||||
def excluded_list(argument):
|
||||
return argument.split(',')
|
||||
|
||||
|
||||
|
||||
|
||||
class LvExample(Directive):
|
||||
required_arguments = 1
|
||||
option_spec = {
|
||||
'excluded_languages': excluded_list,
|
||||
'language': directives.unchanged,
|
||||
'description': directives.unchanged
|
||||
}
|
||||
def get_example_code_path(self, example_path, language):
|
||||
return os.path.abspath("../examples/" + example_path + "." + language)
|
||||
def human_language_name(self, language):
|
||||
if language == 'py':
|
||||
return 'MicroPython'
|
||||
elif language == 'c':
|
||||
return 'C'
|
||||
else:
|
||||
return language
|
||||
def github_path(self, example_path, language):
|
||||
env = self.state.document.settings.env
|
||||
return f"https://github.com/lvgl/lvgl/blob/{env.config.repo_commit_hash}/examples/{example_path}.{language}"
|
||||
def embed_code(self, example_file, example_path, language, buttons={}):
|
||||
toggle = nodes.container('', literal_block=False, classes=['toggle'])
|
||||
header = nodes.container('', literal_block=False, classes=['header'])
|
||||
toggle.append(header)
|
||||
try:
|
||||
with open(example_file) as f:
|
||||
contents = f.read()
|
||||
except FileNotFoundError:
|
||||
contents = 'Error encountered while trying to open ' + example_file
|
||||
literal_list = nodes.literal_block(contents, contents)
|
||||
literal_list['language'] = language
|
||||
toggle.append(literal_list)
|
||||
paragraph_node = nodes.raw(text=f"<p>{self.human_language_name(language)} code </p>", format='html')
|
||||
for text, url in buttons.items():
|
||||
paragraph_node.append(nodes.raw(text=f"<a class='lv-example-link-button' onclick=\"event.stopPropagation();\" href='{url}'>{text}</a>", format='html'))
|
||||
header.append(paragraph_node)
|
||||
return toggle
|
||||
def run(self):
|
||||
example_path = self.arguments[0]
|
||||
example_name = os.path.split(example_path)[1]
|
||||
excluded_languages = self.options.get('excluded_languages', [])
|
||||
node_list = []
|
||||
|
||||
env = self.state.document.settings.env
|
||||
|
||||
iframe_html = ""
|
||||
|
||||
c_path = self.get_example_code_path(example_path, 'c')
|
||||
py_path = self.get_example_code_path(example_path, 'py')
|
||||
|
||||
c_code = self.embed_code(c_path, example_path, 'c', buttons={
|
||||
'<i class="fa fa-github"></i> GitHub': self.github_path(example_path, 'c')
|
||||
})
|
||||
py_code = self.embed_code(py_path, example_path, 'py', buttons={
|
||||
'<i class="fa fa-github"></i> GitHub': self.github_path(example_path, 'py'),
|
||||
'<i class="fa fa-play"></i> Simulator': f"https://sim.lvgl.io/v{env.config.version}/micropython/ports/javascript/index.html?script_startup=https://raw.githubusercontent.com/lvgl/lvgl/{env.config.repo_commit_hash}/examples/header.py&script=https://raw.githubusercontent.com/lvgl/lvgl/{env.config.repo_commit_hash}/examples/{example_path}.py"
|
||||
})
|
||||
|
||||
if not 'c' in excluded_languages:
|
||||
if env.app.tags.has('html'):
|
||||
iframe_html = f"<div class='lv-example' data-real-src='/{env.config.version}/_static/built_lv_examples?example={example_name}&w=320&h=240'></div>"
|
||||
|
||||
description_html = f"<div class='lv-example-description'>{self.options.get('description', '')}</div>"
|
||||
layout_node = nodes.raw(text=f"<div class='lv-example-container'>{iframe_html}{description_html}</div>", format='html')
|
||||
|
||||
node_list.append(layout_node)
|
||||
if not 'c' in excluded_languages:
|
||||
node_list.append(c_code)
|
||||
if not 'py' in excluded_languages:
|
||||
node_list.append(py_code)
|
||||
|
||||
trailing_node = nodes.raw(text=f"<hr/>", format='html')
|
||||
node_list.append(trailing_node)
|
||||
|
||||
return node_list
|
||||
|
||||
def setup(app):
|
||||
app.add_directive("lv_example", LvExample)
|
||||
app.add_config_value("repo_commit_hash", "", "env")
|
||||
|
||||
return {
|
||||
'version': '0.1',
|
||||
'parallel_read_safe': True,
|
||||
'parallel_write_safe': True,
|
||||
}
|
||||
113
LVGL.Simulator/lvgl/docs/_static/css/custom.css
vendored
Normal file
@@ -0,0 +1,113 @@
|
||||
table, th, td {
|
||||
border: 1px solid #bbb;
|
||||
padding: 10px;
|
||||
}
|
||||
|
||||
td {
|
||||
text-align:center;
|
||||
}
|
||||
span.pre
|
||||
{
|
||||
padding-right:8px;
|
||||
}
|
||||
|
||||
span.pre:first-child
|
||||
{
|
||||
padding-right:0px;
|
||||
}
|
||||
|
||||
|
||||
code.sig-name
|
||||
{
|
||||
/*margin-left:8px;*/
|
||||
}
|
||||
|
||||
.toggle .header {
|
||||
display: block;
|
||||
clear: both;
|
||||
cursor: pointer;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.toggle .header:before {
|
||||
font-family: FontAwesome, "Lato","proxima-nova","Helvetica Neue",Arial,sans-serif;
|
||||
content: "\f0da \00a0 Show ";
|
||||
display: inline-block;
|
||||
font-size: 1.1em;
|
||||
}
|
||||
|
||||
.toggle .header.open:before {
|
||||
content: "\f0d7 \00a0 Hide ";
|
||||
}
|
||||
|
||||
.header p {
|
||||
display: inline-block;
|
||||
font-size: 1.1em;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
.wy-side-nav-search {
|
||||
background-color: #f5f5f5;
|
||||
}
|
||||
.wy-side-nav-search>div.version {
|
||||
color: #333;
|
||||
display: none; /*replaced by dropdown*/
|
||||
}
|
||||
|
||||
|
||||
.home-img {
|
||||
width:32%;
|
||||
transition: transform .3s ease-out;
|
||||
}
|
||||
|
||||
.home-img:hover {
|
||||
transform: translate(0, -10px);
|
||||
}
|
||||
|
||||
/*Let `code` wrap*/
|
||||
.rst-content code, .rst-content tt, code {
|
||||
white-space: normal;
|
||||
}
|
||||
|
||||
.lv-example, .lv-example > iframe {
|
||||
border: none;
|
||||
outline: none;
|
||||
padding: none;
|
||||
display: block;
|
||||
width: 320px;
|
||||
height: 240px;
|
||||
flex: none;
|
||||
position: relative;
|
||||
}
|
||||
|
||||
.lv-example > iframe {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
}
|
||||
|
||||
.lv-example-container {
|
||||
display: flex;
|
||||
padding-bottom: 16px;
|
||||
}
|
||||
.lv-example-description {
|
||||
flex: 1 1 auto;
|
||||
margin-left: 1rem;
|
||||
}
|
||||
|
||||
.lv-example-link-button {
|
||||
display: inline-block;
|
||||
padding: 4px 8px;
|
||||
border-radius: 4px;
|
||||
background-color: #2980b9;
|
||||
color: white;
|
||||
margin: 0 4px;
|
||||
}
|
||||
.lv-example-link-button:hover {
|
||||
color: white;
|
||||
filter: brightness(120%);
|
||||
}
|
||||
|
||||
.lv-example-link-button:visited {
|
||||
color: white;
|
||||
}
|
||||
5
LVGL.Simulator/lvgl/docs/_static/css/fontawesome.min.css
vendored
Normal file
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_1.png
vendored
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_2.png
vendored
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_3.png
vendored
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_4.png
vendored
Normal file
|
After Width: | Height: | Size: 16 KiB |
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_5.png
vendored
Normal file
|
After Width: | Height: | Size: 17 KiB |
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_6.png
vendored
Normal file
|
After Width: | Height: | Size: 17 KiB |
BIN
LVGL.Simulator/lvgl/docs/_static/img/home_banner.jpg
vendored
Normal file
|
After Width: | Height: | Size: 186 KiB |
31
LVGL.Simulator/lvgl/docs/_templates/layout.html
vendored
Normal file
@@ -0,0 +1,31 @@
|
||||
{% extends "!layout.html" %}
|
||||
|
||||
{%- block extrahead %}
|
||||
{{ super() }}
|
||||
<!-- Global site tag (gtag.js) - Google Analytics -->
|
||||
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-78811084-3"></script>
|
||||
<script>
|
||||
window.dataLayer = window.dataLayer || [];
|
||||
function gtag(){dataLayer.push(arguments);}
|
||||
gtag('js', new Date());
|
||||
|
||||
gtag('config', 'UA-78811084-3', { 'anonymize_ip': true });
|
||||
</script>
|
||||
{% endblock %}
|
||||
|
||||
{% block footer %}
|
||||
{{ super() }}
|
||||
<div class="footer">This page uses <a href="https://analytics.google.com/">
|
||||
Google Analytics</a> to collect statistics. You can disable it by blocking
|
||||
the JavaScript coming from www.google-analytics.com.
|
||||
<script type="text/javascript">
|
||||
(function() {
|
||||
var ga = document.createElement('script');
|
||||
ga.src = ('https:' == document.location.protocol ?
|
||||
'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
|
||||
ga.setAttribute('async', 'true');
|
||||
document.documentElement.firstChild.appendChild(ga);
|
||||
})();
|
||||
</script>
|
||||
</div>
|
||||
{% endblock %}
|
||||
82
LVGL.Simulator/lvgl/docs/_templates/page.html
vendored
Normal file
@@ -0,0 +1,82 @@
|
||||
{% extends "!page.html" %}
|
||||
|
||||
{% block footer %}
|
||||
|
||||
<style>
|
||||
.wy-side-nav-search > div[role="search"] {
|
||||
color: black;
|
||||
}
|
||||
</style>
|
||||
<script type="text/javascript">
|
||||
$(document).ready(function() {
|
||||
$(".toggle > *").hide();
|
||||
$(".toggle .header").show();
|
||||
$(".toggle .header").click(function() {
|
||||
$(this).parent().children().not(".header").toggle(400);
|
||||
$(this).parent().children(".header").toggleClass("open");
|
||||
})
|
||||
});
|
||||
</script>
|
||||
|
||||
<script type="text/javascript">
|
||||
function add_version_selector()
|
||||
{
|
||||
return fetch("https://raw.githubusercontent.com/lvgl/docs_compiled/gh-pages/versionlist.txt")
|
||||
.then(res => res.text())
|
||||
.then(text => {
|
||||
const versions = text.split("\n").filter(version => version.trim().length > 0);
|
||||
let p = document.getElementById("rtd-search-form").parentElement;
|
||||
p.innerHTML = `
|
||||
<select name="versions" id="versions" onchange="ver_sel()" style="border-radius:5px; margin-bottom:15px">
|
||||
${versions.map(version => {
|
||||
let versionName = "";
|
||||
if(version == "master") versionName = "master (latest)";
|
||||
else versionName = "v" + ((version.indexOf(".") != -1) ? version : (version + " (latest minor)"));
|
||||
return `<option value="${version}">${versionName}</option>`;
|
||||
})}
|
||||
</select>` + p.innerHTML;
|
||||
});
|
||||
}
|
||||
|
||||
function ver_sel()
|
||||
{
|
||||
var x = document.getElementById("versions").value;
|
||||
window.location.href = window.location.protocol + "//" + window.location.host + "/" + x + "/";
|
||||
}
|
||||
|
||||
document.addEventListener('DOMContentLoaded', (event) => {
|
||||
add_version_selector().then(() => {
|
||||
var value = window.location.pathname.split('/')[1];
|
||||
document.getElementById("versions").value = value;
|
||||
});
|
||||
|
||||
})
|
||||
document.addEventListener('DOMContentLoaded', (event) => {
|
||||
function onIntersection(entries) {
|
||||
entries.forEach(entry => {
|
||||
let currentlyLoaded = entry.target.getAttribute("data-is-loaded") == "true";
|
||||
let shouldBeLoaded = entry.intersectionRatio > 0;
|
||||
if(currentlyLoaded != shouldBeLoaded) {
|
||||
entry.target.setAttribute("data-is-loaded", shouldBeLoaded);
|
||||
if(shouldBeLoaded) {
|
||||
let iframe = document.createElement("iframe");
|
||||
iframe.src = entry.target.getAttribute("data-real-src");
|
||||
entry.target.appendChild(iframe);
|
||||
} else {
|
||||
let iframe = entry.target.querySelector("iframe");
|
||||
iframe.parentNode.removeChild(iframe);
|
||||
}
|
||||
}
|
||||
});
|
||||
}
|
||||
const config = {
|
||||
rootMargin: '600px 0px',
|
||||
threshold: 0.01
|
||||
};
|
||||
let observer = new IntersectionObserver(onIntersection, config);
|
||||
document.querySelectorAll(".lv-example").forEach(iframe => {
|
||||
observer.observe(iframe);
|
||||
});
|
||||
});
|
||||
</script>
|
||||
{% endblock %}
|
||||
80
LVGL.Simulator/lvgl/docs/build.py
Normal file
@@ -0,0 +1,80 @@
|
||||
#!/usr/bin/env python3
|
||||
|
||||
import sys
|
||||
import os
|
||||
import subprocess
|
||||
import re
|
||||
import example_list as ex
|
||||
|
||||
langs = ['en']
|
||||
|
||||
# Change to script directory for consistency
|
||||
abspath = os.path.abspath(__file__)
|
||||
dname = os.path.dirname(abspath)
|
||||
os.chdir(dname)
|
||||
|
||||
def cmd(s):
|
||||
print("")
|
||||
print(s)
|
||||
print("-------------------------------------")
|
||||
r = os.system(s)
|
||||
if r != 0:
|
||||
print("Exit build due to previous error")
|
||||
exit(-1)
|
||||
|
||||
# Get the current branch name
|
||||
status, br = subprocess.getstatusoutput("git branch | grep '*'")
|
||||
_, gitcommit = subprocess.getstatusoutput("git rev-parse HEAD")
|
||||
br = re.sub('\* ', '', br)
|
||||
|
||||
# Generate the list of examples
|
||||
ex.exec()
|
||||
|
||||
urlpath = re.sub('release/', '', br)
|
||||
|
||||
# Be sure the GitHub links point to the right branch
|
||||
f = open("header.rst", "w")
|
||||
f.write(".. |github_link_base| replace:: https://github.com/lvgl/lvgl/blob/" + gitcommit + "/docs")
|
||||
f.close()
|
||||
|
||||
base_html = "html_baseurl = 'https://docs.lvgl.io/" + urlpath + "/en/html/'"
|
||||
|
||||
os.system("sed -i \"s|html_baseurl = .*|" + base_html +"|\" conf.py")
|
||||
|
||||
clean = 0
|
||||
trans = 0
|
||||
skip_latex = False
|
||||
args = sys.argv[1:]
|
||||
if len(args) >= 1:
|
||||
if "clean" in args: clean = 1
|
||||
if "skip_latex" in args: skip_latex = True
|
||||
|
||||
lang = "en"
|
||||
print("")
|
||||
print("****************")
|
||||
print("Building")
|
||||
print("****************")
|
||||
if clean:
|
||||
cmd("rm -rf " + lang)
|
||||
cmd("mkdir " + lang)
|
||||
|
||||
|
||||
print("Running doxygen")
|
||||
cmd("cd ../scripts && doxygen Doxyfile")
|
||||
# BUILD PDF
|
||||
|
||||
if not skip_latex:
|
||||
# Silly workaround to include the more or less correct PDF download link in the PDF
|
||||
#cmd("cp -f " + lang +"/latex/LVGL.pdf LVGL.pdf | true")
|
||||
cmd("sphinx-build -b latex . out_latex")
|
||||
|
||||
# Generate PDF
|
||||
cmd("cd out_latex && latexmk -pdf 'LVGL.tex'")
|
||||
# Copy the result PDF to the main directory to make it available for the HTML build
|
||||
cmd("cd out_latex && cp -f LVGL.pdf ../LVGL.pdf")
|
||||
else:
|
||||
print("skipping latex build as requested")
|
||||
|
||||
# BUILD HTML
|
||||
cmd("sphinx-build -b html . ../out_html")
|
||||
|
||||
239
LVGL.Simulator/lvgl/docs/conf.py
Normal file
@@ -0,0 +1,239 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# LVGL documentation build configuration file, created by
|
||||
# sphinx-quickstart on Wed Jun 12 16:38:40 2019.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its
|
||||
# containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
import os
|
||||
import sys
|
||||
import subprocess
|
||||
sys.path.insert(0, os.path.abspath('./_ext'))
|
||||
|
||||
import recommonmark
|
||||
from recommonmark.transform import AutoStructify
|
||||
from sphinx.builders.html import StandaloneHTMLBuilder
|
||||
from subprocess import Popen, PIPE
|
||||
|
||||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#
|
||||
# needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = ['sphinx.ext.autodoc',
|
||||
'sphinx.ext.intersphinx',
|
||||
'sphinx.ext.todo',
|
||||
'recommonmark',
|
||||
'sphinx_markdown_tables',
|
||||
'breathe',
|
||||
'sphinx_sitemap',
|
||||
'lv_example'
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
# The default language to highlight source code in. The default is 'python'.
|
||||
# The value should be a valid Pygments lexer name, see Showing code examples for more details.
|
||||
|
||||
|
||||
highlight_language = 'c'
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
#
|
||||
source_suffix = ['.rst', '.md']
|
||||
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = 'LVGL'
|
||||
copyright = '2021, LVGL Kft'
|
||||
author = 'LVGL community'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
# embeddedt: extract using scripts/find_version.sh
|
||||
|
||||
version = subprocess.run(["../scripts/find_version.sh"], capture_output=True).stdout.decode("utf-8").strip()
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = None
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This patterns also effect to html_static_path and html_extra_path
|
||||
exclude_patterns = ['_build', 'doxygen_html', 'Thumbs.db', '.DS_Store',
|
||||
'README.md', 'lv_examples', 'out_html' ]
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# If true, `todo` and `todoList` produce output, else they produce nothing.
|
||||
todo_include_todos = True
|
||||
|
||||
|
||||
# -- Options for HTML output ----------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
#
|
||||
html_theme_options = {
|
||||
'collapse_navigation' : False,
|
||||
'logo_only': True,
|
||||
}
|
||||
# For site map generation
|
||||
html_baseurl = 'https://docs.lvgl.io/master/en/html/'
|
||||
sitemap_url_scheme = "{link}"
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
# Custom sidebar templates, must be a dictionary that maps document names
|
||||
# to template names.
|
||||
#
|
||||
# This is required for the alabaster theme
|
||||
# refs: http://alabaster.readthedocs.io/en/latest/installation.html#sidebars
|
||||
html_sidebars = {
|
||||
'**': [
|
||||
'relations.html', # needs 'show_related': True theme option to display
|
||||
'searchbox.html',
|
||||
]
|
||||
}
|
||||
|
||||
html_favicon = 'favicon.png'
|
||||
html_logo = 'logo_lvgl.png'
|
||||
|
||||
# -- Options for HTMLHelp output ------------------------------------------
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'LVGLdoc'
|
||||
|
||||
html_last_updated_fmt = ''
|
||||
|
||||
# -- Options for LaTeX output ---------------------------------------------
|
||||
|
||||
latex_engine = 'xelatex'
|
||||
latex_use_xindy = False
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
#
|
||||
# 'papersize': 'letterpaper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#
|
||||
# 'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#
|
||||
# 'preamble': '',
|
||||
|
||||
# Latex figure (float) alignment
|
||||
#
|
||||
# 'figure_align': 'htbp',
|
||||
|
||||
'inputenc': '',
|
||||
'utf8extra': '',
|
||||
'classoptions': ',openany,oneside',
|
||||
'babel': '\\usepackage{babel}',
|
||||
'passoptionstopackages': r'''
|
||||
\PassOptionsToPackage{bookmarksdepth=5}{hyperref}% depth of pdf bookmarks
|
||||
''',
|
||||
'preamble': r'''
|
||||
\usepackage{fontspec}
|
||||
\setmonofont{DejaVu Sans Mono}
|
||||
\usepackage{silence}
|
||||
\WarningsOff*
|
||||
''',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'LVGL.tex', 'LVGL Documentation ' + version,
|
||||
'LVGL community', 'manual'),
|
||||
]
|
||||
|
||||
|
||||
# -- Options for manual page output ---------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'lvgl', 'LVGL Documentation ' + version,
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
|
||||
# -- Options for Texinfo output -------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'LVGL', 'LVGL Documentation ' + version,
|
||||
author, 'Contributors of LVGL', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
||||
breathe_projects = {
|
||||
"lvgl":"xml/",
|
||||
}
|
||||
|
||||
StandaloneHTMLBuilder.supported_image_types = [
|
||||
'image/svg+xml',
|
||||
'image/gif', #prefer gif over png
|
||||
'image/png',
|
||||
'image/jpeg'
|
||||
]
|
||||
|
||||
smartquotes = False
|
||||
|
||||
_, repo_commit_hash = subprocess.getstatusoutput("git rev-parse HEAD")
|
||||
|
||||
|
||||
# Example configuration for intersphinx: refer to the Python standard library.
|
||||
|
||||
def setup(app):
|
||||
app.add_config_value('recommonmark_config', {
|
||||
'enable_eval_rst': True,
|
||||
'enable_auto_toc_tree': 'True',
|
||||
}, True)
|
||||
app.add_transform(AutoStructify)
|
||||
app.add_css_file('css/custom.css')
|
||||
app.add_css_file('css/fontawesome.min.css')
|
||||
127
LVGL.Simulator/lvgl/docs/example_list.py
Normal file
@@ -0,0 +1,127 @@
|
||||
#!/usr/bin/env python3
|
||||
import os
|
||||
|
||||
|
||||
def process_index_rst(path):
|
||||
# print(path)
|
||||
with open(path) as fp:
|
||||
last_line=""
|
||||
line=""
|
||||
title_tmp=""
|
||||
line = fp.readline()
|
||||
d = {}
|
||||
while line:
|
||||
if line[0:3] == '"""':
|
||||
title_tmp = last_line
|
||||
elif line[0:15] ==".. lv_example::":
|
||||
name = line[16:].strip()
|
||||
title_tmp = title_tmp.strip()
|
||||
d[name] = title_tmp
|
||||
last_line = line
|
||||
line = fp.readline()
|
||||
|
||||
return(d)
|
||||
|
||||
h1= {
|
||||
"get_started":"Get started",
|
||||
"styles":"Styles",
|
||||
"anim":"Animations",
|
||||
"event":"Events",
|
||||
"layouts":"Layouts",
|
||||
"scroll":"Scrolling",
|
||||
"widgets":"Widgets"
|
||||
}
|
||||
|
||||
widgets = {
|
||||
"obj":"Base object",
|
||||
"arc":"Arc",
|
||||
"bar":"Bar",
|
||||
"btn":"Button",
|
||||
"btnmatrix":"Button matrix",
|
||||
"calendar":"Calendar",
|
||||
"canvas":"Canvas",
|
||||
"chart":"Chart",
|
||||
"checkbox":"Checkbox",
|
||||
"colorwheel":"Colorwheel",
|
||||
"dropdown":"Dropdown",
|
||||
"img":"Image",
|
||||
"imgbtn":"Image button",
|
||||
"keyboard":"Keyboard",
|
||||
"label":"Label",
|
||||
"led":"LED",
|
||||
"line":"Line",
|
||||
"list":"List",
|
||||
"menu":"Menu",
|
||||
"meter":"Meter",
|
||||
"msgbox":"Message box",
|
||||
"roller":"Roller",
|
||||
"slider":"Slider",
|
||||
"span":"Span",
|
||||
"spinbox":"Spinbox",
|
||||
"spinner":"Spinner",
|
||||
"switch":"Switch",
|
||||
"table":"Table",
|
||||
"tabview":"Tabview",
|
||||
"textarea":"Textarea",
|
||||
"tileview":"Tabview",
|
||||
"win":"Window",
|
||||
}
|
||||
|
||||
layouts = {
|
||||
"flex":"Flex",
|
||||
"grid":"Grid",
|
||||
}
|
||||
|
||||
|
||||
def print_item(path, lvl, d, fout):
|
||||
for k in d:
|
||||
v = d[k]
|
||||
if k.startswith(path + "/lv_example_"):
|
||||
fout.write("#"*lvl + " " + v + "\n")
|
||||
fout.write('```eval_rst\n')
|
||||
fout.write(f".. lv_example:: {k}\n")
|
||||
fout.write('```\n')
|
||||
fout.write("\n")
|
||||
|
||||
def exec():
|
||||
paths = [ "../examples/", "../demos/"]
|
||||
fout = open("examples.md", "w")
|
||||
filelist = []
|
||||
|
||||
for path in paths:
|
||||
for root, dirs, files in os.walk(path):
|
||||
for f in files:
|
||||
#append the file name to the list
|
||||
filelist.append(os.path.join(root,f))
|
||||
|
||||
filelist = [ fi for fi in filelist if fi.endswith("index.rst") ]
|
||||
|
||||
d_all = {}
|
||||
#print all the file names
|
||||
for fn in filelist:
|
||||
d_act = process_index_rst(fn)
|
||||
d_all.update(d_act)
|
||||
|
||||
fout.write("```eval_rst\n")
|
||||
fout.write(".. include:: /header.rst\n")
|
||||
fout.write(":github_url: |github_link_base|/examples.md\n")
|
||||
fout.write("```\n")
|
||||
fout.write("\n")
|
||||
fout.write("# Examples\n")
|
||||
|
||||
for h in h1:
|
||||
fout.write("## " + h1[h] + "\n")
|
||||
|
||||
if h == "widgets":
|
||||
for w in widgets:
|
||||
fout.write("### " + widgets[w] + "\n")
|
||||
print_item(h + "/" + w, 4, d_all, fout)
|
||||
elif h == "layouts":
|
||||
for l in layouts:
|
||||
fout.write("### " + layouts[l] + "\n")
|
||||
print_item(h + "/" + l, 4, d_all, fout)
|
||||
else:
|
||||
print_item(h, 3, d_all, fout)
|
||||
|
||||
fout.write("")
|
||||
|
||||
BIN
LVGL.Simulator/lvgl/docs/favicon.png
Normal file
|
After Width: | Height: | Size: 533 B |
8
LVGL.Simulator/lvgl/docs/get-started/bindings/cpp.md
Normal file
@@ -0,0 +1,8 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/bindings/micropython.md
|
||||
```
|
||||
# Cpp
|
||||
|
||||
In progress: https://github.com/lvgl/lv_binding_cpp
|
||||
|
||||
16
LVGL.Simulator/lvgl/docs/get-started/bindings/index.md
Normal file
@@ -0,0 +1,16 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/bindings/index.md
|
||||
```
|
||||
# Bindings
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
micropython
|
||||
cpp
|
||||
```
|
||||
|
||||
96
LVGL.Simulator/lvgl/docs/get-started/bindings/micropython.md
Normal file
@@ -0,0 +1,96 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/bindings/micropython.md
|
||||
```
|
||||
# Micropython
|
||||
|
||||
## What is Micropython?
|
||||
|
||||
[Micropython](http://micropython.org/) is Python for microcontrollers.
|
||||
Using Micropython, you can write Python3 code and run it even on a bare metal architecture with limited resources.
|
||||
|
||||
### Highlights of Micropython
|
||||
|
||||
- **Compact** - Fits and runs within just 256k of code space and 16k of RAM. No OS is needed, although you can also run it with an OS, if you want.
|
||||
- **Compatible** - Strives to be as compatible as possible with normal Python (known as CPython).
|
||||
- **Versatile** - Supports many architectures (x86, x86-64, ARM, ARM Thumb, Xtensa).
|
||||
- **Interactive** - No need for the compile-flash-boot cycle. With the REPL (interactive prompt) you can type commands and execute them immediately, run scripts, etc.
|
||||
- **Popular** - Many platforms are supported. The user base is growing bigger. Notable forks: [MicroPython](https://github.com/micropython/micropython), [CircuitPython](https://github.com/adafruit/circuitpython), [MicroPython_ESP32_psRAM_LoBo](https://github.com/loboris/MicroPython_ESP32_psRAM_LoBo)
|
||||
- **Embedded Oriented** - Comes with modules specifically for embedded systems, such as the [machine module](https://docs.micropython.org/en/latest/library/machine.html#classes) for accessing low-level hardware (I/O pins, ADC, UART, SPI, I2C, RTC, Timers etc.)
|
||||
|
||||
---
|
||||
|
||||
## Why Micropython + LVGL?
|
||||
|
||||
Currently, Micropython [does not have a good high-level GUI library](https://forum.micropython.org/viewtopic.php?f=18&t=5543) by default. LVGL is an [Object-Oriented Component Based](https://blog.lvgl.io/2018-12-13/extend-lvgl-objects) high-level GUI library, which seems to be a natural candidate to map into a higher level language, such as Python. LVGL is implemented in C and its APIs are in C.
|
||||
|
||||
### Here are some advantages of using LVGL in Micropython:
|
||||
|
||||
- Develop GUI in Python, a very popular high level language. Use paradigms such as Object-Oriented Programming.
|
||||
- Usually, GUI development requires multiple iterations to get things right. With C, each iteration consists of **`Change code` > `Build` > `Flash` > `Run`**.
|
||||
In Micropython it's just **`Change code` > `Run`** ! You can even run commands interactively using the [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) (the interactive prompt)
|
||||
|
||||
### Micropython + LVGL could be used for:
|
||||
|
||||
- Fast prototyping GUI.
|
||||
- Shortening the cycle of changing and fine-tuning the GUI.
|
||||
- Modelling the GUI in a more abstract way by defining reusable composite objects, taking advantage of Python's language features such as Inheritance, Closures, List Comprehension, Generators, Exception Handling, Arbitrary Precision Integers and others.
|
||||
- Make LVGL accessible to a larger audience. No need to know C to create a nice GUI on an embedded system.
|
||||
This goes well with [CircuitPython vision](https://learn.adafruit.com/welcome-to-circuitpython/what-is-circuitpython). CircuitPython was designed with education in mind, to make it easier for new or inexperienced users to get started with embedded development.
|
||||
- Creating tools to work with LVGL at a higher level (e.g. drag-and-drop designer).
|
||||
|
||||
---
|
||||
|
||||
## So what does it look like?
|
||||
|
||||
> TL;DR:
|
||||
> It's very much like the C API, but Object-Oriented for LVGL components.
|
||||
|
||||
Let's dive right into an example!
|
||||
|
||||
### A simple example
|
||||
|
||||
```python
|
||||
import lvgl as lv
|
||||
lv.init()
|
||||
scr = lv.obj()
|
||||
btn = lv.btn(scr)
|
||||
btn.align(lv.scr_act(), lv.ALIGN.CENTER, 0, 0)
|
||||
label = lv.label(btn)
|
||||
label.set_text("Button")
|
||||
lv.scr_load(scr)
|
||||
```
|
||||
|
||||
## How can I use it?
|
||||
|
||||
### Online Simulator
|
||||
|
||||
If you want to experiment with LVGL + Micropython without downloading anything - you can use our online simulator!
|
||||
It's a fully functional LVGL + Micropython that runs entirely in the browser and allows you to edit a python script and run it.
|
||||
|
||||
[Click here to experiment on the online simulator](https://sim.lvgl.io/)
|
||||
|
||||
[Hello World](https://sim.lvgl.io/v7/micropython/ports/javascript/bundle_out/index.html?script=https://gist.githubusercontent.com/amirgon/51299ce9b6448328a855826149482ae6/raw/0f235c6d40462fd2f0e55364b874f14fe3fd613c/lvgl_hello_world.py&script_startup=https://gist.githubusercontent.com/amirgon/7bf15a66ba6d959bbf90d10f3da571be/raw/8684b5fa55318c184b1310663b187aaab5c65be6/init_lv_mp_js.py)
|
||||
|
||||
Note: the online simulator is available for lvgl v6 and v7.
|
||||
|
||||
### PC Simulator
|
||||
|
||||
Micropython is ported to many platforms. One notable port is "unix", which allows you to build and run Micropython (+LVGL) on a Linux machine. (On a Windows machine you might need Virtual Box or WSL or MinGW or Cygwin etc.)
|
||||
|
||||
[Click here to know more information about building and running the unix port](https://github.com/lvgl/lv_micropython)
|
||||
|
||||
### Embedded platform
|
||||
|
||||
In the end, the goal is to run it all on an embedded platform.
|
||||
Both Micropython and LVGL can be used on many embedded architectures, such as stm32, ESP32 etc.
|
||||
You would also need display and input drivers. We have some sample drivers (ESP32+ILI9341, as well as some other examples), but chances are you would want to create your own input/display drivers for your specific hardware.
|
||||
Drivers can be implemented either in C as a Micropython module, or in pure Micropython!
|
||||
|
||||
## Where can I find more information?
|
||||
|
||||
- In this [Blog Post](https://blog.lvgl.io/2019-02-20/micropython-bindings)
|
||||
- `lv_micropython` [README](https://github.com/lvgl/lv_micropython)
|
||||
- `lv_binding_micropython` [README](https://github.com/lvgl/lv_binding_micropython)
|
||||
- The [LVGL micropython forum](https://forum.lvgl.io/c/micropython) (Feel free to ask anything!)
|
||||
- At Micropython: [docs](http://docs.micropython.org/en/latest/) and [forum](https://forum.micropython.org/)
|
||||
30
LVGL.Simulator/lvgl/docs/get-started/index.md
Normal file
@@ -0,0 +1,30 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/index.md
|
||||
```
|
||||
# Get started
|
||||
|
||||
There are several ways to get your feet wet with LVGL. Here is one recommended order of documents to read and things to play with when you are learning to use LVGL:
|
||||
1. Check the [Online demos](https://lvgl.io/demos) to see LVGL in action (3 minutes)
|
||||
2. Read the [Introduction](https://docs.lvgl.io/latest/en/html/intro/index.html) page of the documentation (5 minutes)
|
||||
3. Read the [Quick overview](https://docs.lvgl.io/master/get-started/quick-overview.html) page of the documentation (15 minutes)
|
||||
4. Set up a [Simulator](https://docs.lvgl.io/master/get-started/platforms/pc-simulator.html) (10 minutes)
|
||||
5. Try out some [Examples](https://docs.lvgl.io/master/examples.html)
|
||||
6. Check out the Platform-specific tutorials. (in this section below). (10 minutes)
|
||||
7. Port LVGL to a board. See the [Porting](https://docs.lvgl.io/master/porting/index.html) guide or check the ready to use [Projects](https://github.com/lvgl?q=lv_port_&type=&language=)
|
||||
8. Read the [Overview](https://docs.lvgl.io/master/overview/index.html) page to get a better understanding of the library. (2-3 hours)
|
||||
9. Check the documentation of the [Widgets](https://docs.lvgl.io/master/widgets/index.html) to see their features and usage
|
||||
10. If you have questions got to the [Forum](http://forum.lvgl.io/)
|
||||
11. Read the [Contributing](https://docs.lvgl.io/master/CONTRIBUTING.html) guide to see how you can help to improve LVGL (15 minutes)
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
platforms/index
|
||||
os/index
|
||||
bindings/index
|
||||
```
|
||||
|
||||
7
LVGL.Simulator/lvgl/docs/get-started/os/freertos.md
Normal file
@@ -0,0 +1,7 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/os/freertos.md
|
||||
```
|
||||
# FreeRTOS
|
||||
|
||||
TODO
|
||||
17
LVGL.Simulator/lvgl/docs/get-started/os/index.md
Normal file
@@ -0,0 +1,17 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/os/index.md
|
||||
```
|
||||
# (RT)OS
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
nuttx
|
||||
rt-thread
|
||||
freertos
|
||||
zephyr
|
||||
```
|
||||
|
||||
101
LVGL.Simulator/lvgl/docs/get-started/os/nuttx.md
Normal file
@@ -0,0 +1,101 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/os/nuttx.md
|
||||
```
|
||||
# NuttX RTOS
|
||||
|
||||
## What is NuttX?
|
||||
|
||||
[NuttX](https://nuttx.apache.org/) is a mature and secure real-time operating system (RTOS) with an emphasis on technical standards compliance and small size.
|
||||
It is scalable from 8-bit to 64-bit microcontrollers and microprocessors and compliant with the Portable Operating System Interface (POSIX) and the American National Standards Institute (ANSI) standards and with many Linux-like subsystems.
|
||||
The best way to think about NuttX is to think of it as a small Unix/Linux for microcontrollers.
|
||||
|
||||
### Highlights of NuttX
|
||||
|
||||
- **Small** - Fits and runs in microcontrollers as small as 32 kB Flash and 8 kB of RAM.
|
||||
- **Compliant** - Strives to be as compatible as possible with POSIX and Linux.
|
||||
- **Versatile** - Supports many architectures (ARM, ARM Thumb, AVR, MIPS, OpenRISC, RISC-V 32-bit and 64-bit, RX65N, x86-64, Xtensa, Z80/Z180, etc.).
|
||||
- **Modular** - Its modular design allows developers to select only what really matters and use modules to include new features.
|
||||
- **Popular** - NuttX is used by many companies around the world. Probably you already used a product with NuttX without knowing it was running NuttX.
|
||||
- **Predictable** - NuttX is a preemptible Realtime kernel, so you can use it to create predictable applications for realtime control.
|
||||
|
||||
---
|
||||
|
||||
## Why NuttX + LVGL?
|
||||
|
||||
Although NuttX has its own graphic library called [NX](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474), LVGL is a good alternative because users could find more eye-candy demos and they can reuse code from previous projects.
|
||||
LVGL is an [Object-Oriented Component Based](https://blog.lvgl.io/2018-12-13/extend-lvgl-objects) high-level GUI library, that could fit very well for a RTOS with advanced features like NuttX.
|
||||
LVGL is implemented in C and its APIs are in C.
|
||||
|
||||
### Here are some advantages of using LVGL in NuttX
|
||||
|
||||
- Develop GUI in Linux first and when it is done just compile it for NuttX. Nothing more, no wasting of time.
|
||||
- Usually, GUI development for low level RTOS requires multiple iterations to get things right, where each iteration consists of **`Change code` > `Build` > `Flash` > `Run`**.
|
||||
Using LVGL, Linux and NuttX you can reduce this process and just test everything on your computer and when it is done, compile it on NuttX and that is it.
|
||||
|
||||
### NuttX + LVGL could be used for
|
||||
|
||||
- GUI demos to demonstrate your board graphics capacities.
|
||||
- Fast prototyping GUI for MVP (Minimum Viable Product) presentation.
|
||||
- visualize sensor data directly and easily on the board without using a computer.
|
||||
- Final products with a GUI without a touchscreen (i.e. 3D Printer Interface using Rotary Encoder to Input data).
|
||||
- Final products with a touchscreen (and all sorts of bells and whistles).
|
||||
|
||||
---
|
||||
|
||||
## How to get started with NuttX and LVGL?
|
||||
|
||||
There are many boards in the [NuttX mainline](https://github.com/apache/incubator-nuttx) with support for LVGL.
|
||||
Let's use the [STM32F429IDISCOVERY](https://www.st.com/en/evaluation-tools/32f429idiscovery.html) as an example because it is a very popular board.
|
||||
|
||||
### First you need to install the pre-requisites on your system
|
||||
|
||||
Let's use the [Windows Subsystem for Linux](https://acassis.wordpress.com/2018/01/10/how-to-build-nuttx-on-windows-10/)
|
||||
|
||||
```shell
|
||||
$ sudo apt-get install automake bison build-essential flex gcc-arm-none-eabi gperf git libncurses5-dev libtool libusb-dev libusb-1.0.0-dev pkg-config kconfig-frontends openocd
|
||||
```
|
||||
|
||||
### Now let's create a workspace to save our files
|
||||
|
||||
```shell
|
||||
$ mkdir ~/nuttxspace
|
||||
$ cd ~/nuttxspace
|
||||
```
|
||||
|
||||
### Clone the NuttX and Apps repositories:
|
||||
|
||||
```shell
|
||||
$ git clone https://github.com/apache/incubator-nuttx nuttx
|
||||
$ git clone https://github.com/apache/incubator-nuttx-apps apps
|
||||
```
|
||||
|
||||
### Configure NuttX to use the stm32f429i-disco board and the LVGL Demo
|
||||
|
||||
```shell
|
||||
$ ./tools/configure.sh stm32f429i-disco:lvgl
|
||||
$ make
|
||||
```
|
||||
|
||||
If everything went fine you should have now the file `nuttx.bin` to flash on your board:
|
||||
|
||||
```shell
|
||||
$ ls -l nuttx.bin
|
||||
-rwxrwxr-x 1 alan alan 287144 Jun 27 09:26 nuttx.bin
|
||||
```
|
||||
|
||||
### Flashing the firmware in the board using OpenOCD:
|
||||
```shell
|
||||
$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg -c init -c "reset halt" -c "flash write_image erase nuttx.bin 0x08000000"
|
||||
```
|
||||
|
||||
Reset the board and using the 'NSH>' terminal start the LVGL demo:
|
||||
```shell
|
||||
nsh> lvgldemo
|
||||
```
|
||||
|
||||
## Where can I find more information?
|
||||
|
||||
- This blog post: [LVGL on LPCXpresso54628](https://acassis.wordpress.com/2018/07/19/running-nuttx-on-lpcxpresso54628-om13098/)
|
||||
- NuttX mailing list: [Apache NuttX Mailing List](http://nuttx.incubator.apache.org/community/)
|
||||
|
||||
48
LVGL.Simulator/lvgl/docs/get-started/os/rt-thread.md
Normal file
@@ -0,0 +1,48 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/os/rt-thread.md
|
||||
```
|
||||
# RT-Thread RTOS
|
||||
|
||||
<img src="https://raw.githubusercontent.com/RT-Thread/rt-thread/master/documentation/figures/logo.png" width=40% style="float: center;" >
|
||||
|
||||
## What is RT-Thread?
|
||||
|
||||
[Introduce about RT-Thread and how to run LVGL on RT-Thread in simulators](https://www.youtube.com/watch?v=k7QYk6hSwnc)
|
||||
|
||||
[**RT-Thread**](https://www.rt-thread.io/) is an [open source](https://github.com/RT-Thread/rt-thread), neutral, and community-based real-time operating system (RTOS). RT-Thread has **Standard version** and **Nano version**. For resource-constrained microcontroller (MCU) systems, the Nano version that requires only 3 KB Flash and 1.2 KB RAM memory resources can be tailored with easy-to-use tools. For resource-rich IoT devices, RT-Thread can use the **online software package** management tool, together with system configuration tools, to achieve intuitive and rapid modular cutting, seamlessly import rich software packages; thus, achieving complex functions like Android's graphical interface and touch sliding effects, smart voice interaction effects, and so on.
|
||||
|
||||
### Key features
|
||||
|
||||
- Designed for resource-constrained devices, the minimum kernel requires only 1.2KB of RAM and 3 KB of Flash.
|
||||
- A variety of standard interfaces, such as POSIX, CMSIS, C++ application environment.
|
||||
- Has rich components and a prosperous and fast growing <a href="https://packages.rt-thread.org/en/">package ecosystem</a>
|
||||
- Elegant code style, easy to use, read and master.
|
||||
- High Scalability. RT-Thread has high-quality scalable software architecture, loose coupling, modularity, is easy to tailor and expand.
|
||||
- Supports high-performance applications.
|
||||
- Supports all mainstream compiling tools such as GCC, Keil and IAR.
|
||||
- Supports a wide range of <a href="https://www.rt-thread.io/board.html">architectures and chips</a>.
|
||||
|
||||
|
||||
## How to run LVGL on RT-Thread?
|
||||
|
||||
[中文文档](https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/packages-manual/lvgl-docs/introduction)
|
||||
|
||||
LVGL has registered as a [software package](https://packages.rt-thread.org/en/detail.html?package=LVGL) of RT-Thread. By using [Env tool](https://www.rt-thread.io/download.html?download=Env) or [RT-Thread Studio IDE](https://www.rt-thread.io/download.html?download=Studio), RT-Thread users can easily download LVGL source code and combine with RT-Thread project. RT-Thread community has port LVGL to several BSPs:
|
||||
|
||||
| BSP | Note |
|
||||
| ------------------------------------------------------------ | ---- |
|
||||
| [QEMU simulator](https://github.com/RT-Thread/rt-thread/tree/master/bsp/qemu-vexpress-a9/applications/lvgl) | |
|
||||
| [Visual Studio simulator](https://github.com/RT-Thread/rt-thread/tree/master/bsp/simulator/applications/lvgl) | |
|
||||
| [Nuvoton numaker-iot-m487](https://github.com/RT-Thread/rt-thread/tree/master/bsp/nuvoton/numaker-iot-m487/applications/lvgl) | |
|
||||
| [Nuvoton numaker-pfm-m487](https://github.com/RT-Thread/rt-thread/tree/master/bsp/nuvoton/numaker-pfm-m487/applications/lvgl) | |
|
||||
| [Nuvoton nk-980iot](https://github.com/RT-Thread/rt-thread/tree/master/bsp/nuvoton/nk-980iot/applications/lvgl) | |
|
||||
| [Nuvoton numaker-m2354](https://github.com/RT-Thread/rt-thread/tree/master/bsp/nuvoton/numaker-m2354/applications/lvgl) | |
|
||||
| [Nuvoton nk-n9h30](https://github.com/RT-Thread/rt-thread/tree/master/bsp/nuvoton/nk-n9h30/applications/lvgl) | |
|
||||
| [Nuvoton numaker-m032ki](https://github.com/RT-Thread/rt-thread/tree/master/bsp/nuvoton/numaker-m032ki/applications/lvgl) | |
|
||||
| [NXP imxrt1060-evk](https://github.com/RT-Thread/rt-thread/tree/master/bsp/imxrt/imxrt1060-nxp-evk/applications/lvgl) | |
|
||||
| [STM32L475 pandora](https://github.com/RT-Thread/rt-thread/tree/master/bsp/stm32/stm32l475-atk-pandora/applications/lvgl) | |
|
||||
| [STM32F407 explorer](https://github.com/RT-Thread/rt-thread/tree/master/bsp/stm32/stm32f407-atk-explorer/applications/lvgl) | |
|
||||
| [STM32F469 Discovery](https://github.com/RT-Thread/rt-thread/tree/master/bsp/stm32/stm32f469-st-disco/applications/lvgl) | |
|
||||
| [Raspberry PICO](https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pico/applications/lvgl) | |
|
||||
|
||||
7
LVGL.Simulator/lvgl/docs/get-started/os/zephyr.md
Normal file
@@ -0,0 +1,7 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/os/zephyr.md
|
||||
```
|
||||
# Zephyr
|
||||
|
||||
TODO
|
||||
83
LVGL.Simulator/lvgl/docs/get-started/platforms/arduino.md
Normal file
@@ -0,0 +1,83 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platforms/arduino.md
|
||||
```
|
||||
|
||||
# Arduino
|
||||
|
||||
The [LVGL library](https://github.com/lvgl/lvgl) is directly available as Arduino libraries.
|
||||
|
||||
Note that you need to choose a board powerful enough to run LVGL and your GUI. See the [requirements of LVGL](https://docs.lvgl.io/master/intro/index.html#requirements).
|
||||
|
||||
For example ESP32 is a good candidate to create UI's with LVGL.
|
||||
|
||||
## Get the LVGL Arduino library
|
||||
|
||||
LVGL can be installed via the Arduino IDE Library Manager or as a .ZIP library.
|
||||
|
||||
You can [Download](https://github.com/lvgl/lvgl/archive/refs/heads/master.zip) the latest version of LVGL from GitHub and simply copy it to Arduino's library folder.
|
||||
|
||||
## Set up drivers
|
||||
|
||||
To get started it's recommended to use [TFT_eSPI](https://github.com/Bodmer/TFT_eSPI) library as a TFT driver to simplify testing.
|
||||
To make it work, setup `TFT_eSPI` according to your TFT display type via editing either
|
||||
- `User_Setup.h`
|
||||
- or by selecting a configuration in the `User_Setup_Select.h`
|
||||
|
||||
Both files are located in `TFT_eSPI` library's folder.
|
||||
|
||||
## Configure LVGL
|
||||
|
||||
LVGL has its own configuration file called `lv_conf.h`. When LVGL is installed, follow these configuration steps:
|
||||
1. Go to the directory of the installed Arduino libraries
|
||||
2. Go to `lvgl` and copy `lv_conf_template.h` as `lv_conf.h` into the Arduino Libraries directory next to the `lvgl` library folder.
|
||||
3. Open `lv_conf.h` and change the first `#if 0` to `#if 1` to enable the content of the file
|
||||
4. Set the color depth of you display in `LV_COLOR_DEPTH`
|
||||
5. Set `LV_TICK_CUSTOM 1`
|
||||
|
||||
Finally the layout with `lv_conf.h` should look like this:
|
||||
```
|
||||
arduino
|
||||
|-libraries
|
||||
|-lvgl
|
||||
|-other_lib_1
|
||||
|-other_lib_2
|
||||
|-lv_conf.h
|
||||
```
|
||||
|
||||
## Initialize and run LVGL
|
||||
|
||||
Take a look at [LVGL_Arduino.ino](https://github.com/lvgl/lvgl/blob/master/examples/arduino/LVGL_Arduino/LVGL_Arduino.ino) to see how to initialize LVGL.
|
||||
`TFT_eSPI` is used as the display driver.
|
||||
|
||||
In the INO file you can see how to register a display and a touchpad for LVGL and call an example.
|
||||
|
||||
## Use the examples and demos
|
||||
|
||||
Note that, there is no dedicated INO file for every example. Instead, you can load an example by calling an `lv_example_...` function. For example `lv_example_btn_1()`.
|
||||
|
||||
**IMPORTANT**
|
||||
Due to some the limitations of Arduino's build system you need to copy `lvgl/examples` to `lvgl/src/examples`. Similarly for the demos `lvgl/demos` to `lvgl/src/demos`.
|
||||
|
||||
## Debugging and logging
|
||||
|
||||
LVGL can display debug information in case of trouble.
|
||||
In the `LVGL_Arduino.ino` example there is a `my_print` method, which sends this debug information to the serial interface.
|
||||
To enable this feature you have to edit the `lv_conf.h` file and enable logging in the section `log settings`:
|
||||
|
||||
```c
|
||||
/*Log settings*/
|
||||
#define USE_LV_LOG 1 /*Enable/disable the log module*/
|
||||
#if LV_USE_LOG
|
||||
/* How important log should be added:
|
||||
* LV_LOG_LEVEL_TRACE A lot of logs to give detailed information
|
||||
* LV_LOG_LEVEL_INFO Log important events
|
||||
* LV_LOG_LEVEL_WARN Log if something unwanted happened but didn't cause a problem
|
||||
* LV_LOG_LEVEL_ERROR Only critical issue, when the system may fail
|
||||
* LV_LOG_LEVEL_NONE Do not log anything
|
||||
*/
|
||||
# define LV_LOG_LEVEL LV_LOG_LEVEL_WARN
|
||||
```
|
||||
|
||||
After enabling the log module and setting LV_LOG_LEVEL accordingly, the output log is sent to the `Serial` port @ 115200 bps.
|
||||
|
||||
83
LVGL.Simulator/lvgl/docs/get-started/platforms/cmake.md
Normal file
@@ -0,0 +1,83 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platforms/cmake.md
|
||||
```
|
||||
|
||||
# CMake
|
||||
LVGL supports integrating with [CMake](https://cmake.org/). It comes with preconfigured targets for:
|
||||
- [Espressif (ESP32)](https://docs.espressif.com/projects/esp-idf/en/v3.3/get-started-cmake/index.html)
|
||||
- [MicroPython](https://docs.micropython.org/en/v1.15/develop/cmodules.html)
|
||||
- [Zephyr](https://docs.zephyrproject.org/latest/guides/zephyr_cmake_package.html)
|
||||
|
||||
On top of the preconfigured targets you can also use "plain" CMake to integrate LVGL into any custom C/C++ project.
|
||||
|
||||
### Prerequisites
|
||||
- CMake ( >= 3.12.4 )
|
||||
- Compatible build tool e.g.
|
||||
- [Make](https://www.gnu.org/software/make/)
|
||||
- [Ninja](https://ninja-build.org/)
|
||||
|
||||
## Building LVGL with CMake
|
||||
There are many ways to include external CMake projects into your own. A modern one also used in this example is the CMake [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html) module. This module conveniently allows us to download dependencies directly at configure time from e.g. [GitHub](https://github.com/). Here is an example how we might include LVGL into our own project.
|
||||
|
||||
```cmake
|
||||
cmake_minimum_required(VERSION 3.14)
|
||||
include(FetchContent)
|
||||
|
||||
project(MyProject LANGUAGES C CXX)
|
||||
|
||||
# Build an executable called "MyFirmware"
|
||||
add_executable(MyFirmware src/main.c)
|
||||
|
||||
# Specify path to own LVGL config header
|
||||
set(LV_CONF_PATH
|
||||
${CMAKE_CURRENT_SOURCE_DIR}/src/lv_conf.h
|
||||
CACHE STRING "" FORCE)
|
||||
|
||||
# Fetch LVGL from GitHub
|
||||
FetchContent_Declare(lvgl URL https://github.com/lvgl/lvgl.git)
|
||||
FetchContent_MakeAvailable(lvgl)
|
||||
|
||||
# The target "MyFirmware" depends on LVGL
|
||||
target_link_libraries(MyFirmware PRIVATE lvgl::lvgl)
|
||||
```
|
||||
|
||||
This configuration declares a dependency between the two targets **MyFirmware** and **lvgl**. Upon building the target **MyFirmware** this dependency will be resolved and **lvgl** will be built and linked with it. Since LVGL requires a config header called [lv_conf.h](https://github.com/lvgl/lvgl/blob/master/lv_conf_template.h) to be includable by its sources we also set the option `LV_CONF_PATH` to point to our own copy of it.
|
||||
|
||||
### Additional CMake options
|
||||
Besides `LV_CONF_PATH` there are two additional CMake options to specify include paths.
|
||||
|
||||
`LV_LVGL_H_INCLUDE_SIMPLE` which specifies whether to `#include "lvgl.h"` absolut or relative
|
||||
|
||||
| ON (default) | OFF |
|
||||
| ------------ | -------------- |
|
||||
| "lvgl.h" | "../../lvgl.h" |
|
||||
|
||||
`LV_CONF_INCLUDE_SIMPLE` which specifies whether to `#include "lv_conf.h"` and `"lv_drv_conf.h"` absolut or relative
|
||||
|
||||
| ON (default) | OFF |
|
||||
| --------------- | --------------------- |
|
||||
| "lv_conf.h" | "../../lv_conf.h" |
|
||||
| "lv_drv_conf.h" | "../../lv_drv_conf.h" |
|
||||
|
||||
I do not recommend disabling those options unless your folder layout makes it absolutely necessary.
|
||||
|
||||
## Building LVGL examples with CMake
|
||||
LVGL [examples](https://docs.lvgl.io/master/examples.html) have their own CMake target. If you want to build the examples simply add them to your dependencies.
|
||||
|
||||
```cmake
|
||||
# The target "MyFirmware" depends on LVGL and examples
|
||||
target_link_libraries(MyFirmware PRIVATE lvgl::lvgl lvgl::examples)
|
||||
```
|
||||
|
||||
## Building LVGL drivers and demos with CMake
|
||||
Exactly the same goes for the [drivers](https://github.com/lvgl/lv_drivers) and the [demos](https://github.com/lvgl/lvgl/demos).
|
||||
|
||||
```cmake
|
||||
FetchContent_Declare(lv_drivers
|
||||
GIT_REPOSITORY https://github.com/lvgl/lv_drivers)
|
||||
FetchContent_MakeAvailable(lv_drivers)
|
||||
|
||||
# The target "MyFirmware" depends on LVGL, drivers and demos
|
||||
target_link_libraries(MyFirmware PRIVATE lvgl::lvgl lvgl::drivers lvgl::examples)
|
||||
```
|
||||
62
LVGL.Simulator/lvgl/docs/get-started/platforms/espressif.md
Normal file
@@ -0,0 +1,62 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platforms/espressif.md
|
||||
```
|
||||
|
||||
# Espressif (ESP32 chip series)
|
||||
LVGL can be used and configured as a standard [ESP-IDF](https://github.com/espressif/esp-idf) component.
|
||||
|
||||
More information about ESP-IDF build system can be found [here](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/build-system.html).
|
||||
|
||||
## LVGL demo project for ESP32
|
||||
|
||||
We've created [lv_port_esp32](https://github.com/lvgl/lv_port_esp32), a project using ESP-IDF and LVGL to show one of the demos from [demos](https://github.com/lvgl/lvgl/demos).
|
||||
You can configure the project to use one of the many supported display controllers and targets (chips).
|
||||
|
||||
See [lvgl_esp32_drivers](https://github.com/lvgl/lvgl_esp32_drivers) repository for a complete list
|
||||
of supported display and indev (touch) controllers and targets.
|
||||
|
||||
## Using LVGL in your ESP-IDF project
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* ESP-IDF v4.1 and above
|
||||
* ESP evaluation board with a display
|
||||
|
||||
### Obtaining LVGL
|
||||
|
||||
__Option 1:__ git submodule
|
||||
|
||||
Simply clone LVGL into your `project_root/components` directory and it will be automatically integrated into the project.
|
||||
If the project is a git repository you can include LVGL as a git submodule:
|
||||
|
||||
```sh
|
||||
git submodule add https://github.com/lvgl/lvgl.git components/lvgl
|
||||
```
|
||||
|
||||
The above command will clone LVGL's main repository into the `components/lvgl` directory. LVGL includes a `CMakeLists.txt` file that sets some configuration options so you can use LVGL right away.
|
||||
|
||||
__Option 2:__ IDF Component Manager
|
||||
|
||||
LVGL is also distributed through [IDF Component Manager](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-component-manager.html).
|
||||
It allows users to seamlessly integrate [LVGL component](https://components.espressif.com/component/lvgl/lvgl) into their project with following command:
|
||||
|
||||
```sh
|
||||
idf.py add-dependency lvgl/lvgl>=8.*
|
||||
```
|
||||
|
||||
During next project build, LVGL component will be fetched from the component registry and added to project build.
|
||||
|
||||
### Configuration
|
||||
|
||||
When you are ready to configure LVGL, launch the configuration menu with `idf.py menuconfig` in your project root directory, go to `Component config` and then `LVGL configuration`.
|
||||
|
||||
## Using lvgl_esp32_drivers in ESP-IDF project
|
||||
|
||||
You can also add `lvgl_esp32_drivers` as a "component". This component should be located inside a directory named "components" in your project root directory.
|
||||
|
||||
When your project is a git repository you can include `lvgl_esp32_drivers` as a git submodule:
|
||||
|
||||
```sh
|
||||
git submodule add https://github.com/lvgl/lvgl_esp32_drivers.git components/lvgl_esp32_drivers
|
||||
```
|
||||
20
LVGL.Simulator/lvgl/docs/get-started/platforms/index.md
Normal file
@@ -0,0 +1,20 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/index.md
|
||||
```
|
||||
# Platforms
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
pc-simulator
|
||||
nxp
|
||||
stm32
|
||||
espressif
|
||||
arduino
|
||||
tasmota-berry
|
||||
cmake
|
||||
```
|
||||
|
||||
71
LVGL.Simulator/lvgl/docs/get-started/platforms/nxp.md
Normal file
@@ -0,0 +1,71 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platforms/nxp.md
|
||||
```
|
||||
# NXP
|
||||
NXP has integrated LVGL into the MCUXpresso SDK packages for several of their general
|
||||
purpose and crossover microcontrollers, allowing easy evaluation and migration into your
|
||||
product design. [Download an SDK for a supported board](https://www.nxp.com/design/software/embedded-software/littlevgl-open-source-graphics-library:LITTLEVGL-OPEN-SOURCE-GRAPHICS-LIBRARY?&tid=vanLITTLEVGL-OPEN-SOURCE-GRAPHICS-LIBRARY)
|
||||
today and get started with your next GUI application.
|
||||
|
||||
## Creating new project with LVGL
|
||||
Downloading the MCU SDK example project is recommended as a starting point. It comes fully
|
||||
configured with LVGL (and with PXP support if module is present), no additional integration
|
||||
work is required.
|
||||
|
||||
## Adding HW acceleration for NXP iMX RT platforms using PXP (PiXel Pipeline) engine for existing projects
|
||||
Several drawing features in LVGL can be offloaded to the PXP engine. The CPU is available for other operations while the PXP is running. An RTOS is required to block the LVGL drawing thread and switch to another task or suspend the CPU for power savings.
|
||||
|
||||
#### Features supported:
|
||||
- RGB565 color format
|
||||
- Area fill + optional transparency
|
||||
- BLIT (BLock Image Transfer) + optional transparency
|
||||
- Color keying + optional transparency
|
||||
- Recoloring (color tint) + optional transparency
|
||||
- RTOS integration layer
|
||||
- Default FreeRTOS and bare metal code provided
|
||||
|
||||
#### Basic configuration:
|
||||
- Select NXP PXP engine in lv_conf.h: Set `LV_USE_GPU_NXP_PXP` to 1
|
||||
- Enable default implementation for interrupt handling, PXP start function and automatic initialization: Set `LV_USE_GPU_NXP_PXP_AUTO_INIT` to 1
|
||||
- If `FSL_RTOS_FREE_RTOS` symbol is defined, FreeRTOS implementation will be used, otherwise bare metal code will be included
|
||||
|
||||
#### Basic initialization:
|
||||
- If `LV_USE_GPU_NXP_PXP_AUTO_INIT` is enabled, no user code is required; PXP is initialized automatically in `lv_init()`
|
||||
- For manual PXP initialization, default configuration structure for callbacks can be used. Initialize PXP before calling `lv_init()`
|
||||
```c
|
||||
#if LV_USE_GPU_NXP_PXP
|
||||
#include "lv_gpu/lv_gpu_nxp_pxp.h"
|
||||
#include "lv_gpu/lv_gpu_nxp_pxp_osa.h"
|
||||
#endif
|
||||
. . .
|
||||
#if LV_USE_GPU_NXP_PXP
|
||||
if (lv_gpu_nxp_pxp_init(&pxp_default_cfg) != LV_RES_OK) {
|
||||
PRINTF("PXP init error. STOP.\n");
|
||||
for ( ; ; ) ;
|
||||
}
|
||||
#endif
|
||||
```
|
||||
|
||||
#### Project setup:
|
||||
- Add PXP related files to project:
|
||||
- lv_gpu/lv_gpu_nxp.c, lv_gpu/lv_gpu_nxp.h: low level drawing calls for LVGL
|
||||
- lv_gpu/lv_gpu_nxp_osa.c, lv_gpu/lv_gpu_osa.h: default implementation of OS-specific functions (bare metal and FreeRTOS only)
|
||||
- optional, required only if `LV_USE_GPU_NXP_PXP_AUTO_INIT` is set to 1
|
||||
- PXP related code depends on two drivers provided by MCU SDK. These drivers need to be added to project:
|
||||
- fsl_pxp.c, fsl_pxp.h: PXP driver
|
||||
- fsl_cache.c, fsl_cache.h: CPU cache handling functions
|
||||
|
||||
#### Advanced configuration:
|
||||
- Implementation depends on multiple OS-specific functions. The struct `lv_nxp_pxp_cfg_t` with callback pointers is used
|
||||
as a parameter for the `lv_gpu_nxp_pxp_init()` function. Default implementation for FreeRTOS and baremetal is provided in lv_gpu_nxp_osa.c
|
||||
- `pxp_interrupt_init()`: Initialize PXP interrupt (HW setup, OS setup)
|
||||
- `pxp_interrupt_deinit()`: Deinitialize PXP interrupt (HW setup, OS setup)
|
||||
- `pxp_run()`: Start PXP job. Use OS-specific mechanism to block drawing thread. PXP must finish drawing before leaving this function.
|
||||
- There are configurable area thresholds which are used to decide whether the area will be processed by CPU, or by PXP. Areas smaller than a
|
||||
defined value will be processed by CPU and those bigger than the threshold will be processed by PXP. These thresholds may be defined as
|
||||
preprocessor variables. Default values are defined lv_gpu/lv_gpu_nxp_pxp.h
|
||||
- `GPU_NXP_PXP_BLIT_SIZE_LIMIT`: size threshold for image BLIT, BLIT with color keying, and BLIT with recolor (OPA > LV_OPA_MAX)
|
||||
- `GPU_NXP_PXP_BLIT_OPA_SIZE_LIMIT`: size threshold for image BLIT and BLIT with color keying with transparency (OPA < LV_OPA_MAX)
|
||||
- `GPU_NXP_PXP_FILL_SIZE_LIMIT`: size threshold for fill operation (OPA > LV_OPA_MAX)
|
||||
- `GPU_NXP_PXP_FILL_OPA_SIZE_LIMIT`: size threshold for fill operation with transparency (OPA < LV_OPA_MAX)
|
||||
@@ -0,0 +1,98 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platoforms/simulator.md
|
||||
```
|
||||
# Simulator on PC
|
||||
|
||||
|
||||
You can try out LVGL **using only your PC** (i.e. without any development boards). LVGL will run on a simulator environment on the PC where anyone can write and experiment with real LVGL applications.
|
||||
|
||||
Using the simulator on a PC has the following advantages:
|
||||
- Hardware independent - Write code, run it on the PC and see the result on a monitor.
|
||||
- Cross-platform - Any Windows, Linux or macOS system can run the PC simulator.
|
||||
- Portability - The written code is portable, which means you can simply copy it when migrating to embedded hardware.
|
||||
- Easy Validation - The simulator is also very useful to report bugs because it provides a common platform for every user. So it's a good idea to reproduce a bug in the simulator and use that code snippet in the [Forum](https://forum.lvgl.io).
|
||||
|
||||
## Select an IDE
|
||||
|
||||
The simulator is ported to various IDEs (Integrated Development Environments). Choose your favorite IDE, read its README on GitHub, download the project, and load it to the IDE.
|
||||
|
||||
- [Eclipse with SDL driver](https://github.com/lvgl/lv_sim_eclipse_sdl): Recommended on Linux and Mac
|
||||
- [CodeBlocks](https://github.com/lvgl/lv_sim_codeblocks_win): Recommended on Windows
|
||||
- [VisualStudio with SDL driver](https://github.com/lvgl/lv_sim_visual_studio_sdl): For Windows
|
||||
- [VSCode with SDL driver](https://github.com/lvgl/lv_sim_vscode_sdl): Recommended on Linux and Mac
|
||||
- [PlatformIO with SDL driver](https://github.com/lvgl/lv_platformio): Recommended on Linux and Mac
|
||||
|
||||
You can use any IDE for development but, for simplicity, the configuration for Eclipse CDT is what we'll focus on in this tutorial.
|
||||
The following section describes the set-up guide of Eclipse CDT in more detail.
|
||||
|
||||
**Note: If you are on Windows, it's usually better to use the Visual Studio or CodeBlocks projects instead. They work out of the box without requiring extra steps.**
|
||||
|
||||
## Set-up Eclipse CDT
|
||||
|
||||
### Install Eclipse CDT
|
||||
|
||||
[Eclipse CDT](https://eclipse.org/cdt/) is a C/C++ IDE.
|
||||
|
||||
Eclipse is a Java-based tool so be sure **Java Runtime Environment** is installed on your system.
|
||||
|
||||
On Debian-based distros (e.g. Ubuntu): `sudo apt-get install default-jre`
|
||||
|
||||
Note: If you are using other distros, then please install a 'Java Runtime Environment' suitable to your distro.
|
||||
Note: If you are using macOS and get a "Failed to create the Java Virtual Machine" error, uninstall any other Java JDK installs and install Java JDK 8u. This should fix the problem.
|
||||
|
||||
You can download Eclipse's CDT from: [https://www.eclipse.org/cdt/downloads.php](https://www.eclipse.org/cdt/downloads.php). Start the installer and choose *Eclipse CDT* from the list.
|
||||
|
||||
### Install SDL 2
|
||||
|
||||
The PC simulator uses the [SDL 2](https://www.libsdl.org/download-2.0.php) cross-platform library to simulate a TFT display and a touchpad.
|
||||
|
||||
#### Linux
|
||||
On **Linux** you can easily install SDL2 using a terminal:
|
||||
|
||||
1. Find the current version of SDL2: `apt-cache search libsdl2 (e.g. libsdl2-2.0-0)`
|
||||
2. Install SDL2: `sudo apt-get install libsdl2-2.0-0` (replace with the found version)
|
||||
3. Install SDL2 development package: `sudo apt-get install libsdl2-dev`
|
||||
4. If build essentials are not installed yet: `sudo apt-get install build-essential`
|
||||
|
||||
#### Windows
|
||||
If you are using **Windows** firstly you need to install MinGW ([64 bit version](http://mingw-w64.org/doku.php/download)). After installing MinGW, do the following steps to add SDL2:
|
||||
|
||||
1. Download the development libraries of SDL.
|
||||
Go to [https://www.libsdl.org/download-2.0.php](https://www.libsdl.org/download-2.0.php) and download _Development Libraries: SDL2-devel-2.0.5-mingw.tar.gz_
|
||||
2. Decompress the file and go to _x86_64-w64-mingw32_ directory (for 64 bit MinGW) or to _i686-w64-mingw32_ (for 32 bit MinGW)
|
||||
3. Copy _..._mingw32/include/SDL2_ folder to _C:/MinGW/.../x86_64-w64-mingw32/include_
|
||||
4. Copy _..._mingw32/lib/_ content to _C:/MinGW/.../x86_64-w64-mingw32/lib_
|
||||
5. Copy _..._mingw32/bin/SDL2.dll_ to _{eclipse_workspace}/pc_simulator/Debug/_. Do it later when Eclipse is installed.
|
||||
|
||||
Note: If you are using **Microsoft Visual Studio** instead of Eclipse then you don't have to install MinGW.
|
||||
|
||||
#### OSX
|
||||
On **OSX** you can easily install SDL2 with brew: `brew install sdl2`
|
||||
|
||||
If something is not working, then please refer [this tutorial](http://lazyfoo.net/tutorials/SDL/01_hello_SDL/index.php) to get started with SDL.
|
||||
|
||||
### Pre-configured project
|
||||
|
||||
A pre-configured graphics library project (based on the latest release) is always available to get started easily.
|
||||
You can find the latest one on [GitHub](https://github.com/lvgl/lv_sim_eclipse_sdl).
|
||||
(Please note that, the project is configured for Eclipse CDT).
|
||||
|
||||
### Add the pre-configured project to Eclipse CDT
|
||||
|
||||
Run Eclipse CDT. It will show a dialogue about the **workspace path**. Before accepting the path, check that path and copy (and unzip) the downloaded pre-configured project there. After that, you can accept the workspace path. Of course you can modify this path but in that case copy the project to the corresponding location.
|
||||
|
||||
Close the start-up window and go to **File->Import** and choose **General->Existing project into Workspace**. **Browse the root directory** of the project and click **Finish**
|
||||
|
||||
On **Windows** you have to do two additional things:
|
||||
|
||||
- Copy the **SDL2.dll** into the project's Debug folder
|
||||
- Right-click on the project -> Project properties -> C/C++ Build -> Settings -> Libraries -> Add ... and add _mingw32_ above SDLmain and SDL. (The order is important: mingw32, SDLmain, SDL)
|
||||
|
||||
### Compile and Run
|
||||
|
||||
Now you are ready to run LVGL on your PC. Click on the Hammer Icon on the top menu bar to Build the project. If you have done everything right, then you will not get any errors. Note that on some systems additional steps might be required to "see" SDL 2 from Eclipse but in most cases the configuration in the downloaded project is enough.
|
||||
|
||||
After a successful build, click on the Play button on the top menu bar to run the project. Now a window should appear in the middle of your screen.
|
||||
|
||||
Now you are ready to use LVGL and begin development on your PC.
|
||||
8
LVGL.Simulator/lvgl/docs/get-started/platforms/stm32.md
Normal file
@@ -0,0 +1,8 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platforms/stm32.md
|
||||
```
|
||||
|
||||
# STM32
|
||||
|
||||
TODO
|
||||
@@ -0,0 +1,77 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/platforms/tasmota-berry.md
|
||||
```
|
||||
# Tasmota and berry
|
||||
|
||||
## What is Tasmota?
|
||||
|
||||
[Tasmota](https://github.com/arendst/Tasmota) is a widely used open-source firmware for ESP8266 and EPS32 based devices. It supports a wide variety of devices, sensors and integrations to Home Automation and Cloud services. Tasmota firmware is downloaded more than 200,000 times each month, and has an active and growing community.
|
||||
|
||||
Tasmota provides access to hundreds of supported devices, full support of MQTT, HTTP(S), integration with major Home Automation systems, myriad of sensors, IR, RF, Zigbee, Bluetooth, AWS IoT, Azure IoT, Alexa and many more.
|
||||
|
||||
## What is Berry?
|
||||
|
||||
[Berry](https://github.com/berry-lang/berry) is a ultra-lightweight dynamically typed embedded scripting language. It is designed for lower-performance embedded devices. The interpreter of Berry include a one-pass compiler and register-based VM, all the code is written in ANSI C99. Berry offers a syntax very similar to Python, and is inspired from LUA VM. It is fully integrated in Tasmota
|
||||
|
||||
### Highlights of Berry
|
||||
|
||||
Berry has the following advantages:
|
||||
|
||||
- Lightweight: A well-optimized interpreter with very little resources. Ideal for use in microprocessors.
|
||||
- Fast: optimized one-pass bytecode compiler and register-based virtual machine.
|
||||
- Powerful: supports imperative programming, object-oriented programming, functional programming.
|
||||
- Flexible: Berry is a dynamic type script, and it's intended for embedding in applications. It can provide good dynamic scalability for the host system.
|
||||
- Simple: simple and natural syntax, support garbage collection, and easy to use FFI (foreign function interface).
|
||||
- RAM saving: With compile-time object construction, most of the constant objects are stored in read-only code data segments, so the RAM usage of the interpreter is very low when it starts.
|
||||
|
||||
All features are detailed in the [Berry Reference Manual](https://github.com/berry-lang/berry/wiki/Reference)
|
||||
|
||||
---
|
||||
|
||||
## Why LVGL + Tasmota + Berry?
|
||||
|
||||
In 2021, Tasmota added full support of LVGL for ESP32 based devices. It also introduced the Berry scripting language, a small-footprint language similar to Python and fully integrated in Tasmota.
|
||||
|
||||
A comprehensive mapping of LVGL in Berry language is now available, similar to the mapping of Micropython. It allows to use +98% of all LVGL features. It is also possible to write custom widgets in Berry.
|
||||
|
||||
Versions supported: LVGL v8.0.2, LodePNG v20201017, Freetype 2.10.4
|
||||
|
||||
### Tasmota + Berry + LVGL could be used for:
|
||||
|
||||
- Fast prototyping GUI.
|
||||
- Shortening the cycle of changing and fine-tuning the GUI.
|
||||
- Modelling the GUI in a more abstract way by defining reusable composite objects, taking advantage of Berry's language features such as Inheritance, Closures, Exception Handling...
|
||||
- Make LVGL accessible to a larger audience. No need to know C to create a nice GUI on an embedded system.
|
||||
|
||||
A higher level interface compatible with [OpenHASP](https://github.com/HASwitchPlate/openHASP) is also under development.
|
||||
|
||||
---
|
||||
|
||||
## So what does it look like?
|
||||
|
||||
> TL;DR:
|
||||
> Similar to MicroPython, it's very much like the C API, but Object-Oriented for LVGL components.
|
||||
|
||||
Let's dive right into an example!
|
||||
|
||||
### A simple example
|
||||
|
||||
```python
|
||||
lv.start() # start LVGL
|
||||
scr = lv.scr_act() # get default screen
|
||||
btn = lv.btn(scr) # create button
|
||||
btn.center()
|
||||
label = lv.label(btn) # create a label in the button
|
||||
label.set_text("Button") # set a label to the button
|
||||
```
|
||||
|
||||
## How can I use it?
|
||||
|
||||
You can start in less than 10 minutes on a M5Stack or equivalent device in less than 10 minutes in this [short tutorial](https://tasmota.github.io/docs/LVGL_in_10_minutes/)
|
||||
|
||||
## Where can I find more information?
|
||||
|
||||
- [Tasmota Documentation](https://tasmota.github.io/docs/)
|
||||
- [Berry Documentation](https://github.com/berry-lang/berry/wiki/Reference)
|
||||
- [Tasmota LVGL Berry documentation](https://tasmota.github.io/docs/LVGL/)
|
||||
270
LVGL.Simulator/lvgl/docs/get-started/quick-overview.md
Normal file
@@ -0,0 +1,270 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/get-started/quick-overview.md
|
||||
```
|
||||
|
||||
# Quick overview
|
||||
|
||||
Here you can learn the most important things about LVGL.
|
||||
You should read this first to get a general impression and read the detailed [Porting](/porting/index) and [Overview](/overview/index) sections after that.
|
||||
|
||||
## Get started in a simulator
|
||||
|
||||
Instead of porting LVGL to embedded hardware straight away, it's highly recommended to get started in a simulator first.
|
||||
|
||||
LVGL is ported to many IDEs to be sure you will find your favorite one.
|
||||
Go to the [Simulators](/get-started/pc-simulator) section to get ready-to-use projects that can be run on your PC.
|
||||
This way you can save the time of porting for now and get some experience with LVGL immediately.
|
||||
|
||||
## Add LVGL into your project
|
||||
If you would rather try LVGL on your own project follow these steps:
|
||||
|
||||
- [Download](https://github.com/lvgl/lvgl/archive/master.zip) or clone the library from GitHub with `git clone https://github.com/lvgl/lvgl.git`.
|
||||
- Copy the `lvgl` folder into your project.
|
||||
- Copy `lvgl/lv_conf_template.h` as `lv_conf.h` next to the `lvgl` folder, change the first `#if 0` to `1` to enable the file's content and set the `LV_COLOR_DEPTH` defines.
|
||||
- Include `lvgl/lvgl.h` in files where you need to use LVGL related functions.
|
||||
- Call `lv_tick_inc(x)` every `x` milliseconds in a Timer or Task (`x` should be between 1 and 10). It is required for the internal timing of LVGL.
|
||||
Alternatively, configure `LV_TICK_CUSTOM` (see `lv_conf.h`) so that LVGL can retrieve the current time directly.
|
||||
- Call `lv_init()`
|
||||
- Create a draw buffer: LVGL will render the graphics here first, and send the rendered image to the display.
|
||||
The buffer size can be set freely but 1/10 screen size is a good starting point.
|
||||
```c
|
||||
static lv_disp_draw_buf_t draw_buf;
|
||||
static lv_color_t buf1[DISP_HOR_RES * DISP_VER_RES / 10]; /*Declare a buffer for 1/10 screen size*/
|
||||
lv_disp_draw_buf_init(&draw_buf, buf1, NULL, MY_DISP_HOR_RES * MY_DISP_VER_SER / 10); /*Initialize the display buffer.*/
|
||||
```
|
||||
- Implement and register a function which can copy the rendered image to an area of your display:
|
||||
```c
|
||||
static lv_disp_drv_t disp_drv; /*Descriptor of a display driver*/
|
||||
lv_disp_drv_init(&disp_drv); /*Basic initialization*/
|
||||
disp_drv.flush_cb = my_disp_flush; /*Set your driver function*/
|
||||
disp_drv.draw_buf = &draw_buf; /*Assign the buffer to the display*/
|
||||
disp_drv.hor_res = MY_DISP_HOR_RES; /*Set the horizontal resolution of the display*/
|
||||
disp_drv.ver_res = MY_DISP_VER_RES; /*Set the vertical resolution of the display*/
|
||||
lv_disp_drv_register(&disp_drv); /*Finally register the driver*/
|
||||
|
||||
void my_disp_flush(lv_disp_drv_t * disp, const lv_area_t * area, lv_color_t * color_p)
|
||||
{
|
||||
int32_t x, y;
|
||||
/*It's a very slow but simple implementation.
|
||||
*`set_pixel` needs to be written by you to a set pixel on the screen*/
|
||||
for(y = area->y1; y <= area->y2; y++) {
|
||||
for(x = area->x1; x <= area->x2; x++) {
|
||||
set_pixel(x, y, *color_p);
|
||||
color_p++;
|
||||
}
|
||||
}
|
||||
|
||||
lv_disp_flush_ready(disp); /* Indicate you are ready with the flushing*/
|
||||
}
|
||||
|
||||
```
|
||||
- Implement and register a function which can read an input device. E.g. for a touchpad:
|
||||
```c
|
||||
static lv_indev_drv_t indev_drv; /*Descriptor of a input device driver*/
|
||||
lv_indev_drv_init(&indev_drv); /*Basic initialization*/
|
||||
indev_drv.type = LV_INDEV_TYPE_POINTER; /*Touch pad is a pointer-like device*/
|
||||
indev_drv.read_cb = my_touchpad_read; /*Set your driver function*/
|
||||
lv_indev_drv_register(&indev_drv); /*Finally register the driver*/
|
||||
|
||||
void my_touchpad_read(lv_indev_t * indev, lv_indev_data_t * data)
|
||||
{
|
||||
/*`touchpad_is_pressed` and `touchpad_get_xy` needs to be implemented by you*/
|
||||
if(touchpad_is_pressed()) {
|
||||
data->state = LV_INDEV_STATE_PRESSED;
|
||||
touchpad_get_xy(&data->point.x, &data->point.y);
|
||||
} else {
|
||||
data->state = LV_INDEV_STATE_RELEASED;
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
- Call `lv_timer_handler()` periodically every few milliseconds in the main `while(1)` loop or in an operating system task.
|
||||
It will redraw the screen if required, handle input devices, animation etc.
|
||||
|
||||
For a more detailed guide go to the [Porting](/porting/index) section.
|
||||
|
||||
## Learn the basics
|
||||
|
||||
### Widgets
|
||||
|
||||
The graphical elements like Buttons, Labels, Sliders, Charts etc. are called objects or widgets. Go to [Widgets](/widgets/index) to see the full list of available widgets.
|
||||
|
||||
Every object has a parent object where it is created. For example, if a label is created on a button, the button is the parent of label.
|
||||
|
||||
The child object moves with the parent and if the parent is deleted the children will be deleted too.
|
||||
|
||||
Children can be visible only within their parent's bounding area. In other words, the parts of the children outside the parent are clipped.
|
||||
|
||||
A Screen is the "root" parent. You can have any number of screens.
|
||||
|
||||
To get the current screen call `lv_scr_act()`, and to load a screen use `lv_scr_load(scr1)`.
|
||||
|
||||
You can create a new object with `lv_<type>_create(parent)`. It will return an `lv_obj_t *` variable that can be used as a reference to the object to set its parameters.
|
||||
|
||||
For example:
|
||||
```c
|
||||
lv_obj_t * slider1 = lv_slider_create(lv_scr_act());
|
||||
```
|
||||
|
||||
To set some basic attributes `lv_obj_set_<parameter_name>(obj, <value>)` functions can be used. For example:
|
||||
```c
|
||||
lv_obj_set_x(btn1, 30);
|
||||
lv_obj_set_y(btn1, 10);
|
||||
lv_obj_set_size(btn1, 200, 50);
|
||||
```
|
||||
|
||||
Along with the basic attributes, widgets can have type specific parameters which are set by `lv_<widget_type>_set_<parameter_name>(obj, <value>)` functions. For example:
|
||||
```c
|
||||
lv_slider_set_value(slider1, 70, LV_ANIM_ON);
|
||||
```
|
||||
|
||||
To see the full API visit the documentation of the widgets or the related header file (e.g. [lvgl/src/widgets/lv_slider.h](https://github.com/lvgl/lvgl/blob/master/src/widgets/lv_slider.h)).
|
||||
|
||||
|
||||
|
||||
### Events
|
||||
Events are used to inform the user that something has happened with an object.
|
||||
You can assign one or more callbacks to an object which will be called if the object is clicked, released, dragged, being deleted, etc.
|
||||
|
||||
A callback is assigned like this:
|
||||
|
||||
```c
|
||||
lv_obj_add_event_cb(btn, btn_event_cb, LV_EVENT_CLICKED, NULL); /*Assign a callback to the button*/
|
||||
|
||||
...
|
||||
|
||||
void btn_event_cb(lv_event_t * e)
|
||||
{
|
||||
printf("Clicked\n");
|
||||
}
|
||||
```
|
||||
|
||||
`LV_EVENT_ALL` can be used instead of `LV_EVENT_CLICKED` to invoke the callback for any event.
|
||||
|
||||
From `lv_event_t * e` the current event code can be retrieved with:
|
||||
```c
|
||||
lv_event_code_t code = lv_event_get_code(e);
|
||||
```
|
||||
|
||||
The object that triggered the event can be retrieved with:
|
||||
```c
|
||||
lv_obj_t * obj = lv_event_get_target(e);
|
||||
```
|
||||
|
||||
To learn all features of the events go to the [Event overview](/overview/event) section.
|
||||
|
||||
### Parts
|
||||
Widgets might be built from one or more *parts*. For example, a button has only one part called `LV_PART_MAIN`.
|
||||
However, a [Slider](/widgets/core/slider) has `LV_PART_MAIN`, `LV_PART_INDICATOR` and `LV_PART_KNOB`.
|
||||
|
||||
By using parts you can apply different styles to sub-elements of a widget. (See below)
|
||||
|
||||
Read the widgets' documentation to learn which parts each uses.
|
||||
|
||||
### States
|
||||
LVGL objects can be in a combination of the following states:
|
||||
- `LV_STATE_DEFAULT` Normal, released state
|
||||
- `LV_STATE_CHECKED` Toggled or checked state
|
||||
- `LV_STATE_FOCUSED` Focused via keypad or encoder or clicked via touchpad/mouse
|
||||
- `LV_STATE_FOCUS_KEY` Focused via keypad or encoder but not via touchpad/mouse
|
||||
- `LV_STATE_EDITED` Edit by an encoder
|
||||
- `LV_STATE_HOVERED` Hovered by mouse (not supported now)
|
||||
- `LV_STATE_PRESSED` Being pressed
|
||||
- `LV_STATE_SCROLLED` Being scrolled
|
||||
- `LV_STATE_DISABLED` Disabled
|
||||
|
||||
For example, if you press an object it will automatically go to the `LV_STATE_FOCUSED` and `LV_STATE_PRESSED` states and when you release it the `LV_STATE_PRESSED` state will be removed while focus remains active.
|
||||
|
||||
To check if an object is in a given state use `lv_obj_has_state(obj, LV_STATE_...)`. It will return `true` if the object is currently in that state.
|
||||
|
||||
To manually add or remove states use:
|
||||
```c
|
||||
lv_obj_add_state(obj, LV_STATE_...);
|
||||
lv_obj_clear_state(obj, LV_STATE_...);
|
||||
```
|
||||
|
||||
### Styles
|
||||
A style instance contains properties such as background color, border width, font, etc. that describe the appearance of objects.
|
||||
|
||||
Styles are represented with `lv_style_t` variables. Only their pointer is saved in the objects so they need to be defined as static or global.
|
||||
Before using a style it needs to be initialized with `lv_style_init(&style1)`. After that, properties can be added to configure the style. For example:
|
||||
```
|
||||
static lv_style_t style1;
|
||||
lv_style_init(&style1);
|
||||
lv_style_set_bg_color(&style1, lv_color_hex(0xa03080))
|
||||
lv_style_set_border_width(&style1, 2))
|
||||
```
|
||||
See the full list of properties [here](/overview/style.html#properties).
|
||||
|
||||
|
||||
Styles are assigned using the ORed combination of an object's part and state. For example to use this style on the slider's indicator when the slider is pressed:
|
||||
```c
|
||||
lv_obj_add_style(slider1, &style1, LV_PART_INDICATOR | LV_STATE_PRESSED);
|
||||
```
|
||||
|
||||
If the *part* is `LV_PART_MAIN` it can be omitted:
|
||||
```c
|
||||
lv_obj_add_style(btn1, &style1, LV_STATE_PRESSED); /*Equal to LV_PART_MAIN | LV_STATE_PRESSED*/
|
||||
```
|
||||
|
||||
Similarly, `LV_STATE_DEFAULT` can be omitted too:
|
||||
```c
|
||||
lv_obj_add_style(slider1, &style1, LV_PART_INDICATOR); /*Equal to LV_PART_INDICATOR | LV_STATE_DEFAULT*/
|
||||
```
|
||||
|
||||
For `LV_STATE_DEFAULT` and `LV_PART_MAIN` simply write `0`:
|
||||
```c
|
||||
lv_obj_add_style(btn1, &style1, 0); /*Equal to LV_PART_MAIN | LV_STATE_DEFAULT*/
|
||||
```
|
||||
|
||||
|
||||
Styles can be cascaded (similarly to CSS). It means you can add more styles to a part of an object.
|
||||
For example `style_btn` can set a default button appearance, and `style_btn_red` can overwrite the background color to make the button red:
|
||||
```c
|
||||
lv_obj_add_style(btn1, &style_btn, 0);
|
||||
lv_obj_add_style(btn1, &style1_btn_red, 0);
|
||||
```
|
||||
|
||||
|
||||
If a property is not set on for the current state, the style with `LV_STATE_DEFAULT` will be used. A default value is used if the property is not defined in the default state.
|
||||
|
||||
Some properties (typically the text-related ones) can be inherited. This means if a property is not set in an object it will be searched for in its parents too.
|
||||
For example, you can set the font once in the screen's style and all text on that screen will inherit it by default.
|
||||
|
||||
|
||||
Local style properties also can be added to objects. This creates a style which resides inside the object and is used only by the object:
|
||||
```c
|
||||
lv_obj_set_style_bg_color(slider1, lv_color_hex(0x2080bb), LV_PART_INDICATOR | LV_STATE_PRESSED);
|
||||
```
|
||||
|
||||
To learn all the features of styles see the [Style overview](/overview/style) section.
|
||||
|
||||
|
||||
### Themes
|
||||
|
||||
Themes are the default styles for objects. Styles from a theme are applied automatically when objects are created.
|
||||
|
||||
The theme for your application is a compile time configuration set in `lv_conf.h`.
|
||||
|
||||
## Examples
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/get_started/index.rst
|
||||
```
|
||||
|
||||
## Micropython
|
||||
Learn more about [Micropython](/get-started/micropython).
|
||||
```python
|
||||
# Create a Button and a Label
|
||||
scr = lv.obj()
|
||||
btn = lv.btn(scr)
|
||||
btn.align(lv.scr_act(), lv.ALIGN.CENTER, 0, 0)
|
||||
label = lv.label(btn)
|
||||
label.set_text("Button")
|
||||
|
||||
# Load the screen
|
||||
lv.scr_load(scr)
|
||||
```
|
||||
|
||||
1
LVGL.Simulator/lvgl/docs/header.rst
Normal file
@@ -0,0 +1 @@
|
||||
.. |github_link_base| replace:: https://github.com/lvgl/lvgl/blob/8a8153219163b689e8f96d6a97c1f128eefd7ce2/docs
|
||||
42
LVGL.Simulator/lvgl/docs/index.md
Normal file
@@ -0,0 +1,42 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/index.md
|
||||
```
|
||||
|
||||
```eval_rst
|
||||
|
||||
PDF version: :download:`LVGL.pdf <LVGL.pdf>`
|
||||
```
|
||||
|
||||
# Welcome to the documentation of LVGL!
|
||||
|
||||
<img src="_static/img/home_banner.jpg" style="width:100%">
|
||||
|
||||
|
||||
<div style="margin-bottom:48px">
|
||||
<a href="intro/index.html"><img class="home-img" src="_static/img/home_1.png" alt="Get familiar with the LVGL project"></a>
|
||||
<a href="get-started/index.html"><img class="home-img" src="_static/img/home_2.png" alt="Learn the basic of LVGL and its usage on various platforms"></a>
|
||||
<a href="porting/index.html"><img class="home-img" src="_static/img/home_3.png" alt="See how to port LVGL to any platform"></a>
|
||||
<a href="overview/index.html"><img class="home-img" src="_static/img/home_4.png" alt="Learn the how LVGL works in more detail"></a>
|
||||
<a href="widgets/index.html"><img class="home-img" src="_static/img/home_5.png" alt="Take a look at the description of the available widgets"></a>
|
||||
<a href="CONTRIBUTING.html"><img class="home-img" src="_static/img/home_6.png" alt="Be part of the development of LVGL"></a>
|
||||
</div>
|
||||
|
||||
|
||||
```eval_rst
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
intro/index
|
||||
examples
|
||||
get-started/index
|
||||
porting/index
|
||||
overview/index
|
||||
widgets/index
|
||||
layouts/index
|
||||
libs/index
|
||||
others/index
|
||||
CONTRIBUTING
|
||||
CHANGELOG
|
||||
ROADMAP
|
||||
```
|
||||
219
LVGL.Simulator/lvgl/docs/intro/index.md
Normal file
@@ -0,0 +1,219 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/intro/index.md
|
||||
```
|
||||
|
||||
# Introduction
|
||||
|
||||
LVGL (Light and Versatile Graphics Library) is a free and open-source graphics library providing everything you need to create an embedded GUI with easy-to-use graphical elements, beautiful visual effects and a low memory footprint.
|
||||
|
||||
|
||||
## Key features
|
||||
- Powerful building blocks such as buttons, charts, lists, sliders, images, etc.
|
||||
- Advanced graphics with animations, anti-aliasing, opacity, smooth scrolling
|
||||
- Various input devices such as touchpad, mouse, keyboard, encoder, etc.
|
||||
- Multi-language support with UTF-8 encoding
|
||||
- Multi-display support, i.e. use multiple TFT, monochrome displays simultaneously
|
||||
- Fully customizable graphic elements with CSS-like styles
|
||||
- Hardware independent: use with any microcontroller or display
|
||||
- Scalable: able to operate with little memory (64 kB Flash, 16 kB RAM)
|
||||
- OS, external memory and GPU are supported but not required
|
||||
- Single frame buffer operation even with advanced graphic effects
|
||||
- Written in C for maximal compatibility (C++ compatible)
|
||||
- Simulator to start embedded GUI design on a PC without embedded hardware
|
||||
- Binding to MicroPython
|
||||
- Tutorials, examples, themes for rapid GUI design
|
||||
- Documentation is available online and as PDF
|
||||
- Free and open-source under MIT license
|
||||
|
||||
## Requirements
|
||||
Basically, every modern controller which is able to drive a display is suitable to run LVGL. The minimal requirements are:
|
||||
<ul>
|
||||
<li> 16, 32 or 64 bit microcontroller or processor</li>
|
||||
<li>> 16 MHz clock speed is recommended</li>
|
||||
<li> Flash/ROM: > 64 kB for the very essential components (> 180 kB is recommended)</li>
|
||||
<li> RAM:
|
||||
<ul>
|
||||
<li> Static RAM usage: ~2 kB depending on the used features and object types</li>
|
||||
<li> Stack: > 2kB (> 8 kB is recommended)</li>
|
||||
<li> Dynamic data (heap): > 4 KB (> 32 kB is recommended if using several objects).
|
||||
Set by <em>LV_MEM_SIZE</em> in <em>lv_conf.h</em>. </li>
|
||||
<li> Display buffer: > <em>"Horizontal resolution"</em> pixels (> 10 × <em>"Horizontal resolution"</em> is recommended) </li>
|
||||
<li> One frame buffer in the MCU or in an external display controller</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li> C99 or newer compiler</li>
|
||||
<li> Basic C (or C++) knowledge:
|
||||
<a href="https://www.tutorialspoint.com/cprogramming/c_pointers.htm">pointers</a>,
|
||||
<a href="https://www.tutorialspoint.com/cprogramming/c_structures.htm">structs</a>,
|
||||
<a href="https://www.geeksforgeeks.org/callbacks-in-c/">callbacks</a>.</li>
|
||||
</ul>
|
||||
<em>Note that memory usage may vary depending on architecture, compiler and build options.</em>
|
||||
|
||||
## License
|
||||
The LVGL project (including all repositories) is licensed under [MIT license](https://github.com/lvgl/lvgl/blob/master/LICENCE.txt).
|
||||
This means you can use it even in commercial projects.
|
||||
|
||||
It's not mandatory, but we highly appreciate it if you write a few words about your project in the [My projects](https://forum.lvgl.io/c/my-projects/10) category of the forum or a private message to [lvgl.io](https://lvgl.io/#contact).
|
||||
|
||||
Although you can get LVGL for free there is a massive amount of work behind it. It's created by a group of volunteers who made it available for you in their free time.
|
||||
|
||||
To make the LVGL project sustainable, please consider [contributing](/CONTRIBUTING) to the project.
|
||||
You can choose from [many different ways of contributing](/CONTRIBUTING) such as simply writing a tweet about you using LVGL, fixing bugs, translating the documentation, or even becoming a maintainer.
|
||||
|
||||
## Repository layout
|
||||
All repositories of the LVGL project are hosted on GitHub: https://github.com/lvgl
|
||||
|
||||
You will find these repositories there:
|
||||
- [lvgl](https://github.com/lvgl/lvgl) The library itself with many [examples](https://github.com/lvgl/lvgl/blob/master/examples/) and [demos](https://github.com/lvgl/lvgl/blob/master/demos/).
|
||||
- [lv_drivers](https://github.com/lvgl/lv_drivers) Display and input device drivers
|
||||
- [blog](https://github.com/lvgl/blog) Source of the blog's site (https://blog.lvgl.io)
|
||||
- [sim](https://github.com/lvgl/sim) Source of the online simulator's site (https://sim.lvgl.io)
|
||||
- [lv_port_...](https://github.com/lvgl?q=lv_port&type=&language=) LVGL ports to development boards or environments
|
||||
- [lv_binding_..](https://github.com/lvgl?q=lv_binding&type=&language=l) Bindings to other languages
|
||||
|
||||
## Release policy
|
||||
|
||||
The core repositories follow the rules of [Semantic versioning](https://semver.org/):
|
||||
- Major versions for incompatible API changes. E.g. v5.0.0, v6.0.0
|
||||
- Minor version for new but backward-compatible functionalities. E.g. v6.1.0, v6.2.0
|
||||
- Patch version for backward-compatible bug fixes. E.g. v6.1.1, v6.1.2
|
||||
|
||||
Tags like `vX.Y.Z` are created for every release.
|
||||
|
||||
### Release cycle
|
||||
- Bug fixes: Released on demand even weekly
|
||||
- Minor releases: Every 3-4 months
|
||||
- Major releases: Approximately yearly
|
||||
|
||||
### Branches
|
||||
The core repositories have at least the following branches:
|
||||
- `master` latest version, patches are merged directly here.
|
||||
- `release/vX.Y` stable versions of the minor releases
|
||||
- `fix/some-description` temporary branches for bug fixes
|
||||
- `feat/some-description` temporary branches for features
|
||||
|
||||
|
||||
### Changelog
|
||||
|
||||
The changes are recorded in [CHANGELOG.md](/CHANGELOG).
|
||||
|
||||
### Version support
|
||||
Before v8 the last minor release of each major series was supported for 1 year.
|
||||
Starting from v8, every minor release is supported for 1 year.
|
||||
|
||||
| Version | Release date | Support end | Active |
|
||||
|---------|--------------|-------------|--------|
|
||||
| v5.3 | Feb 1, 2019 |Feb 1, 2020 | No |
|
||||
| v6.1 | Nov 26, 2019 |Nov 26, 2020 | No |
|
||||
| v7.11 | Mar 16, 2021 |Mar 16, 2022 | No |
|
||||
| v8.0 | 1 Jun, 2021 |1 Jun, 2022 | Yes |
|
||||
| v8.1 | 10 Nov, 2021 |10 Nov, 2022 | Yes |
|
||||
| v8.2 | In progress | | |
|
||||
|
||||
|
||||
## FAQ
|
||||
|
||||
### Where can I ask questions?
|
||||
You can ask questions in the forum: [https://forum.lvgl.io/](https://forum.lvgl.io/).
|
||||
|
||||
We use [GitHub issues](https://github.com/lvgl/lvgl/issues) for development related discussion.
|
||||
You should use them only if your question or issue is tightly related to the development of the library.
|
||||
|
||||
Before posting a question, please ready this FAQ section as you might find answer to your issue here too.
|
||||
|
||||
### Is my MCU/hardware supported?
|
||||
Every MCU which is capable of driving a display via parallel port, SPI, RGB interface or anything else and fulfills the [Requirements](#requirements) is supported by LVGL.
|
||||
|
||||
This includes:
|
||||
- "Common" MCUs like STM32F, STM32H, NXP Kinetis, LPC, iMX, dsPIC33, PIC32 etc.
|
||||
- Bluetooth, GSM, Wi-Fi modules like Nordic NRF and Espressif ESP32
|
||||
- Linux with frame buffer device such as /dev/fb0. This includes Single-board computers like the Raspberry Pi
|
||||
- Anything else with a strong enough MCU and a peripheral to drive a display
|
||||
|
||||
### Is my display supported?
|
||||
LVGL needs just one simple driver function to copy an array of pixels into a given area of the display.
|
||||
If you can do this with your display then you can use it with LVGL.
|
||||
|
||||
Some examples of the supported display types:
|
||||
- TFTs with 16 or 24 bit color depth
|
||||
- Monitors with an HDMI port
|
||||
- Small monochrome displays
|
||||
- Gray-scale displays
|
||||
- even LED matrices
|
||||
- or any other display where you can control the color/state of the pixels
|
||||
|
||||
See the [Porting](/porting/display) section to learn more.
|
||||
|
||||
### LVGL doesn't start, randomly crashes or nothing is drawn on the display. What can be the problem?
|
||||
- Try increasing `LV_MEM_SIZE`.
|
||||
- Be sure `lv_disp_drv_t`, `lv_indev_drv_t` and `lv_fs_drv_t` are global or `static`.
|
||||
- Be sure your display works without LVGL. E.g. paint it to red on start up.
|
||||
- Enable [Logging](porting/log)
|
||||
- Enable asserts in `lv_conf.h` (`LV_USE_ASSERT_...`)
|
||||
- If you use an RTOS
|
||||
- increase the stack size of the task which calls `lv_timer_handler()`
|
||||
- Be sure you used a mutex as [described here](/porting/os)
|
||||
|
||||
### My display driver is not called. What have I missed?
|
||||
Be sure you are calling `lv_tick_inc(x)` in an interrupt and `lv_timer_handler()` in your main `while(1)`.
|
||||
|
||||
Learn more in the [Tick](/porting/tick) and [Timer handler](/porting/timer-handler) sections.
|
||||
|
||||
### Why is the display driver called only once? Only the upper part of the display is refreshed.
|
||||
Be sure you are calling `lv_disp_flush_ready(drv)` at the end of your "*display flush callback*".
|
||||
|
||||
### Why do I see only garbage on the screen?
|
||||
Probably there a bug in your display driver. Try the following code without using LVGL. You should see a square with red-blue gradient.
|
||||
|
||||
```c
|
||||
#define BUF_W 20
|
||||
#define BUF_H 10
|
||||
|
||||
lv_color_t buf[BUF_W * BUF_H];
|
||||
lv_color_t * buf_p = buf;
|
||||
uint16_t x, y;
|
||||
for(y = 0; y < BUF_H; y++) {
|
||||
lv_color_t c = lv_color_mix(LV_COLOR_BLUE, LV_COLOR_RED, (y * 255) / BUF_H);
|
||||
for(x = 0; x < BUF_W; x++){
|
||||
(*buf_p) = c;
|
||||
buf_p++;
|
||||
}
|
||||
}
|
||||
|
||||
lv_area_t a;
|
||||
a.x1 = 10;
|
||||
a.y1 = 40;
|
||||
a.x2 = a.x1 + BUF_W - 1;
|
||||
a.y2 = a.y1 + BUF_H - 1;
|
||||
my_flush_cb(NULL, &a, buf);
|
||||
```
|
||||
|
||||
### Why do I see nonsense colors on the screen?
|
||||
Probably LVGL's color format is not compatible with your display's color format. Check `LV_COLOR_DEPTH` in *lv_conf.h*.
|
||||
|
||||
If you are using 16-bit colors with SPI (or another byte-oriented interface) you probably need to set `LV_COLOR_16_SWAP 1` in *lv_conf.h*.
|
||||
It swaps the upper and lower bytes of the pixels.
|
||||
|
||||
### How to speed up my UI?
|
||||
- Turn on compiler optimization and enable cache if your MCU has it
|
||||
- Increase the size of the display buffer
|
||||
- Use two display buffers and flush the buffer with DMA (or similar peripheral) in the background
|
||||
- Increase the clock speed of the SPI or parallel port if you use them to drive the display
|
||||
- If your display has an SPI port consider changing to a model with a parallel interface because it has much higher throughput
|
||||
- Keep the display buffer in internal RAM (not in external SRAM) because LVGL uses it a lot and it should have a fast access time
|
||||
|
||||
### How to reduce flash/ROM usage?
|
||||
You can disable all the unused features (such as animations, file system, GPU etc.) and object types in *lv_conf.h*.
|
||||
|
||||
If you are using GCC you can add `-fdata-sections -ffunction-sections` compiler flags and `--gc-sections` linker flag to remove unused functions and variables from the final binary.
|
||||
|
||||
### How to reduce the RAM usage
|
||||
- Lower the size of the *Display buffer*
|
||||
- Reduce `LV_MEM_SIZE` in *lv_conf.h*. This memory is used when you create objects like buttons, labels, etc.
|
||||
- To work with lower `LV_MEM_SIZE` you can create objects only when required and delete them when they are not needed anymore
|
||||
|
||||
### How to work with an operating system?
|
||||
|
||||
To work with an operating system where tasks can interrupt each other (preemptively) you should protect LVGL related function calls with a mutex.
|
||||
See the [Operating system and interrupts](/porting/os) section to learn more.
|
||||
123
LVGL.Simulator/lvgl/docs/layouts/flex.md
Normal file
@@ -0,0 +1,123 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/layouts/flex.md
|
||||
```
|
||||
|
||||
# Flex
|
||||
|
||||
## Overview
|
||||
|
||||
The Flexbox (or Flex for short) is a subset of [CSS Flexbox](https://css-tricks.com/snippets/css/a-guide-to-flexbox/).
|
||||
|
||||
It can arrange items into rows or columns (tracks), handle wrapping, adjust the spacing between the items and tracks, handle *grow* to make the item(s) fill the remaining space with respect to min/max width and height.
|
||||
|
||||
To make an object flex container call `lv_obj_set_layout(obj, LV_LAYOUT_FLEX)`.
|
||||
|
||||
Note that the flex layout feature of LVGL needs to be globally enabled with `LV_USE_FLEX` in `lv_conf.h`.
|
||||
|
||||
## Terms
|
||||
- tracks: the rows or columns
|
||||
- main direction: row or column, the direction in which the items are placed
|
||||
- cross direction: perpendicular to the main direction
|
||||
- wrap: if there is no more space in the track a new track is started
|
||||
- grow: if set on an item it will grow to fill the remaining space on the track.
|
||||
The available space will be distributed among items respective to their grow value (larger value means more space)
|
||||
- gap: the space between the rows and columns or the items on a track
|
||||
|
||||
## Simple interface
|
||||
|
||||
With the following functions you can set a Flex layout on any parent.
|
||||
|
||||
### Flex flow
|
||||
|
||||
`lv_obj_set_flex_flow(obj, flex_flow)`
|
||||
|
||||
The possible values for `flex_flow` are:
|
||||
- `LV_FLEX_FLOW_ROW` Place the children in a row without wrapping
|
||||
- `LV_FLEX_FLOW_COLUMN` Place the children in a column without wrapping
|
||||
- `LV_FLEX_FLOW_ROW_WRAP` Place the children in a row with wrapping
|
||||
- `LV_FLEX_FLOW_COLUMN_WRAP` Place the children in a column with wrapping
|
||||
- `LV_FLEX_FLOW_ROW_REVERSE` Place the children in a row without wrapping but in reversed order
|
||||
- `LV_FLEX_FLOW_COLUMN_REVERSE` Place the children in a column without wrapping but in reversed order
|
||||
- `LV_FLEX_FLOW_ROW_WRAP_REVERSE` Place the children in a row with wrapping but in reversed order
|
||||
- `LV_FLEX_FLOW_COLUMN_WRAP_REVERSE` Place the children in a column with wrapping but in reversed order
|
||||
|
||||
### Flex align
|
||||
To manage the placement of the children use `lv_obj_set_flex_align(obj, main_place, cross_place, track_cross_place)`
|
||||
|
||||
- `main_place` determines how to distribute the items in their track on the main axis. E.g. flush the items to the right on `LV_FLEX_FLOW_ROW_WRAP`. (It's called `justify-content` in CSS)
|
||||
- `cross_place` determines how to distribute the items in their track on the cross axis. E.g. if the items have different height place them to the bottom of the track. (It's called `align-items` in CSS)
|
||||
- `track_cross_place` determines how to distribute the tracks (It's called `align-content` in CSS)
|
||||
|
||||
The possible values are:
|
||||
- `LV_FLEX_ALIGN_START` means left on a horizontally and top vertically. (default)
|
||||
- `LV_FLEX_ALIGN_END` means right on a horizontally and bottom vertically
|
||||
- `LV_FLEX_ALIGN_CENTER` simply center
|
||||
- `LV_FLEX_ALIGN_SPACE_EVENLY` items are distributed so that the spacing between any two items (and the space to the edges) is equal. Does not apply to `track_cross_place`.
|
||||
- `LV_FLEX_ALIGN_SPACE_AROUND` items are evenly distributed in the track with equal space around them.
|
||||
Note that visually the spaces aren’t equal, since all the items have equal space on both sides.
|
||||
The first item will have one unit of space against the container edge, but two units of space between the next item because that next item has its own spacing that applies. Not applies to `track_cross_place`.
|
||||
- `LV_FLEX_ALIGN_SPACE_BETWEEN` items are evenly distributed in the track: first item is on the start line, last item on the end line. Not applies to `track_cross_place`.
|
||||
|
||||
|
||||
### Flex grow
|
||||
|
||||
Flex grow can be used to make one or more children fill the available space on the track. When more children have grow parameters, the available space will be distributed proportionally to the grow values.
|
||||
For example, there is 400 px remaining space and 4 objects with grow:
|
||||
- `A` with grow = 1
|
||||
- `B` with grow = 1
|
||||
- `C` with grow = 2
|
||||
|
||||
`A` and `B` will have 100 px size, and `C` will have 200 px size.
|
||||
|
||||
Flex grow can be set on a child with `lv_obj_set_flex_grow(child, value)`. `value` needs to be > 1 or 0 to disable grow on the child.
|
||||
|
||||
|
||||
## Style interface
|
||||
|
||||
All the Flex-related values are style properties under the hood and you can use them similarly to any other style property. The following flex related style properties exist:
|
||||
|
||||
- `FLEX_FLOW`
|
||||
- `FLEX_MAIN_PLACE`
|
||||
- `FLEX_CROSS_PLACE`
|
||||
- `FLEX_TRACK_PLACE`
|
||||
- `FLEX_GROW`
|
||||
|
||||
### Internal padding
|
||||
|
||||
To modify the minimum space flexbox inserts between objects, the following properties can be set on the flex container style:
|
||||
|
||||
- `pad_row` Sets the padding between the rows.
|
||||
|
||||
- `pad_column` Sets the padding between the columns.
|
||||
|
||||
These can for example be used if you don't want any padding between your objects: `lv_style_set_pad_column(&row_container_style,0)`
|
||||
|
||||
## Other features
|
||||
|
||||
### RTL
|
||||
If the base direction of the container is set the `LV_BASE_DIR_RTL` the meaning of `LV_FLEX_ALIGN_START` and `LV_FLEX_ALIGN_END` is swapped on `ROW` layouts. I.e. `START` will mean right.
|
||||
|
||||
The items on `ROW` layouts, and tracks of `COLUMN` layouts will be placed from right to left.
|
||||
|
||||
### New track
|
||||
|
||||
You can force Flex to put an item into a new line with `lv_obj_add_flag(child, LV_OBJ_FLAG_FLEX_IN_NEW_TRACK)`.
|
||||
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/layouts/flex/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_flex.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
117
LVGL.Simulator/lvgl/docs/layouts/grid.md
Normal file
@@ -0,0 +1,117 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/layouts/grid.md
|
||||
```
|
||||
|
||||
# Grid
|
||||
|
||||
## Overview
|
||||
|
||||
The Grid layout is a subset of [CSS Flexbox](https://css-tricks.com/snippets/css/complete-guide-grid/).
|
||||
|
||||
It can arrange items into a 2D "table" that has rows or columns (tracks). The item can span through multiple columns or rows.
|
||||
The track's size can be set in pixel, to the largest item (`LV_GRID_CONTENT`) or in "Free unit" (FR) to distribute the free space proportionally.
|
||||
|
||||
To make an object a grid container call `lv_obj_set_layout(obj, LV_LAYOUT_GRID)`.
|
||||
|
||||
Note that the grid layout feature of LVGL needs to be globally enabled with `LV_USE_GRID` in `lv_conf.h`.
|
||||
|
||||
## Terms
|
||||
- tracks: the rows or columns
|
||||
- free unit (FR): if set on track's size is set in `FR` it will grow to fill the remaining space on the parent.
|
||||
- gap: the space between the rows and columns or the items on a track
|
||||
|
||||
## Simple interface
|
||||
|
||||
With the following functions you can easily set a Grid layout on any parent.
|
||||
|
||||
### Grid descriptors
|
||||
|
||||
First you need to describe the size of rows and columns. It can be done by declaring 2 arrays and the track sizes in them. The last element must be `LV_GRID_TEMPLATE_LAST`.
|
||||
|
||||
For example:
|
||||
```
|
||||
static lv_coord_t column_dsc[] = {100, 400, LV_GRID_TEMPLATE_LAST}; /*2 columns with 100 and 400 ps width*/
|
||||
static lv_coord_t row_dsc[] = {100, 100, 100, LV_GRID_TEMPLATE_LAST}; /*3 100 px tall rows*/
|
||||
```
|
||||
|
||||
To set the descriptors on a parent use `lv_obj_set_grid_dsc_array(obj, col_dsc, row_dsc)`.
|
||||
|
||||
Besides simple settings the size in pixel you can use two special values:
|
||||
- `LV_GRID_CONTENT` set the width to the largest children on this track
|
||||
- `LV_GRID_FR(X)` tell what portion of the remaining space should be used by this track. Larger value means larger space.
|
||||
|
||||
### Grid items
|
||||
By default, the children are not added to the grid. They need to be added manually to a cell.
|
||||
|
||||
To do this call `lv_obj_set_grid_cell(child, column_align, column_pos, column_span, row_align, row_pos, row_span)`.
|
||||
|
||||
`column_align` and `row_align` determine how to align the children in its cell. The possible values are:
|
||||
- `LV_GRID_ALIGN_START` means left on a horizontally and top vertically. (default)
|
||||
- `LV_GRID_ALIGN_END` means right on a horizontally and bottom vertically
|
||||
- `LV_GRID_ALIGN_CENTER` simply center
|
||||
|
||||
`colum_pos` and `row_pos` means the zero based index of the cell into the item should be placed.
|
||||
|
||||
`colum_span` and `row_span` means how many tracks should the item involve from the start cell. Must be > 1.
|
||||
|
||||
### Grid align
|
||||
|
||||
If there are some empty space the track can be aligned several ways:
|
||||
- `LV_GRID_ALIGN_START` means left on a horizontally and top vertically. (default)
|
||||
- `LV_GRID_ALIGN_END` means right on a horizontally and bottom vertically
|
||||
- `LV_GRID_ALIGN_CENTER` simply center
|
||||
- `LV_GRID_ALIGN_SPACE_EVENLY` items are distributed so that the spacing between any two items (and the space to the edges) is equal. Not applies to `track_cross_place`.
|
||||
- `LV_GRID_ALIGN_SPACE_AROUND` items are evenly distributed in the track with equal space around them.
|
||||
Note that visually the spaces aren’t equal, since all the items have equal space on both sides.
|
||||
The first item will have one unit of space against the container edge, but two units of space between the next item because that next item has its own spacing that applies. Not applies to `track_cross_place`.
|
||||
- `LV_GRID_ALIGN_SPACE_BETWEEN` items are evenly distributed in the track: first item is on the start line, last item on the end line. Not applies to `track_cross_place`.
|
||||
|
||||
To set the track's alignment use `lv_obj_set_grid_align(obj, column_align, row_align)`.
|
||||
|
||||
## Style interface
|
||||
|
||||
All the Grid related values are style properties under the hood and you can use them similarly to any other style properties. The following Grid related style properties exist:
|
||||
|
||||
- `GRID_COLUMN_DSC_ARRAY`
|
||||
- `GRID_ROW_DSC_ARRAY`
|
||||
- `GRID_COLUMN_ALIGN`
|
||||
- `GRID_ROW_ALIGN`
|
||||
- `GRID_CELL_X_ALIGN`
|
||||
- `GRID_CELL_COLUMN_POS`
|
||||
- `GRID_CELL_COLUMN_SPAN`
|
||||
- `GRID_CELL_Y_ALIGN`
|
||||
- `GRID_CELL_ROW_POS`
|
||||
- `GRID_CELL_ROW_SPAN`
|
||||
|
||||
### Internal padding
|
||||
|
||||
To modify the minimum space Grid inserts between objects, the following properties can be set on the Grid container style:
|
||||
|
||||
- `pad_row` Sets the padding between the rows.
|
||||
- `pad_column` Sets the padding between the columns.
|
||||
|
||||
## Other features
|
||||
|
||||
### RTL
|
||||
If the base direction of the container is set to `LV_BASE_DIR_RTL`, the meaning of `LV_GRID_ALIGN_START` and `LV_GRID_ALIGN_END` is swapped. I.e. `START` will mean right-most.
|
||||
|
||||
The columns will be placed from right to left.
|
||||
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/layouts/grid/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_grid.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
15
LVGL.Simulator/lvgl/docs/layouts/index.md
Normal file
@@ -0,0 +1,15 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/layouts/index.md
|
||||
```
|
||||
|
||||
# Layouts
|
||||
|
||||
|
||||
```eval_rst
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
flex
|
||||
grid
|
||||
```
|
||||
42
LVGL.Simulator/lvgl/docs/libs/bmp.md
Normal file
@@ -0,0 +1,42 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/bmp.md
|
||||
```
|
||||
|
||||
# BMP decoder
|
||||
|
||||
This extension allows the use of BMP images in LVGL.
|
||||
This implementation uses [bmp-decoder](https://github.com/caj-johnson/bmp-decoder) library.
|
||||
The pixels are read on demand (not the whole image is loaded) so using BMP images requires very little RAM.
|
||||
|
||||
If enabled in `lv_conf.h` by `LV_USE_BMP` LVGL will register a new image decoder automatically so BMP files can be directly used as image sources. For example:
|
||||
```
|
||||
lv_img_set_src(my_img, "S:path/to/picture.bmp");
|
||||
```
|
||||
|
||||
Note that, a file system driver needs to registered to open images from files. Read more about it [here](https://docs.lvgl.io/master/overview/file-system.html) or just enable one in `lv_conf.h` with `LV_USE_FS_...`
|
||||
|
||||
## Limitations
|
||||
- Only BMP files are supported and BMP images as C array (`lv_img_dsc_t`) are not. It's because there is no practical differences between how the BMP files and LVGL's image format stores the image data.
|
||||
- BMP files can be loaded only from file. If you want to store them in flash it's better to convert them to C array with [LVGL's image converter](https://lvgl.io/tools/imageconverter).
|
||||
- The BMP files color format needs to match with `LV_COLOR_DEPTH`. Use GIMP to save the image in the required format.
|
||||
Both RGB888 and ARGB888 works with `LV_COLOR_DEPTH 32`
|
||||
- Palette is not supported.
|
||||
- Because not the whole image is read in can not be zoomed or rotated.
|
||||
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/libs/bmp/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_bmp.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
41
LVGL.Simulator/lvgl/docs/libs/ffmpeg.md
Normal file
@@ -0,0 +1,41 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/ffmpeg.md
|
||||
```
|
||||
|
||||
# FFmpeg support
|
||||
[FFmpeg](https://www.ffmpeg.org/) A complete, cross-platform solution to record, convert and stream audio and video.
|
||||
|
||||
## Install FFmpeg
|
||||
- Download FFmpeg from [here](https://www.ffmpeg.org/download.html)
|
||||
- `./configure --disable-all --disable-autodetect --disable-podpages --disable-asm --enable-avcodec --enable-avformat --enable-decoders --enable-encoders --enable-demuxers --enable-parsers --enable-protocol='file' --enable-swscale --enable-zlib`
|
||||
- `make`
|
||||
- `sudo make install`
|
||||
|
||||
## Add FFmpeg to your project
|
||||
- Add library: `FFmpeg` (for GCC: `-lavformat -lavcodec -lavutil -lswscale -lm -lz -lpthread`)
|
||||
|
||||
## Usage
|
||||
|
||||
Enable `LV_USE_FFMPEG` in `lv_conf.h`.
|
||||
|
||||
See the examples below.
|
||||
|
||||
Note that, the FFmpeg extension doesn't use LVGL's file system.
|
||||
You can simply pass the path to the image or video as usual on your operating system or platform.
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/libs/ffmpeg/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_ffmpeg.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
55
LVGL.Simulator/lvgl/docs/libs/freetype.md
Normal file
@@ -0,0 +1,55 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/freetype.md
|
||||
```
|
||||
|
||||
# FreeType support
|
||||
Interface to [FreeType](https://www.freetype.org/) to generate font bitmaps run time.
|
||||
|
||||
## Install FreeType
|
||||
- Download Freetype from [here](https://sourceforge.net/projects/freetype/files/)
|
||||
- `make`
|
||||
- `sudo make install`
|
||||
|
||||
## Add FreeType to your project
|
||||
- Add include path: `/usr/include/freetype2` (for GCC: `-I/usr/include/freetype2 -L/usr/local/lib`)
|
||||
- Add library: `freetype` (for GCC: `-L/usr/local/lib -lfreetype`)
|
||||
|
||||
## Usage
|
||||
Enable `LV_USE_FREETYPE` in `lv_conf.h`.
|
||||
|
||||
To cache the glyphs from the opened fonts, set `LV_FREETYPE_CACHE_SIZE >= 0` and then use the following macros for detailed configuration:
|
||||
1. `LV_FREETYPE_CACHE_SIZE`:maximum memory(bytes) used to cache font bitmap, outline, character maps, etc. 0 means use the system default value, less than 0 means disable cache. Note: that this value does not account for managed FT_Face and FT_Size objects.
|
||||
1. `LV_FREETYPE_CACHE_FT_FACES`:maximum number of opened FT_Face objects managed by this cache instance.0 means use the system default value. Only useful when LV_FREETYPE_CACHE_SIZE >= 0.
|
||||
1. `LV_FREETYPE_CACHE_FT_SIZES`:maximum number of opened FT_Size objects managed by this cache instance. 0 means use the system default value. Only useful when LV_FREETYPE_CACHE_SIZE >= 0.
|
||||
|
||||
When you are sure that all the used font sizes will not be greater than 256, you can enable `LV_FREETYPE_SBIT_CACHE`, which is much more memory efficient for small bitmaps.
|
||||
|
||||
You can use `lv_ft_font_init()` to create FreeType fonts. It returns `true` to indicate success, at the same time, the `font` member of `lv_ft_info_t` will be filled with a pointer to an LVGL font, and you can use it like any LVGL font.
|
||||
|
||||
Font style supports bold and italic, you can use the following macros to set:
|
||||
1. `FT_FONT_STYLE_NORMAL`:default style.
|
||||
1. `FT_FONT_STYLE_ITALIC`:Italic style
|
||||
1. `FT_FONT_STYLE_BOLD`:bold style
|
||||
|
||||
They can be combined.eg:`FT_FONT_STYLE_BOLD | FT_FONT_STYLE_ITALIC`.
|
||||
|
||||
Note that, the FreeType extension doesn't use LVGL's file system.
|
||||
You can simply pass the path to the font as usual on your operating system or platform.
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
.. include:: ../../examples/libs/freetype/index.rst
|
||||
```
|
||||
|
||||
|
||||
## Learn more
|
||||
- FreeType [tutorial](https://www.freetype.org/freetype2/docs/tutorial/step1.html)
|
||||
- LVGL's [font interface](https://docs.lvgl.io/v7/en/html/overview/font.html#add-a-new-font-engine)
|
||||
|
||||
|
||||
## API
|
||||
```eval_rst
|
||||
.. doxygenfile:: lv_freetype.h
|
||||
:project: lvgl
|
||||
```
|
||||
25
LVGL.Simulator/lvgl/docs/libs/fsdrv.md
Normal file
@@ -0,0 +1,25 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/fsdrv.md
|
||||
```
|
||||
|
||||
# File System Interfaces
|
||||
|
||||
LVGL has a [File system](https://docs.lvgl.io/master/overview/file-system.html) module to provide an abstraction layer for various file system drivers.
|
||||
|
||||
LVG has built in support for:
|
||||
- [FATFS](http://elm-chan.org/fsw/ff/00index_e.html)
|
||||
- STDIO (Linux and Windows using C standard function .e.g fopen, fread)
|
||||
- POSIX (Linux and Windows using POSIX function .e.g open, read)
|
||||
- WIN32 (Windows using Win32 API function .e.g CreateFileA, ReadFile)
|
||||
|
||||
You still need to provide the drivers and libraries, this extension provides only the bridge between FATFS, STDIO, POSIX, WIN32 and LVGL.
|
||||
|
||||
## Usage
|
||||
|
||||
In `lv_conf.h` enable `LV_USE_FS_...` and assign an upper cased letter to `LV_FS_..._LETTER` (e.g. `'S'`).
|
||||
After that you can access files using that driver letter. E.g. `"S:path/to/file.txt"`.
|
||||
|
||||
The work directory can be set with `LV_FS_..._PATH`. E.g. `"/home/joe/projects/"` The actual file/directory paths will be appended to it.
|
||||
|
||||
Cached reading is also supported if `LV_FS_..._CACHE_SIZE` is set to not `0` value. `lv_fs_read` caches this size of data to lower the number of actual reads from the storage.
|
||||
43
LVGL.Simulator/lvgl/docs/libs/gif.md
Normal file
@@ -0,0 +1,43 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/gif.md
|
||||
```
|
||||
|
||||
# GIF decoder
|
||||
Allow using GIF images in LVGL. Based on https://github.com/lecram/gifdec
|
||||
|
||||
When enabled in `lv_conf.h` with `LV_USE_GIF` `lv_gif_create(parent)` can be used to create a gif widget.
|
||||
|
||||
`lv_gif_set_src(obj, src)` works very similarly to `lv_img_set_src`. As source, it also accepts images as variables (`lv_img_dsc_t`) or files.
|
||||
|
||||
|
||||
## Convert GIF files to C array
|
||||
To convert a GIF file to byte values array use [LVGL's online converter](https://lvgl.io/tools/imageconverter). Select "Raw" color format and "C array" Output format.
|
||||
|
||||
|
||||
## Use GIF images from file
|
||||
For example:
|
||||
```c
|
||||
lv_gif_set_src(obj, "S:path/to/example.gif");
|
||||
```
|
||||
|
||||
Note that, a file system driver needs to be registered to open images from files. Read more about it [here](https://docs.lvgl.io/master/overview/file-system.html) or just enable one in `lv_conf.h` with `LV_USE_FS_...`
|
||||
|
||||
|
||||
## Memory requirements
|
||||
To decode and display a GIF animation the following amount of RAM is required:
|
||||
- `LV_COLOR_DEPTH 8`: 3 x image width x image height
|
||||
- `LV_COLOR_DEPTH 16`: 4 x image width x image height
|
||||
- `LV_COLOR_DEPTH 32`: 5 x image width x image height
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
.. include:: ../../examples/libs/gif/index.rst
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
.. doxygenfile:: lv_gif.h
|
||||
:project: lvgl
|
||||
```
|
||||
23
LVGL.Simulator/lvgl/docs/libs/index.md
Normal file
@@ -0,0 +1,23 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/index.md
|
||||
```
|
||||
# 3rd party libraries
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
fsdrv
|
||||
bmp
|
||||
sjpg
|
||||
png
|
||||
gif
|
||||
freetype
|
||||
qrcode
|
||||
rlottie
|
||||
ffmpeg
|
||||
```
|
||||
|
||||
31
LVGL.Simulator/lvgl/docs/libs/png.md
Normal file
@@ -0,0 +1,31 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/png.md
|
||||
```
|
||||
|
||||
# PNG decoder
|
||||
|
||||
Allow the use of PNG images in LVGL. This implementation uses [lodepng](https://github.com/lvandeve/lodepng) library.
|
||||
|
||||
If enabled in `lv_conf.h` by `LV_USE_PNG` LVGL will register a new image decoder automatically so PNG files can be directly used as any other image sources.
|
||||
|
||||
Note that, a file system driver needs to registered to open images from files. Read more about it [here](https://docs.lvgl.io/master/overview/file-system.html) or just enable one in `lv_conf.h` with `LV_USE_FS_...`
|
||||
|
||||
The whole PNG image is decoded so during decoding RAM equals to `image width x image height x 4` bytes are required.
|
||||
|
||||
As it might take significant time to decode PNG images LVGL's [images caching](https://docs.lvgl.io/master/overview/image.html#image-caching) feature can be useful.
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/libs/png/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_png.h
|
||||
:project: lvgl
|
||||
|
||||
42
LVGL.Simulator/lvgl/docs/libs/qrcode.md
Normal file
@@ -0,0 +1,42 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/qrcode.md
|
||||
```
|
||||
|
||||
# QR code
|
||||
|
||||
QR code generation with LVGL. Uses [QR-Code-generator](https://github.com/nayuki/QR-Code-generator) by [nayuki](https://github.com/nayuki).
|
||||
|
||||
## Get started
|
||||
- Download or clone this repository
|
||||
- [Download](https://github.com/lvgl/lv_lib_qrcode.git) from GitHub
|
||||
- Clone: git clone https://github.com/lvgl/lv_lib_qrcode.git
|
||||
- Include the library: `#include "lv_lib_qrcode/lv_qrcode.h"`
|
||||
- Test with the following code:
|
||||
```c
|
||||
const char * data = "Hello world";
|
||||
|
||||
/*Create a 100x100 QR code*/
|
||||
lv_obj_t * qr = lv_qrcode_create(lv_scr_act(), 100, lv_color_hex3(0x33f), lv_color_hex3(0xeef));
|
||||
|
||||
/*Set data*/
|
||||
lv_qrcode_update(qr, data, strlen(data));
|
||||
```
|
||||
|
||||
## Notes
|
||||
- QR codes with less data are smaller, but they scaled by an integer number to best fit to the given size.
|
||||
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/libs/qrcode/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_qrcode.h
|
||||
:project: lvgl
|
||||
110
LVGL.Simulator/lvgl/docs/libs/rlottie.md
Normal file
@@ -0,0 +1,110 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/rlottie.md
|
||||
```
|
||||
|
||||
|
||||
# Lottie player
|
||||
Allows to use Lottie animations in LVGL. Taken from this [base repository](https://github.com/ValentiWorkLearning/lv_rlottie)
|
||||
|
||||
LVGL provides the interface to [Samsung/rlottie](https://github.com/Samsung/rlottie) library's C API. That is the actual Lottie player is not part of LVGL, it needs to be built separately.
|
||||
|
||||
## Build Rlottie
|
||||
To build Samsung's Rlottie C++14-compatible compiler and optionally CMake 3.14 or higher is required.
|
||||
|
||||
To build on desktop you can follow the instructions from Rlottie's [README](https://github.com/Samsung/rlottie/blob/master/README.md). In the most basic case it looks like this:
|
||||
```
|
||||
mkdir rlottie_workdir
|
||||
cd rlottie_workdir
|
||||
git clone https://github.com/Samsung/rlottie.git
|
||||
mkdir build
|
||||
cd build
|
||||
cmake ../rlottie
|
||||
make -j
|
||||
sudo make install
|
||||
```
|
||||
|
||||
And finally add the `-lrlottie` flag to your linker.
|
||||
|
||||
On embedded systems you need to take care of integrating Rlottie to the given build system.
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
You can use animation from files or raw data (text). In either case first you need to enable `LV_USE_RLOTTIE` in `lv_conf.h`.
|
||||
|
||||
|
||||
The `width` and `height` of the object be set in the *create* function and the animation will be scaled accordingly.
|
||||
|
||||
### Use Rlottie from file
|
||||
|
||||
To create a Lottie animation from file use:
|
||||
```c
|
||||
lv_obj_t * lottie = lv_rlottie_create_from_file(parent, width, height, "path/to/lottie.json");
|
||||
```
|
||||
|
||||
Note that, Rlottie uses the standard STDIO C file API, so you can use the path "normally" and no LVGL specific driver letter is required.
|
||||
|
||||
|
||||
### Use Rlottie from raw string data
|
||||
|
||||
`lv_example_rlottie_approve.c` contains an example animation in raw format. Instead storing the JSON string a hex array is stored for the following reasons:
|
||||
- avoid escaping `"` in the JSON file
|
||||
- some compilers don't support very long strings
|
||||
|
||||
`lvgl/scripts/filetohex.py` can be used to convert a Lottie file a hex array. E.g.:
|
||||
```
|
||||
./filetohex.py path/to/lottie.json > out.txt
|
||||
```
|
||||
|
||||
To create an animation from raw data:
|
||||
|
||||
```c
|
||||
extern const uint8_t lottie_data[];
|
||||
lv_obj_t* lottie = lv_rlottie_create_from_raw(parent, width, height, (const char *)lottie_data);
|
||||
```
|
||||
|
||||
## Getting animations
|
||||
|
||||
Lottie is standard and popular format so you can find many animation files on the web.
|
||||
For example: https://lottiefiles.com/
|
||||
|
||||
You can also create your own animations with Adobe After Effects or similar software.
|
||||
|
||||
## Controlling animations
|
||||
|
||||
LVGL provides two functions to control the animation mode: `lv_rlottie_set_play_mode` and `lv_rlottie_set_current_frame`.
|
||||
You'll combine your intentions when calling the first method, like in these examples:
|
||||
```c
|
||||
lv_obj_t * lottie = lv_rlottie_create_from_file(scr, 128, 128, "test.json");
|
||||
lv_obj_center(lottie);
|
||||
// Pause to a specific frame
|
||||
lv_rlottie_set_current_frame(lottie, 50);
|
||||
lv_rlottie_set_play_mode(lottie, LV_RLOTTIE_CTRL_PAUSE); // The specified frame will be displayed and then the animation will pause
|
||||
|
||||
// Play backward and loop
|
||||
lv_rlottie_set_play_mode(lottie, LV_RLOTTIE_CTRL_PLAY | LV_RLOTTIE_CTRL_BACKWARD | LV_RLOTTIE_CTRL_LOOP);
|
||||
|
||||
// Play forward once (no looping)
|
||||
lv_rlottie_set_play_mode(lottie, LV_RLOTTIE_CTRL_PLAY | LV_RLOTTIE_CTRL_FORWARD);
|
||||
```
|
||||
|
||||
The default animation mode is **play forward with loop**.
|
||||
|
||||
If you don't enable looping, a `LV_EVENT_READY` is sent when the animation can not make more progress without looping.
|
||||
|
||||
To get the number of frames in an animation or the current frame index, you can cast the `lv_obj_t` instance to a `lv_rlottie_t` instance and inspect the `current_frame` and `total_frames` members.
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/libs/rlottie/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_rlottie.h
|
||||
:project: lvgl
|
||||
77
LVGL.Simulator/lvgl/docs/libs/sjpg.md
Normal file
@@ -0,0 +1,77 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/libs/sjpg.md
|
||||
```
|
||||
|
||||
# JPG decoder
|
||||
|
||||
Allow the use of JPG images in LVGL. Besides that it also allows the use of a custom format, called Split JPG (SJPG), which can be decoded in more optimal way on embedded systems.
|
||||
|
||||
## Overview
|
||||
- Supports both normal JPG and the custom SJPG formats.
|
||||
- Decoding normal JPG consumes RAM with the size fo the whole uncompressed image (recommended only for devices with more RAM)
|
||||
- SJPG is a custom format based on "normal" JPG and specially made for LVGL.
|
||||
- SJPG is 'split-jpeg' which is a bundle of small jpeg fragments with an sjpg header.
|
||||
- SJPG size will be almost comparable to the jpg file or might be a slightly larger.
|
||||
- File read from file and c-array are implemented.
|
||||
- SJPEG frame fragment cache enables fast fetching of lines if available in cache.
|
||||
- By default the sjpg image cache will be image width * 2 * 16 bytes (can be modified)
|
||||
- Currently only 16 bit image format is supported (TODO)
|
||||
- Only the required partion of the JPG and SJPG images are decoded, therefore they can't be zoomed or rotated.
|
||||
|
||||
## Usage
|
||||
|
||||
If enabled in `lv_conf.h` by `LV_USE_SJPG` LVGL will register a new image decoder automatically so JPG and SJPG files can be directly used as image sources. For example:
|
||||
```
|
||||
lv_img_set_src(my_img, "S:path/to/picture.jpg");
|
||||
```
|
||||
|
||||
Note that, a file system driver needs to registered to open images from files. Read more about it [here](https://docs.lvgl.io/master/overview/file-system.html) or just enable one in `lv_conf.h` with `LV_USE_FS_...`
|
||||
|
||||
|
||||
|
||||
## Converter
|
||||
|
||||
### Converting JPG to C array
|
||||
- Use lvgl online tool https://lvgl.io/tools/imageconverter
|
||||
- Color format = RAW, output format = C Array
|
||||
|
||||
### Converting JPG to SJPG
|
||||
python3 and the PIL library required. (PIL can be installed with `pip3 install pillow`)
|
||||
|
||||
To create SJPG from JPG:
|
||||
- Copy the image to convert into `lvgl/scripts`
|
||||
- `cd lvgl/scripts`
|
||||
- `python3 jpg_to_sjpg.py image_to_convert.jpg`. It creates both a C files and an SJPG image.
|
||||
|
||||
The expected result is:
|
||||
```sh
|
||||
Conversion started...
|
||||
|
||||
Input:
|
||||
image_to_convert.jpg
|
||||
RES = 640 x 480
|
||||
|
||||
Output:
|
||||
Time taken = 1.66 sec
|
||||
bin size = 77.1 KB
|
||||
walpaper.sjpg (bin file)
|
||||
walpaper.c (c array)
|
||||
|
||||
All good!
|
||||
```
|
||||
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/libs/sjpg/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_sjpg.h
|
||||
:project: lvgl
|
||||
BIN
LVGL.Simulator/lvgl/docs/logo_lvgl.png
Normal file
|
After Width: | Height: | Size: 6.6 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/align.png
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/anim-timeline.png
Normal file
|
After Width: | Height: | Size: 86 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/bidi.png
Normal file
|
After Width: | Height: | Size: 21 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/boxmodel.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/btn_example.png
Normal file
|
After Width: | Height: | Size: 1.3 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/button_style_example.gif
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/button_style_example.png
Normal file
|
After Width: | Height: | Size: 2.4 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/codeblocks.jpg
Normal file
|
After Width: | Height: | Size: 3.3 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/eclipse.jpg
Normal file
|
After Width: | Height: | Size: 3.6 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/layers.png
Normal file
|
After Width: | Height: | Size: 5.4 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/par_child1.png
Normal file
|
After Width: | Height: | Size: 973 B |
BIN
LVGL.Simulator/lvgl/docs/misc/par_child2.png
Normal file
|
After Width: | Height: | Size: 993 B |
BIN
LVGL.Simulator/lvgl/docs/misc/par_child3.png
Normal file
|
After Width: | Height: | Size: 990 B |
BIN
LVGL.Simulator/lvgl/docs/misc/platformio.jpg
Normal file
|
After Width: | Height: | Size: 4.9 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/qtcreator.jpg
Normal file
|
After Width: | Height: | Size: 3.5 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/simple_button_example.gif
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/simple_button_example.png
Normal file
|
After Width: | Height: | Size: 1.8 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/symbols.png
Normal file
|
After Width: | Height: | Size: 76 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/sys.png
Normal file
|
After Width: | Height: | Size: 17 KiB |
BIN
LVGL.Simulator/lvgl/docs/misc/visualstudio.jpg
Normal file
|
After Width: | Height: | Size: 3.0 KiB |
81
LVGL.Simulator/lvgl/docs/others/fragment.md
Normal file
@@ -0,0 +1,81 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/fragment.md
|
||||
```
|
||||
|
||||
# Fragment
|
||||
|
||||
Fragment is a concept copied from [Android](https://developer.android.com/guide/fragments).
|
||||
|
||||
It represents a reusable portion of your app's UI. A fragment defines and manages its own layout, has its own lifecycle,
|
||||
and can handle its own events. Like Android's Fragment that must be hosted by an activity or another fragment, Fragment
|
||||
in LVGL needs to be hosted by an object, or another fragment. The fragment’s view hierarchy becomes part of, or attaches
|
||||
to, the host’s view hierarchy.
|
||||
|
||||
Such concept also has some similarities
|
||||
to [UiViewController on iOS](https://developer.apple.com/documentation/uikit/uiviewcontroller).
|
||||
|
||||
Fragment Manager is a manager holding references to fragments attached to it, and has an internal stack to achieve
|
||||
navigation. You can use fragment manager to build navigation stack, or multi pane application easily.
|
||||
|
||||
## Usage
|
||||
|
||||
Enable `LV_USE_FRAGMENT` in `lv_conf.h`.
|
||||
|
||||
### Create Fragment Class
|
||||
|
||||
```c
|
||||
struct sample_fragment_t {
|
||||
/* IMPORTANT: don't miss this part */
|
||||
lv_fragment_t base;
|
||||
/* States, object references and data fields for this fragment */
|
||||
const char *title;
|
||||
};
|
||||
|
||||
const lv_fragment_class_t sample_cls = {
|
||||
/* Initialize something needed */
|
||||
.constructor_cb = sample_fragment_ctor,
|
||||
/* Create view objects */
|
||||
.create_obj_cb = sample_fragment_create_obj,
|
||||
/* IMPORTANT: size of your fragment struct */
|
||||
.instance_size = sizeof(struct sample_fragment_t)
|
||||
};
|
||||
```
|
||||
|
||||
### Use `lv_fragment_manager`
|
||||
|
||||
```c
|
||||
/* Create fragment instance, and objects will be added to container */
|
||||
lv_fragment_manager_t *manager = lv_fragment_manager_create(container, NULL);
|
||||
/* Replace current fragment with instance of sample_cls, and init_argument is user defined pointer */
|
||||
lv_fragment_manager_replace(manager, &sample_cls, init_argument);
|
||||
```
|
||||
|
||||
### Fragment Based Navigation
|
||||
|
||||
```c
|
||||
/* Add one instance into manager stack. View object of current fragment will be destroyed,
|
||||
* but instances created in class constructor will be kept.
|
||||
*/
|
||||
lv_fragment_manager_push(manager, &sample_cls, NULL);
|
||||
|
||||
/* Remove the top most fragment from the stack, and bring back previous one. */
|
||||
lv_fragment_manager_pop(manager);
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/others/fragment/index.rst
|
||||
|
||||
```
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_fragment.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
60
LVGL.Simulator/lvgl/docs/others/gridnav.md
Normal file
@@ -0,0 +1,60 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/gridnav.md
|
||||
```
|
||||
# Grid navigation
|
||||
|
||||
Grid navigation (gridnav for short) is a feature that changes the currently focused child object as arrow keys are pressed.
|
||||
|
||||
If the children are arranged into a grid-like layout then the up, down, left and right arrows move focus to the nearest sibling
|
||||
in the respective direction.
|
||||
|
||||
It doesn't matter how the children are positioned, as only the current x and y coordinates are considered.
|
||||
This means that gridnav works with manually positioned children, as well as [Flex](/layouts/flex) and [Grid](/layouts/grid) layouts.
|
||||
|
||||
Gridnav also works if the children are arranged into a single row or column.
|
||||
That makes it useful, for example, to simplify navigation on a [List widget](/widgets/extra/list).
|
||||
|
||||
Gridnav assumes that the object to which gridnav is added is part of a [group](/overview/indev.html#groups).
|
||||
This way, if the object with gridnav is focused, the arrow key presses are automatically forwarded to the object
|
||||
so that gridnav can process the arrow keys.
|
||||
|
||||
To move the focus to the next widget of the group use `LV_KEY_NEXT/PREV` or `lv_group_focus_next/prev()` or the `TAB` key on keyboard as usual.
|
||||
|
||||
If the container is scrollable and the focused child is out of the view, gridnav will automatically scroll the child into view.
|
||||
|
||||
## Usage
|
||||
|
||||
To add the gridnav feature to an object use `lv_gridnav_add(cont, flags)`.
|
||||
|
||||
`flags` control the behavior of gridnav:
|
||||
- `LV_GRIDNAV_CTRL_NONE` Default settings
|
||||
- `LV_GRIDNAV_CTRL_ROLLOVER` If there is no next/previous object in a direction,
|
||||
the focus goes to the object in the next/previous row (on left/right keys) or first/last row (on up/down keys
|
||||
- `LV_GRIDNAV_CTRL_SCROLL_FIRST` If an arrow is pressed and the focused object can be scrolled in that direction
|
||||
then it will be scrolled instead of going to the next/previous object. If there is no more room for scrolling the next/previous object will be focused normally
|
||||
|
||||
`lv_gridnav_remove(cont)` Removes gridnav from an object.
|
||||
|
||||
## Focusable objects
|
||||
|
||||
An object needs to be clickable or click focusable (`LV_OBJ_FLAG_CLICKABLE` or `LV_OBJ_FLAG_CLICK_FOCUSABLE`)
|
||||
and not hidden (`LV_OBJ_FLAG_HIDDEN`) to be focusable by gridnav.
|
||||
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/others/gridnav/index.rst
|
||||
|
||||
```
|
||||
## API
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_gridnav.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
29
LVGL.Simulator/lvgl/docs/others/imgfont.md
Normal file
@@ -0,0 +1,29 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/imgfont.md
|
||||
```
|
||||
## Image font (imgfont)
|
||||
Draw image in label or span obj with imgfont.
|
||||
This is often used to display Unicode emoji icons in text.
|
||||
Supported image formats: determined by LVGL image decoder.
|
||||
|
||||
## Usage
|
||||
Enable `LV_USE_IMGFONT` in `lv_conf.h`.
|
||||
|
||||
To create a new imgfont use `lv_imgfont_create(height, path_cb)`.
|
||||
|
||||
`height` used to indicate the size of a imgfont.
|
||||
`path_cb` Used to get the image path of the specified unicode.
|
||||
|
||||
Use `lv_imgfont_destroy(imgfont)` to destroy a imgfont that is no longer used.
|
||||
|
||||
## Example
|
||||
```eval_rst
|
||||
.. include:: ../../examples/others/imgfont/index.rst
|
||||
```
|
||||
|
||||
## API
|
||||
```eval_rst
|
||||
.. doxygenfile:: lv_imgfont.h
|
||||
:project: lvgl
|
||||
```
|
||||
19
LVGL.Simulator/lvgl/docs/others/index.md
Normal file
@@ -0,0 +1,19 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/index.md
|
||||
```
|
||||
# Others
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
snapshot
|
||||
monkey
|
||||
gridnav
|
||||
fragment
|
||||
msg
|
||||
```
|
||||
|
||||
39
LVGL.Simulator/lvgl/docs/others/monkey.md
Normal file
@@ -0,0 +1,39 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/monkey.md
|
||||
```
|
||||
# Monkey
|
||||
|
||||
A simple monkey test. Use random input to stress test the application.
|
||||
|
||||
## Usage
|
||||
|
||||
Enable `LV_USE_MONKEY` in `lv_conf.h`.
|
||||
|
||||
First configure monkey, use `lv_monkey_config_t` to define the configuration structure, set the `type` (check [input devices](/overview/indev) for the supported types), and then set the range of `period_range` and `input_range`, the monkey will output random operations at random times within this range. Call `lv_monkey_create` to create monkey. Finally call `lv_monkey_set_enable(monkey, true)` to enable monkey.
|
||||
|
||||
If you want to pause the monkey, call `lv_monkey_set_enable(monkey, false)`. To delete the monkey, call `lv_monkey_del(monkey)`.
|
||||
|
||||
Note that `input_range` has different meanings in different `type`:
|
||||
|
||||
- `LV_INDEV_TYPE_POINTER` No effect, click randomly within the pixels of the screen resolution.
|
||||
- `LV_INDEV_TYPE_ENCODER` The minimum and maximum values of `enc_diff`.
|
||||
- `LV_INDEV_TYPE_BUTTON` The minimum and maximum values of `btn_id`. Use `lv_monkey_get_indev()` to get the input device, and use `lv_indev_set_button_points()` to map the key ID to the coordinates.
|
||||
- `LV_INDEV_TYPE_KEYPAD` No effect, Send random [Keys](/overview/indev).
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/others/monkey/index.rst
|
||||
|
||||
```
|
||||
## API
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_monkey.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
101
LVGL.Simulator/lvgl/docs/others/msg.md
Normal file
@@ -0,0 +1,101 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/msg.md
|
||||
```
|
||||
# Messaging
|
||||
|
||||
Messaging (`lv_msg`) is a classic []publisher subscriber](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern) implementation for LVGL.
|
||||
|
||||
## IDs
|
||||
Both the publishers and the subscribers needs to know the message identifiers.
|
||||
In `lv_msg` these are simple `uint32_t` integers. For example:
|
||||
```c
|
||||
#define MSG_DOOR_OPENED 1
|
||||
#define MSG_DOOR_CLOSED 2
|
||||
#define MSG_USER_NAME_CHANGED 100
|
||||
#define MSG_USER_AVATAR_CHANGED 101
|
||||
```
|
||||
|
||||
You can orgnaize the message IDs as you wish.
|
||||
|
||||
Both parties also need to know about the format of teh payload. E.g. in the above example
|
||||
`MSG_DOOR_OPENED` and `MSG_DOOR_CLOSED` has no payload but `MSG_USER_NAME_CHANGED` can have a `const char *` payload containing the user name, and `MSG_USER_AVATAR_CHANGED` a `const void *` image source with the new avatar image.
|
||||
|
||||
|
||||
## Send message
|
||||
|
||||
Messages can be sent with `lv_msg_send(msg_id, payload)`. E.g.
|
||||
```c
|
||||
lv_msg_send(MSG_USER_DOOR_OPENED, NULL);
|
||||
lv_msg_send(MSG_USER_NAME_CHANGED, "John Smith");
|
||||
```
|
||||
|
||||
## Subscribe to a message
|
||||
|
||||
`lv_msg_subscribe(msg_id, callback, user_data)` can be used to subscribe to message.
|
||||
|
||||
The callback should look like this:
|
||||
```c
|
||||
|
||||
static void user_name_subscriber_cb(void * s, lv_msg_t * m)
|
||||
{
|
||||
/*s: a subscriber obeject, can be used to unscubscribe*/
|
||||
/*m: a message object with the msg_id, payload, and user_data (set durung subscription)*/
|
||||
|
||||
...do something...
|
||||
}
|
||||
```
|
||||
|
||||
From `lv_msg_t` the followings can be used to get some data:
|
||||
- `lv_msg_get_id(m)`
|
||||
- `lv_msg_get_payload(m)`
|
||||
- `lv_msg_get_user_data(m)`
|
||||
|
||||
## Subscribe with an lv_obj
|
||||
It's quite typical that an LVGL widget is interested in some messages.
|
||||
To make it simpler `lv_msg_subsribe_obj(msg_id, obj, user_data)` can be used.
|
||||
If a new message is published with `msg_id` an `LV_EVENT_MSG_RECEIVED` event will be sent to the object.
|
||||
|
||||
For example:
|
||||
```c
|
||||
lv_obj_add_event_cb(user_name_label, user_name_label_event_cb, LV_EVENT_MSG_RECEIVED, NULL);
|
||||
lv_msg_subsribe_obj(MSG_USER_NAME_CHANGED, user_name_label, NULL);
|
||||
|
||||
...
|
||||
|
||||
void user_name_label_event_cb(lv_event_t * e)
|
||||
{
|
||||
lv_obj_t * label = lv_event_get_target(e);
|
||||
lv_msg_t * m = lv_event_get_msg(e);
|
||||
lv_label_set_text(label, lv_msg_get_payload(m));
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Unsubscribe
|
||||
`lv_msg_subscribe` returns a pointer which can be used to unsubscribe:
|
||||
```c
|
||||
void * s1;
|
||||
s1 = lv_msg_subscribe(MSG_USER_DOOR_OPENED, some_callback, NULL);
|
||||
|
||||
...
|
||||
|
||||
lv_msg_unsubscribe(s1);
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/others/msg/index.rst
|
||||
|
||||
```
|
||||
## API
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_msg.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
67
LVGL.Simulator/lvgl/docs/others/snapshot.md
Normal file
@@ -0,0 +1,67 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/others/snapshot.md
|
||||
```
|
||||
# Snapshot
|
||||
|
||||
Snapshot provides APIs to take snapshot image for LVGL object together with its children. The image will look exactly like the object.
|
||||
|
||||
## Usage
|
||||
|
||||
Simply call API `lv_snapshot_take` to generate the image descriptor which can be set as image object src using `lv_img_set_src`.
|
||||
|
||||
|
||||
Note, only below color formats are supported for now:
|
||||
- LV_IMG_CF_TRUE_COLOR_ALPHA
|
||||
- LV_IMG_CF_ALPHA_1BIT
|
||||
- LV_IMG_CF_ALPHA_2BIT
|
||||
- LV_IMG_CF_ALPHA_4BIT
|
||||
- LV_IMG_CF_ALPHA_8BIT
|
||||
|
||||
|
||||
### Free the Image
|
||||
The memory `lv_snapshot_take` uses are dynamically allocated using `lv_mem_alloc`. Use API `lv_snapshot_free` to free the memory it takes. This will firstly free memory the image data takes, then the image descriptor.
|
||||
|
||||
|
||||
Take caution to free the snapshot but not delete the image object. Before free the memory, be sure to firstly unlink it from image object, using `lv_img_set_src(NULL)` and `lv_img_cache_invalidate_src(src)`.
|
||||
|
||||
|
||||
Below code snippet explains usage of this API.
|
||||
|
||||
```c
|
||||
void update_snapshot(lv_obj_t * obj, lv_obj_t * img_snapshot)
|
||||
{
|
||||
lv_img_dsc_t* snapshot = (void*)lv_img_get_src(img_snapshot);
|
||||
if(snapshot) {
|
||||
lv_snapshot_free(snapshot);
|
||||
}
|
||||
snapshot = lv_snapshot_take(obj, LV_IMG_CF_TRUE_COLOR_ALPHA);
|
||||
lv_img_set_src(img_snapshot, snapshot);
|
||||
}
|
||||
```
|
||||
|
||||
### Use Existing Buffer
|
||||
If the snapshot needs update now and then, or simply caller provides memory, use API `lv_res_t lv_snapshot_take_to_buf(lv_obj_t * obj, lv_img_cf_t cf, lv_img_dsc_t * dsc, void * buf, uint32_t buff_size);` for this case. It's caller's responsibility to alloc/free the memory.
|
||||
|
||||
|
||||
If snapshot is generated successfully, the image descriptor is updated and image data will be stored to provided `buf`.
|
||||
|
||||
|
||||
Note that snapshot may fail if provided buffer is not enough, which may happen when object size changes. It's recommended to use API `lv_snapshot_buf_size_needed` to check the needed buffer size in byte firstly and resize the buffer accordingly.
|
||||
|
||||
## Example
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/others/snapshot/index.rst
|
||||
|
||||
```
|
||||
## API
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_snapshot.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
145
LVGL.Simulator/lvgl/docs/overview/animation.md
Normal file
@@ -0,0 +1,145 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/animation.md
|
||||
```
|
||||
# Animations
|
||||
|
||||
You can automatically change the value of a variable between a start and an end value using animations.
|
||||
Animation will happen by periodically calling an "animator" function with the corresponding value parameter.
|
||||
|
||||
The *animator* functions have the following prototype:
|
||||
```c
|
||||
void func(void * var, lv_anim_var_t value);
|
||||
```
|
||||
This prototype is compatible with the majority of the property *set* functions in LVGL. For example `lv_obj_set_x(obj, value)` or `lv_obj_set_width(obj, value)`
|
||||
|
||||
|
||||
## Create an animation
|
||||
To create an animation an `lv_anim_t` variable has to be initialized and configured with `lv_anim_set_...()` functions.
|
||||
|
||||
```c
|
||||
|
||||
/* INITIALIZE AN ANIMATION
|
||||
*-----------------------*/
|
||||
|
||||
lv_anim_t a;
|
||||
lv_anim_init(&a);
|
||||
|
||||
/* MANDATORY SETTINGS
|
||||
*------------------*/
|
||||
|
||||
/*Set the "animator" function*/
|
||||
lv_anim_set_exec_cb(&a, (lv_anim_exec_xcb_t) lv_obj_set_x);
|
||||
|
||||
/*Set target of the animation*/
|
||||
lv_anim_set_var(&a, obj);
|
||||
|
||||
/*Length of the animation [ms]*/
|
||||
lv_anim_set_time(&a, duration);
|
||||
|
||||
/*Set start and end values. E.g. 0, 150*/
|
||||
lv_anim_set_values(&a, start, end);
|
||||
|
||||
/* OPTIONAL SETTINGS
|
||||
*------------------*/
|
||||
|
||||
/*Time to wait before starting the animation [ms]*/
|
||||
lv_anim_set_delay(&a, delay);
|
||||
|
||||
/*Set path (curve). Default is linear*/
|
||||
lv_anim_set_path(&a, lv_anim_path_ease_in);
|
||||
|
||||
/*Set a callback to indicate when the animation is ready (idle).*/
|
||||
lv_anim_set_ready_cb(&a, ready_cb);
|
||||
|
||||
/*Set a callback to indicate when the animation is started (after delay).*/
|
||||
lv_anim_set_start_cb(&a, start_cb);
|
||||
|
||||
/*When ready, play the animation backward with this duration. Default is 0 (disabled) [ms]*/
|
||||
lv_anim_set_playback_time(&a, time);
|
||||
|
||||
/*Delay before playback. Default is 0 (disabled) [ms]*/
|
||||
lv_anim_set_playback_delay(&a, delay);
|
||||
|
||||
/*Number of repetitions. Default is 1. LV_ANIM_REPEAT_INFINITE for infinite repetition*/
|
||||
lv_anim_set_repeat_count(&a, cnt);
|
||||
|
||||
/*Delay before repeat. Default is 0 (disabled) [ms]*/
|
||||
lv_anim_set_repeat_delay(&a, delay);
|
||||
|
||||
/*true (default): apply the start value immediately, false: apply start value after delay when the anim. really starts. */
|
||||
lv_anim_set_early_apply(&a, true/false);
|
||||
|
||||
/* START THE ANIMATION
|
||||
*------------------*/
|
||||
lv_anim_start(&a); /*Start the animation*/
|
||||
```
|
||||
|
||||
|
||||
You can apply multiple different animations on the same variable at the same time.
|
||||
For example, animate the x and y coordinates with `lv_obj_set_x` and `lv_obj_set_y`. However, only one animation can exist with a given variable and function pair and `lv_anim_start()` will remove any existing animations for such a pair.
|
||||
|
||||
## Animation path
|
||||
|
||||
You can control the path of an animation. The most simple case is linear, meaning the current value between *start* and *end* is changed with fixed steps.
|
||||
A *path* is a function which calculates the next value to set based on the current state of the animation. Currently, there are the following built-in path functions:
|
||||
|
||||
- `lv_anim_path_linear` linear animation
|
||||
- `lv_anim_path_step` change in one step at the end
|
||||
- `lv_anim_path_ease_in` slow at the beginning
|
||||
- `lv_anim_path_ease_out` slow at the end
|
||||
- `lv_anim_path_ease_in_out` slow at the beginning and end
|
||||
- `lv_anim_path_overshoot` overshoot the end value
|
||||
- `lv_anim_path_bounce` bounce back a little from the end value (like hitting a wall)
|
||||
|
||||
|
||||
## Speed vs time
|
||||
By default, you set the animation time directly. But in some cases, setting the animation speed is more practical.
|
||||
|
||||
The `lv_anim_speed_to_time(speed, start, end)` function calculates the required time in milliseconds to reach the end value from a start value with the given speed.
|
||||
The speed is interpreted in _unit/sec_ dimension. For example, `lv_anim_speed_to_time(20,0,100)` will yield 5000 milliseconds. For example, in the case of `lv_obj_set_x` *unit* is pixels so *20* means *20 px/sec* speed.
|
||||
|
||||
## Delete animations
|
||||
|
||||
You can delete an animation with `lv_anim_del(var, func)` if you provide the animated variable and its animator function.
|
||||
|
||||
## Timeline
|
||||
A timeline is a collection of multiple animations which makes it easy to create complex composite animations.
|
||||
|
||||
Firstly, create an animation element but don’t call `lv_anim_start()`.
|
||||
|
||||
Secondly, create an animation timeline object by calling `lv_anim_timeline_create()`.
|
||||
|
||||
Thirdly, add animation elements to the animation timeline by calling `lv_anim_timeline_add(at, start_time, &a)`. `start_time` is the start time of the animation on the timeline. Note that `start_time` will override the value of `delay`.
|
||||
|
||||
Finally, call `lv_anim_timeline_start(at)` to start the animation timeline.
|
||||
|
||||
It supports forward and backward playback of the entire animation group, using `lv_anim_timeline_set_reverse(at, reverse)`.
|
||||
|
||||
Call `lv_anim_timeline_stop(at)` to stop the animation timeline.
|
||||
|
||||
Call `lv_anim_timeline_set_progress(at, progress)` function to set the state of the object corresponding to the progress of the timeline.
|
||||
|
||||
Call `lv_anim_timeline_get_playtime(at)` function to get the total duration of the entire animation timeline.
|
||||
|
||||
Call `lv_anim_timeline_get_reverse(at)` function to get whether to reverse the animation timeline.
|
||||
|
||||
Call `lv_anim_timeline_del(at)` function to delete the animation timeline.
|
||||
|
||||

|
||||
|
||||
## Examples
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/anim/index.rst
|
||||
|
||||
```
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_anim.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
157
LVGL.Simulator/lvgl/docs/overview/color.md
Normal file
@@ -0,0 +1,157 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/color.md
|
||||
```
|
||||
# Colors
|
||||
|
||||
The color module handles all color-related functions like changing color depth, creating colors from hex code, converting between color depths, mixing colors, etc.
|
||||
|
||||
The type `lv_color_t` is used to store a color. Its fields are set according to `LV_COLOR_DEPTH` in `lv_conf.h`. (See below)
|
||||
|
||||
You may set `LV_COLOR_16_SWAP` in `lv_conf.h` to swap bytes of *RGB565* colors. You may need this when sending 16-bit colors via a byte-oriented interface like SPI. As 16-bit numbers are stored in little-endian format (lower byte at the lower address), the interface will send the lower byte first. However, displays usually need the higher byte first. A mismatch in the byte order will result in highly distorted colors.
|
||||
|
||||
## Creating colors
|
||||
|
||||
### RGB
|
||||
Create colors from Red, Green and Blue channel values:
|
||||
```c
|
||||
//All channels are 0-255
|
||||
lv_color_t c = lv_color_make(red, green, blue);
|
||||
|
||||
//From hex code 0x000000..0xFFFFFF interpreted as RED + GREEN + BLUE
|
||||
lv_color_t c = lv_color_hex(0x123456);
|
||||
|
||||
//From 3 digits. Same as lv_color_hex(0x112233)
|
||||
lv_color_t c = lv_color_hex3(0x123);
|
||||
```
|
||||
|
||||
### HSV
|
||||
Create colors from Hue, Saturation and Value values:
|
||||
|
||||
```c
|
||||
//h = 0..359, s = 0..100, v = 0..100
|
||||
lv_color_t c = lv_color_hsv_to_rgb(h, s, v);
|
||||
|
||||
//All channels are 0-255
|
||||
lv_color_hsv_t c_hsv = lv_color_rgb_to_hsv(r, g, b);
|
||||
|
||||
|
||||
//From lv_color_t variable
|
||||
lv_color_hsv_t c_hsv = lv_color_to_hsv(color);
|
||||
```
|
||||
|
||||
### Palette
|
||||
LVGL includes [Material Design's palette](https://vuetifyjs.com/en/styles/colors/#material-colors) of colors. In this system all named colors have a nominal main color as well as four darker and five lighter variants.
|
||||
|
||||
The names of the colors are as follows:
|
||||
- `LV_PALETTE_RED`
|
||||
- `LV_PALETTE_PINK`
|
||||
- `LV_PALETTE_PURPLE`
|
||||
- `LV_PALETTE_DEEP_PURPLE`
|
||||
- `LV_PALETTE_INDIGO`
|
||||
- `LV_PALETTE_BLUE`
|
||||
- `LV_PALETTE_LIGHT_BLUE`
|
||||
- `LV_PALETTE_CYAN`
|
||||
- `LV_PALETTE_TEAL`
|
||||
- `LV_PALETTE_GREEN`
|
||||
- `LV_PALETTE_LIGHT_GREEN`
|
||||
- `LV_PALETTE_LIME`
|
||||
- `LV_PALETTE_YELLOW`
|
||||
- `LV_PALETTE_AMBER`
|
||||
- `LV_PALETTE_ORANGE`
|
||||
- `LV_PALETTE_DEEP_ORANGE`
|
||||
- `LV_PALETTE_BROWN`
|
||||
- `LV_PALETTE_BLUE_GREY`
|
||||
- `LV_PALETTE_GREY`
|
||||
|
||||
|
||||
To get the main color use `lv_color_t c = lv_palette_main(LV_PALETTE_...)`.
|
||||
|
||||
For the lighter variants of a palette color use `lv_color_t c = lv_palette_lighten(LV_PALETTE_..., v)`. `v` can be 1..5.
|
||||
For the darker variants of a palette color use `lv_color_t c = lv_palette_darken(LV_PALETTE_..., v)`. `v` can be 1..4.
|
||||
|
||||
### Modify and mix colors
|
||||
The following functions can modify a color:
|
||||
```c
|
||||
// Lighten a color. 0: no change, 255: white
|
||||
lv_color_t c = lv_color_lighten(c, lvl);
|
||||
|
||||
// Darken a color. 0: no change, 255: black
|
||||
lv_color_t c = lv_color_darken(lv_color_t c, lv_opa_t lvl);
|
||||
|
||||
// Lighten or darken a color. 0: black, 128: no change 255: white
|
||||
lv_color_t c = lv_color_change_lightness(lv_color_t c, lv_opa_t lvl);
|
||||
|
||||
|
||||
// Mix two colors with a given ratio 0: full c2, 255: full c1, 128: half c1 and half c2
|
||||
lv_color_t c = lv_color_mix(c1, c2, ratio);
|
||||
```
|
||||
|
||||
### Built-in colors
|
||||
`lv_color_white()` and `lv_color_black()` return `0xFFFFFF` and `0x000000` respectively.
|
||||
|
||||
## Opacity
|
||||
To describe opacity the `lv_opa_t` type is created from `uint8_t`. Some special purpose defines are also introduced:
|
||||
|
||||
- `LV_OPA_TRANSP` Value: 0, means no opacity making the color completely transparent
|
||||
- `LV_OPA_10` Value: 25, means the color covers only a little
|
||||
- `LV_OPA_20 ... OPA_80` follow logically
|
||||
- `LV_OPA_90` Value: 229, means the color near completely covers
|
||||
- `LV_OPA_COVER` Value: 255, means the color completely covers (full opacity)
|
||||
|
||||
You can also use the `LV_OPA_*` defines in `lv_color_mix()` as a mixing *ratio*.
|
||||
|
||||
|
||||
## Color types
|
||||
The following variable types are defined by the color module:
|
||||
|
||||
- `lv_color1_t` Monochrome color. Also has R, G, B fields for compatibility but they are always the same value (1 byte)
|
||||
- `lv_color8_t` A structure to store R (3 bit),G (3 bit),B (2 bit) components for 8-bit colors (1 byte)
|
||||
- `lv_color16_t` A structure to store R (5 bit),G (6 bit),B (5 bit) components for 16-bit colors (2 byte)
|
||||
- `lv_color32_t` A structure to store R (8 bit),G (8 bit), B (8 bit) components for 24-bit colors (4 byte)
|
||||
- `lv_color_t` Equal to `lv_color1/8/16/24_t` depending on the configured color depth setting
|
||||
- `lv_color_int_t` `uint8_t`, `uint16_t` or `uint32_t` depending on the color depth setting. Used to build color arrays from plain numbers.
|
||||
- `lv_opa_t` A simple `uint8_t` type to describe opacity.
|
||||
|
||||
The `lv_color_t`, `lv_color1_t`, `lv_color8_t`, `lv_color16_t` and `lv_color32_t` types have four fields:
|
||||
|
||||
- `ch.red` red channel
|
||||
- `ch.green` green channel
|
||||
- `ch.blue` blue channel
|
||||
- `full*` red + green + blue as one number
|
||||
|
||||
You can set the current color depth in *lv_conf.h*, by setting the `LV_COLOR_DEPTH` define to 1 (monochrome), 8, 16 or 32.
|
||||
|
||||
|
||||
### Convert color
|
||||
You can convert a color from the current color depth to another. The converter functions return with a number, so you have to use the `full` field to map a converted color back into a structure:
|
||||
|
||||
```c
|
||||
lv_color_t c;
|
||||
c.red = 0x38;
|
||||
c.green = 0x70;
|
||||
c.blue = 0xCC;
|
||||
|
||||
lv_color1_t c1;
|
||||
c1.full = lv_color_to1(c); /*Return 1 for light colors, 0 for dark colors*/
|
||||
|
||||
lv_color8_t c8;
|
||||
c8.full = lv_color_to8(c); /*Give a 8 bit number with the converted color*/
|
||||
|
||||
lv_color16_t c16;
|
||||
c16.full = lv_color_to16(c); /*Give a 16 bit number with the converted color*/
|
||||
|
||||
lv_color32_t c24;
|
||||
c32.full = lv_color_to32(c); /*Give a 32 bit number with the converted color*/
|
||||
```
|
||||
|
||||
|
||||
## API
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_color.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
367
LVGL.Simulator/lvgl/docs/overview/coords.md
Normal file
@@ -0,0 +1,367 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/coords.md
|
||||
```
|
||||
# Positions, sizes, and layouts
|
||||
|
||||
## Overview
|
||||
Similarly to many other parts of LVGL, the concept of setting the coordinates was inspired by CSS. LVGL has by no means a complete implementation of CSS but a comparable subset is implemented (sometimes with minor adjustments).
|
||||
|
||||
In short this means:
|
||||
- Explicitly set coordinates are stored in styles (size, position, layouts, etc.)
|
||||
- support min-width, max-width, min-height, max-height
|
||||
- have pixel, percentage, and "content" units
|
||||
- x=0; y=0 coordinate means the top-left corner of the parent plus the left/top padding plus border width
|
||||
- width/height means the full size, the "content area" is smaller with padding and border width
|
||||
- a subset of flexbox and grid layouts are supported
|
||||
|
||||
### Units
|
||||
- pixel: Simply a position in pixels. An integer always means pixels. E.g. `lv_obj_set_x(btn, 10)`
|
||||
- percentage: The percentage of the size of the object or its parent (depending on the property). `lv_pct(value)` converts a value to percentage. E.g. `lv_obj_set_width(btn, lv_pct(50))`
|
||||
- `LV_SIZE_CONTENT`: Special value to set the width/height of an object to involve all the children. It's similar to `auto` in CSS. E.g. `lv_obj_set_width(btn, LV_SIZE_CONTENT)`.
|
||||
|
||||
### Boxing model
|
||||
LVGL follows CSS's [border-box](https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing) model.
|
||||
An object's "box" is built from the following parts:
|
||||
- bounding box: the width/height of the elements.
|
||||
- border width: the width of the border.
|
||||
- padding: space between the sides of the object and its children.
|
||||
- content: the content area which is the size of the bounding box reduced by the border width and padding.
|
||||
|
||||

|
||||
|
||||
The border is drawn inside the bounding box. Inside the border LVGL keeps a "padding margin" when placing an object's children.
|
||||
|
||||
The outline is drawn outside the bounding box.
|
||||
|
||||
### Important notes
|
||||
This section describes special cases in which LVGL's behavior might be unexpected.
|
||||
|
||||
#### Postponed coordinate calculation
|
||||
LVGL doesn't recalculate all the coordinate changes immediately. This is done to improve performance.
|
||||
Instead, the objects are marked as "dirty" and before redrawing the screen LVGL checks if there are any "dirty" objects. If so it refreshes their position, size and layout.
|
||||
|
||||
In other words, if you need to get the coordinate of an object and the coordinates were just changed, LVGL needs to be forced to recalculate the coordinates.
|
||||
To do this call `lv_obj_update_layout(obj)`.
|
||||
|
||||
The size and position might depend on the parent or layout. Therefore `lv_obj_update_layout` recalculates the coordinates of all objects on the screen of `obj`.
|
||||
|
||||
#### Removing styles
|
||||
As it's described in the [Using styles](#using-styles) section, coordinates can also be set via style properties.
|
||||
To be more precise, under the hood every style coordinate related property is stored as a style property. If you use `lv_obj_set_x(obj, 20)` LVGL saves `x=20` in the local style of the object.
|
||||
|
||||
This is an internal mechanism and doesn't matter much as you use LVGL. However, there is one case in which you need to be aware of the implementation. If the style(s) of an object are removed by
|
||||
```c
|
||||
lv_obj_remove_style_all(obj)
|
||||
```
|
||||
|
||||
or
|
||||
```c
|
||||
lv_obj_remove_style(obj, NULL, LV_PART_MAIN);
|
||||
```
|
||||
the earlier set coordinates will be removed as well.
|
||||
|
||||
For example:
|
||||
```c
|
||||
/*The size of obj1 will be set back to the default in the end*/
|
||||
lv_obj_set_size(obj1, 200, 100); /*Now obj1 has 200;100 size*/
|
||||
lv_obj_remove_style_all(obj1); /*It removes the set sizes*/
|
||||
|
||||
|
||||
/*obj2 will have 200;100 size in the end */
|
||||
lv_obj_remove_style_all(obj2);
|
||||
lv_obj_set_size(obj2, 200, 100);
|
||||
```
|
||||
|
||||
## Position
|
||||
|
||||
### Simple way
|
||||
To simply set the x and y coordinates of an object use:
|
||||
```c
|
||||
lv_obj_set_x(obj, 10); //Separate...
|
||||
lv_obj_set_y(obj, 20);
|
||||
lv_obj_set_pos(obj, 10, 20); //Or in one function
|
||||
```
|
||||
|
||||
By default, the x and y coordinates are measured from the top left corner of the parent's content area.
|
||||
For example if the parent has five pixels of padding on every side the above code will place `obj` at (15, 25) because the content area starts after the padding.
|
||||
|
||||
Percentage values are calculated from the parent's content area size.
|
||||
```c
|
||||
lv_obj_set_x(btn, lv_pct(10)); //x = 10 % of parent content area width
|
||||
```
|
||||
|
||||
### Align
|
||||
In some cases it's convenient to change the origin of the positioning from the default top left. If the origin is changed e.g. to bottom-right, the (0,0) position means: align to the bottom-right corner.
|
||||
To change the origin use:
|
||||
```c
|
||||
lv_obj_set_align(obj, align);
|
||||
```
|
||||
|
||||
To change the alignment and set new coordinates:
|
||||
```c
|
||||
lv_obj_align(obj, align, x, y);
|
||||
```
|
||||
|
||||
The following alignment options can be used:
|
||||
- `LV_ALIGN_TOP_LEFT`
|
||||
- `LV_ALIGN_TOP_MID`
|
||||
- `LV_ALIGN_TOP_RIGHT`
|
||||
- `LV_ALIGN_BOTTOM_LEFT`
|
||||
- `LV_ALIGN_BOTTOM_MID`
|
||||
- `LV_ALIGN_BOTTOM_RIGHT`
|
||||
- `LV_ALIGN_LEFT_MID`
|
||||
- `LV_ALIGN_RIGHT_MID`
|
||||
- `LV_ALIGN_CENTER`
|
||||
|
||||
It's quite common to align a child to the center of its parent, therefore a dedicated function exists:
|
||||
```c
|
||||
lv_obj_center(obj);
|
||||
|
||||
//Has the same effect
|
||||
lv_obj_align(obj, LV_ALIGN_CENTER, 0, 0);
|
||||
```
|
||||
|
||||
If the parent's size changes, the set alignment and position of the children is updated automatically.
|
||||
|
||||
The functions introduced above align the object to its parent. However, it's also possible to align an object to an arbitrary reference object.
|
||||
```c
|
||||
lv_obj_align_to(obj_to_align, reference_obj, align, x, y);
|
||||
```
|
||||
|
||||
Besides the alignments options above, the following can be used to align an object outside the reference object:
|
||||
|
||||
- `LV_ALIGN_OUT_TOP_LEFT`
|
||||
- `LV_ALIGN_OUT_TOP_MID`
|
||||
- `LV_ALIGN_OUT_TOP_RIGHT`
|
||||
- `LV_ALIGN_OUT_BOTTOM_LEFT`
|
||||
- `LV_ALIGN_OUT_BOTTOM_MID`
|
||||
- `LV_ALIGN_OUT_BOTTOM_RIGHT`
|
||||
- `LV_ALIGN_OUT_LEFT_TOP`
|
||||
- `LV_ALIGN_OUT_LEFT_MID`
|
||||
- `LV_ALIGN_OUT_LEFT_BOTTOM`
|
||||
- `LV_ALIGN_OUT_RIGHT_TOP`
|
||||
- `LV_ALIGN_OUT_RIGHT_MID`
|
||||
- `LV_ALIGN_OUT_RIGHT_BOTTOM`
|
||||
|
||||
For example to align a label above a button and center the label horizontally:
|
||||
```c
|
||||
lv_obj_align_to(label, btn, LV_ALIGN_OUT_TOP_MID, 0, -10);
|
||||
```
|
||||
|
||||
Note that, unlike with `lv_obj_align()`, `lv_obj_align_to()` can not realign the object if its coordinates or the reference object's coordinates change.
|
||||
|
||||
## Size
|
||||
|
||||
### Simple way
|
||||
The width and the height of an object can be set easily as well:
|
||||
```c
|
||||
lv_obj_set_width(obj, 200); //Separate...
|
||||
lv_obj_set_height(obj, 100);
|
||||
lv_obj_set_size(obj, 200, 100); //Or in one function
|
||||
```
|
||||
|
||||
Percentage values are calculated based on the parent's content area size. For example to set the object's height to the screen height:
|
||||
```c
|
||||
lv_obj_set_height(obj, lv_pct(100));
|
||||
```
|
||||
|
||||
The size settings support a special value: `LV_SIZE_CONTENT`. It means the object's size in the respective direction will be set to the size of its children.
|
||||
Note that only children on the right and bottom sides will be considered and children on the top and left remain cropped. This limitation makes the behavior more predictable.
|
||||
|
||||
Objects with `LV_OBJ_FLAG_HIDDEN` or `LV_OBJ_FLAG_FLOATING` will be ignored by the `LV_SIZE_CONTENT` calculation.
|
||||
|
||||
The above functions set the size of an object's bounding box but the size of the content area can be set as well. This means an object's bounding box will be enlarged with the addition of padding.
|
||||
```c
|
||||
lv_obj_set_content_width(obj, 50); //The actual width: padding left + 50 + padding right
|
||||
lv_obj_set_content_height(obj, 30); //The actual width: padding top + 30 + padding bottom
|
||||
```
|
||||
|
||||
The size of the bounding box and the content area can be retrieved with the following functions:
|
||||
```c
|
||||
lv_coord_t w = lv_obj_get_width(obj);
|
||||
lv_coord_t h = lv_obj_get_height(obj);
|
||||
lv_coord_t content_w = lv_obj_get_content_width(obj);
|
||||
lv_coord_t content_h = lv_obj_get_content_height(obj);
|
||||
```
|
||||
|
||||
## Using styles
|
||||
Under the hood the position, size and alignment properties are style properties.
|
||||
The above described "simple functions" hide the style related code for the sake of simplicity and set the position, size, and alignment properties in the local styles of the object.
|
||||
|
||||
However, using styles to set the coordinates has some great advantages:
|
||||
- It makes it easy to set the width/height/etc. for several objects together. E.g. make all the sliders 100x10 pixels sized.
|
||||
- It also makes possible to modify the values in one place.
|
||||
- The values can be partially overwritten by other styles. For example `style_btn` makes the object `100x50` by default but adding `style_full_width` overwrites only the width of the object.
|
||||
- The object can have different position or size depending on state. E.g. 100 px wide in `LV_STATE_DEFAULT` but 120 px in `LV_STATE_PRESSED`.
|
||||
- Style transitions can be used to make the coordinate changes smooth.
|
||||
|
||||
|
||||
Here are some examples to set an object's size using a style:
|
||||
```c
|
||||
static lv_style_t style;
|
||||
lv_style_init(&style);
|
||||
lv_style_set_width(&style, 100);
|
||||
|
||||
lv_obj_t * btn = lv_btn_create(lv_scr_act());
|
||||
lv_obj_add_style(btn, &style, LV_PART_MAIN);
|
||||
```
|
||||
|
||||
As you will see below there are some other great features of size and position setting.
|
||||
However, to keep the LVGL API lean, only the most common coordinate setting features have a "simple" version and the more complex features can be used via styles.
|
||||
|
||||
## Translation
|
||||
|
||||
Let's say the there are 3 buttons next to each other. Their position is set as described above.
|
||||
Now you want to move a button up a little when it's pressed.
|
||||
|
||||
One way to achieve this is by setting a new Y coordinate for the pressed state:
|
||||
```c
|
||||
static lv_style_t style_normal;
|
||||
lv_style_init(&style_normal);
|
||||
lv_style_set_y(&style_normal, 100);
|
||||
|
||||
static lv_style_t style_pressed;
|
||||
lv_style_init(&style_pressed);
|
||||
lv_style_set_y(&style_pressed, 80);
|
||||
|
||||
lv_obj_add_style(btn1, &style_normal, LV_STATE_DEFAULT);
|
||||
lv_obj_add_style(btn1, &style_pressed, LV_STATE_PRESSED);
|
||||
|
||||
lv_obj_add_style(btn2, &style_normal, LV_STATE_DEFAULT);
|
||||
lv_obj_add_style(btn2, &style_pressed, LV_STATE_PRESSED);
|
||||
|
||||
lv_obj_add_style(btn3, &style_normal, LV_STATE_DEFAULT);
|
||||
lv_obj_add_style(btn3, &style_pressed, LV_STATE_PRESSED);
|
||||
```
|
||||
|
||||
This works, but it's not really flexible because the pressed coordinate is hard-coded. If the buttons are not at y=100, `style_pressed` won't work as expected. Translations can be used to solve this:
|
||||
```c
|
||||
static lv_style_t style_normal;
|
||||
lv_style_init(&style_normal);
|
||||
lv_style_set_y(&style_normal, 100);
|
||||
|
||||
static lv_style_t style_pressed;
|
||||
lv_style_init(&style_pressed);
|
||||
lv_style_set_translate_y(&style_pressed, -20);
|
||||
|
||||
lv_obj_add_style(btn1, &style_normal, LV_STATE_DEFAULT);
|
||||
lv_obj_add_style(btn1, &style_pressed, LV_STATE_PRESSED);
|
||||
|
||||
lv_obj_add_style(btn2, &style_normal, LV_STATE_DEFAULT);
|
||||
lv_obj_add_style(btn2, &style_pressed, LV_STATE_PRESSED);
|
||||
|
||||
lv_obj_add_style(btn3, &style_normal, LV_STATE_DEFAULT);
|
||||
lv_obj_add_style(btn3, &style_pressed, LV_STATE_PRESSED);
|
||||
```
|
||||
|
||||
Translation is applied from the current position of the object.
|
||||
|
||||
Percentage values can be used in translations as well. The percentage is relative to the size of the object (and not to the size of the parent). For example `lv_pct(50)` will move the object with half of its width/height.
|
||||
|
||||
The translation is applied after the layouts are calculated. Therefore, even laid out objects' position can be translated.
|
||||
|
||||
The translation actually moves the object. That means it makes the scrollbars and `LV_SIZE_CONTENT` sized objects react to the position change.
|
||||
|
||||
|
||||
## Transformation
|
||||
Similarly to position, an object's size can be changed relative to the current size as well.
|
||||
The transformed width and height are added on both sides of the object. This means a 10 px transformed width makes the object 2x10 pixels wider.
|
||||
|
||||
Unlike position translation, the size transformation doesn't make the object "really" larger. In other words scrollbars, layouts, and `LV_SIZE_CONTENT` will not react to the transformed size.
|
||||
Hence, size transformation is "only" a visual effect.
|
||||
|
||||
This code enlarges a button when it's pressed:
|
||||
```c
|
||||
static lv_style_t style_pressed;
|
||||
lv_style_init(&style_pressed);
|
||||
lv_style_set_transform_width(&style_pressed, 10);
|
||||
lv_style_set_transform_height(&style_pressed, 10);
|
||||
|
||||
lv_obj_add_style(btn, &style_pressed, LV_STATE_PRESSED);
|
||||
```
|
||||
|
||||
### Min and Max size
|
||||
Similarly to CSS, LVGL also supports `min-width`, `max-width`, `min-height` and `max-height`. These are limits preventing an object's size from becoming smaller/larger than these values.
|
||||
They are especially useful if the size is set by percentage or `LV_SIZE_CONTENT`.
|
||||
```c
|
||||
static lv_style_t style_max_height;
|
||||
lv_style_init(&style_max_height);
|
||||
lv_style_set_y(&style_max_height, 200);
|
||||
|
||||
lv_obj_set_height(obj, lv_pct(100));
|
||||
lv_obj_add_style(obj, &style_max_height, LV_STATE_DEFAULT); //Limit the height to 200 px
|
||||
```
|
||||
|
||||
Percentage values can be used as well which are relative to the size of the parent's content area.
|
||||
```c
|
||||
static lv_style_t style_max_height;
|
||||
lv_style_init(&style_max_height);
|
||||
lv_style_set_y(&style_max_height, lv_pct(50));
|
||||
|
||||
lv_obj_set_height(obj, lv_pct(100));
|
||||
lv_obj_add_style(obj, &style_max_height, LV_STATE_DEFAULT); //Limit the height to half parent height
|
||||
```
|
||||
|
||||
## Layout
|
||||
|
||||
### Overview
|
||||
Layouts can update the position and size of an object's children. They can be used to automatically arrange the children into a line or column, or in much more complicated forms.
|
||||
|
||||
The position and size set by the layout overwrites the "normal" x, y, width, and height settings.
|
||||
|
||||
There is only one function that is the same for every layout: `lv_obj_set_layout(obj, <LAYOUT_NAME>)` sets the layout on an object.
|
||||
For further settings of the parent and children see the documentation of the given layout.
|
||||
|
||||
### Built-in layout
|
||||
LVGL comes with two very powerful layouts:
|
||||
- Flexbox
|
||||
- Grid
|
||||
|
||||
Both are heavily inspired by the CSS layouts with the same name.
|
||||
|
||||
### Flags
|
||||
There are some flags that can be used on objects to affect how they behave with layouts:
|
||||
- `LV_OBJ_FLAG_HIDDEN` Hidden objects are ignored in layout calculations.
|
||||
- `LV_OBJ_FLAG_IGNORE_LAYOUT` The object is simply ignored by the layouts. Its coordinates can be set as usual.
|
||||
- `LV_OBJ_FLAG_FLOATING` Same as `LV_OBJ_FLAG_IGNORE_LAYOUT` but the object with `LV_OBJ_FLAG_FLOATING` will be ignored in `LV_SIZE_CONTENT` calculations.
|
||||
|
||||
These flags can be added/removed with `lv_obj_add/clear_flag(obj, FLAG);`
|
||||
|
||||
### Adding new layouts
|
||||
|
||||
LVGL can be freely extended by a custom layout like this:
|
||||
```c
|
||||
uint32_t MY_LAYOUT;
|
||||
|
||||
...
|
||||
|
||||
MY_LAYOUT = lv_layout_register(my_layout_update, &user_data);
|
||||
|
||||
...
|
||||
|
||||
void my_layout_update(lv_obj_t * obj, void * user_data)
|
||||
{
|
||||
/*Will be called automatically if it's required to reposition/resize the children of "obj" */
|
||||
}
|
||||
```
|
||||
|
||||
Custom style properties can be added which can be retrieved and used in the update callback. For example:
|
||||
```c
|
||||
uint32_t MY_PROP;
|
||||
...
|
||||
|
||||
LV_STYLE_MY_PROP = lv_style_register_prop();
|
||||
|
||||
...
|
||||
static inline void lv_style_set_my_prop(lv_style_t * style, uint32_t value)
|
||||
{
|
||||
lv_style_value_t v = {
|
||||
.num = (int32_t)value
|
||||
};
|
||||
lv_style_set_prop(style, LV_STYLE_MY_PROP, v);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## Examples
|
||||
108
LVGL.Simulator/lvgl/docs/overview/display.md
Normal file
@@ -0,0 +1,108 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/display.md
|
||||
```
|
||||
# Displays
|
||||
|
||||
``` important:: The basic concept of a *display* in LVGL is explained in the [Porting](/porting/display) section. So before reading further, please read the [Porting](/porting/display) section first.
|
||||
```
|
||||
|
||||
## Multiple display support
|
||||
|
||||
In LVGL you can have multiple displays, each with their own driver and objects. The only limitation is that every display needs to have the same color depth (as defined in `LV_COLOR_DEPTH`).
|
||||
If the displays are different in this regard the rendered image can be converted to the correct format in the drivers `flush_cb`.
|
||||
|
||||
Creating more displays is easy: just initialize more display buffers and register another driver for every display.
|
||||
When you create the UI, use `lv_disp_set_default(disp)` to tell the library on which display to create objects.
|
||||
|
||||
Why would you want multi-display support? Here are some examples:
|
||||
- Have a "normal" TFT display with local UI and create "virtual" screens on VNC on demand. (You need to add your VNC driver).
|
||||
- Have a large TFT display and a small monochrome display.
|
||||
- Have some smaller and simple displays in a large instrument or technology.
|
||||
- Have two large TFT displays: one for a customer and one for the shop assistant.
|
||||
|
||||
### Using only one display
|
||||
Using more displays can be useful but in most cases it's not required. Therefore, the whole concept of multi-display handling is completely hidden if you register only one display.
|
||||
By default, the last created (and only) display is used.
|
||||
|
||||
`lv_scr_act()`, `lv_scr_load(scr)`, `lv_layer_top()`, `lv_layer_sys()`, `LV_HOR_RES` and `LV_VER_RES` are always applied on the most recently created (default) display.
|
||||
If you pass `NULL` as `disp` parameter to display related functions the default display will usually be used.
|
||||
E.g. `lv_disp_trig_activity(NULL)` will trigger a user activity on the default display. (See below in [Inactivity](#Inactivity)).
|
||||
|
||||
### Mirror display
|
||||
|
||||
To mirror the image of a display to another display, you don't need to use multi-display support. Just transfer the buffer received in `drv.flush_cb` to the other display too.
|
||||
|
||||
### Split image
|
||||
You can create a larger virtual display from an array of smaller ones. You can create it as below:
|
||||
1. Set the resolution of the displays to the large display's resolution.
|
||||
2. In `drv.flush_cb`, truncate and modify the `area` parameter for each display.
|
||||
3. Send the buffer's content to each real display with the truncated area.
|
||||
|
||||
## Screens
|
||||
|
||||
Every display has its own set of [screens](overview/object#screen-the-most-basic-parent) and the objects on each screen.
|
||||
|
||||
Be sure not to confuse displays and screens:
|
||||
|
||||
* **Displays** are the physical hardware drawing the pixels.
|
||||
* **Screens** are the high-level root objects associated with a particular display. One display can have multiple screens associated with it, but not vice versa.
|
||||
|
||||
Screens can be considered the highest level containers which have no parent.
|
||||
A screen's size is always equal to its display and their origin is (0;0). Therefore, a screen's coordinates can't be changed, i.e. `lv_obj_set_pos()`, `lv_obj_set_size()` or similar functions can't be used on screens.
|
||||
|
||||
A screen can be created from any object type but the two most typical types are [Base object](/widgets/obj) and [Image](/widgets/core/img) (to create a wallpaper).
|
||||
|
||||
To create a screen, use `lv_obj_t * scr = lv_<type>_create(NULL, copy)`. `copy` can be an existing screen copied into the new screen.
|
||||
|
||||
To load a screen, use `lv_scr_load(scr)`. To get the active screen, use `lv_scr_act()`. These functions work on the default display. If you want to specify which display to work on, use `lv_disp_get_scr_act(disp)` and `lv_disp_load_scr(disp, scr)`. A screen can be loaded with animations too. Read more [here](object.html#load-screens).
|
||||
|
||||
Screens can be deleted with `lv_obj_del(scr)`, but ensure that you do not delete the currently loaded screen.
|
||||
|
||||
### Transparent screens
|
||||
|
||||
Usually, the opacity of the screen is `LV_OPA_COVER` to provide a solid background for its children. If this is not the case (opacity < 100%) the display's background color or image will be visible.
|
||||
See the [Display background](#display-background) section for more details. If the display's background opacity is also not `LV_OPA_COVER` LVGL has no solid background to draw.
|
||||
|
||||
This configuration (transparent screen and display) could be used to create for example OSD menus where a video is played on a lower layer, and a menu is overlayed on an upper layer.
|
||||
|
||||
To handle transparent displays, special (slower) color mixing algorithms need to be used by LVGL so this feature needs to enabled with `LV_COLOR_SCREEN_TRANSP` in `lv_conf.h`.
|
||||
As this mode operates on the Alpha channel of the pixels `LV_COLOR_DEPTH = 32` is also required. The Alpha channel of 32-bit colors will be 0 where there are no objects and 255 where there are solid objects.
|
||||
|
||||
In summary, to enable transparent screens and displays for OSD menu-like UIs:
|
||||
- Enable `LV_COLOR_SCREEN_TRANSP` in `lv_conf.h`
|
||||
- Be sure to use `LV_COLOR_DEPTH 32`
|
||||
- Set the screen's opacity to `LV_OPA_TRANSP` e.g. with `lv_obj_set_style_local_bg_opa(lv_scr_act(), LV_OBJMASK_PART_MAIN, LV_STATE_DEFAULT, LV_OPA_TRANSP)`
|
||||
- Set the display opacity to `LV_OPA_TRANSP` with `lv_disp_set_bg_opa(NULL, LV_OPA_TRANSP);`
|
||||
|
||||
## Features of displays
|
||||
|
||||
### Inactivity
|
||||
|
||||
A user's inactivity time is measured on each display. Every use of an [Input device](/overview/indev) (if [associated with the display](/porting/indev#other-features)) counts as an activity.
|
||||
To get time elapsed since the last activity, use `lv_disp_get_inactive_time(disp)`. If `NULL` is passed, the lowest inactivity time among all displays will be returned (**NULL isn't just the default display**).
|
||||
|
||||
You can manually trigger an activity using `lv_disp_trig_activity(disp)`. If `disp` is `NULL`, the default screen will be used (**and not all displays**).
|
||||
|
||||
### Background
|
||||
Every display has a background color, background image and background opacity properties. They become visible when the current screen is transparent or not positioned to cover the whole display.
|
||||
|
||||
The background color is a simple color to fill the display. It can be adjusted with `lv_disp_set_bg_color(disp, color)`;
|
||||
|
||||
The display background image is a path to a file or a pointer to an `lv_img_dsc_t` variable (converted image data) to be used as wallpaper. It can be set with `lv_disp_set_bg_image(disp, &my_img)`;
|
||||
If a background image is configured the background won't be filled with `bg_color`.
|
||||
|
||||
The opacity of the background color or image can be adjusted with `lv_disp_set_bg_opa(disp, opa)`.
|
||||
|
||||
The `disp` parameter of these functions can be `NULL` to select the default display.
|
||||
|
||||
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_disp.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
225
LVGL.Simulator/lvgl/docs/overview/drawing.md
Normal file
@@ -0,0 +1,225 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/drawing.md
|
||||
```
|
||||
# Drawing
|
||||
|
||||
With LVGL, you don't need to draw anything manually. Just create objects (like buttons, labels, arc, etc.), move and change them, and LVGL will refresh and redraw what is required.
|
||||
|
||||
However, it can be useful to have a basic understanding of how drawing happens in LVGL to add customization, make it easier to find bugs or just out of curiosity.
|
||||
|
||||
The basic concept is to not draw directly onto the display but rather to first draw on an internal draw buffer. When a drawing (rendering) is ready that buffer is copied to the display.
|
||||
|
||||
The draw buffer can be smaller than a display's size. LVGL will simply render in "tiles" that fit into the given draw buffer.
|
||||
|
||||
This approach has two main advantages compared to directly drawing to the display:
|
||||
1. It avoids flickering while the layers of the UI are drawn. For example, if LVGL drew directly onto the display, when drawing a *background + button + text*, each "stage" would be visible for a short time.
|
||||
2. It's faster to modify a buffer in internal RAM and finally write one pixel only once than reading/writing the display directly on each pixel access.
|
||||
(e.g. via a display controller with SPI interface).
|
||||
|
||||
Note that this concept is different from "traditional" double buffering where there are two display sized frame buffers:
|
||||
one holds the current image to show on the display, and rendering happens to the other (inactive) frame buffer, and they are swapped when the rendering is finished.
|
||||
The main difference is that with LVGL you don't have to store two frame buffers (which usually requires external RAM) but only smaller draw buffer(s) that can easily fit into internal RAM.
|
||||
|
||||
|
||||
## Mechanism of screen refreshing
|
||||
|
||||
Be sure to get familiar with the [Buffering modes of LVGL](/porting/display) first.
|
||||
|
||||
LVGL refreshes the screen in the following steps:
|
||||
1. Something happens in the UI which requires redrawing. For example, a button is pressed, a chart is changed, an animation happened, etc.
|
||||
2. LVGL saves the changed object's old and new area into a buffer, called an *Invalid area buffer*. For optimization, in some cases, objects are not added to the buffer:
|
||||
- Hidden objects are not added.
|
||||
- Objects completely out of their parent are not added.
|
||||
- Areas partially out of the parent are cropped to the parent's area.
|
||||
- Objects on other screens are not added.
|
||||
3. In every `LV_DISP_DEF_REFR_PERIOD` (set in `lv_conf.h`) the following happens:
|
||||
- LVGL checks the invalid areas and joins those that are adjacent or intersecting.
|
||||
- Takes the first joined area, if it's smaller than the *draw buffer*, then simply renders the area's content into the *draw buffer*.
|
||||
If the area doesn't fit into the buffer, draw as many lines as possible to the *draw buffer*.
|
||||
- When the area is rendered, call `flush_cb` from the display driver to refresh the display.
|
||||
- If the area was larger than the buffer, render the remaining parts too.
|
||||
- Repeat the same with remaining joined areas.
|
||||
|
||||
When an area is redrawn the library searches the top-most object which covers that area and starts drawing from that object.
|
||||
For example, if a button's label has changed, the library will see that it's enough to draw the button under the text and it's not necessary to redraw the display under the rest of the button too.
|
||||
|
||||
The difference between buffering modes regarding the drawing mechanism is the following:
|
||||
1. **One buffer** - LVGL needs to wait for `lv_disp_flush_ready()` (called from `flush_cb`) before starting to redraw the next part.
|
||||
2. **Two buffers** - LVGL can immediately draw to the second buffer when the first is sent to `flush_cb` because the flushing should be done by DMA (or similar hardware) in the background.
|
||||
3. **Double buffering** - `flush_cb` should only swap the addresses of the frame buffers.
|
||||
|
||||
## Masking
|
||||
*Masking* is the basic concept of LVGL's draw engine.
|
||||
To use LVGL it's not required to know about the mechanisms described here but you might find interesting to know how drawing works under hood.
|
||||
Knowing about masking comes in handy if you want to customize drawing.
|
||||
|
||||
To learn about masking let's see the steps of drawing first.
|
||||
LVGL performs the following steps to render any shape, image or text. It can be considered as a drawing pipeline.
|
||||
|
||||
1. **Prepare the draw descriptors** Create a draw descriptor from an object's styles (e.g. `lv_draw_rect_dsc_t`). This gives us the parameters for drawing, for example colors, widths, opacity, fonts, radius, etc.
|
||||
2. **Call the draw function** Call the draw function with the draw descriptor and some other parameters (e.g. `lv_draw_rect()`). It will render the primitive shape to the current draw buffer.
|
||||
3. **Create masks** If the shape is very simple and doesn't require masks, go to #5. Otherwise, create the required masks in the draw function. (e.g. a rounded rectangle mask)
|
||||
4. **Calculate all the added mask** It composites opacity values into a *mask buffer* with the "shape" of the created masks.
|
||||
E.g. in case of a "line mask" according to the parameters of the mask, keep one side of the buffer as it is (255 by default) and set the rest to 0 to indicate that this side should be removed.
|
||||
5. **Blend a color or image** During blending, masking (make some pixels transparent or opaque), blending modes (additive, subtractive, etc.) and color/image opacity are handled.
|
||||
|
||||
LVGL has the following built-in mask types which can be calculated and applied real-time:
|
||||
- `LV_DRAW_MASK_TYPE_LINE` Removes a side from a line (top, bottom, left or right). `lv_draw_line` uses four instances of it.
|
||||
Essentially, every (skew) line is bounded with four line masks forming a rectangle.
|
||||
- `LV_DRAW_MASK_TYPE_RADIUS` Removes the inner or outer corners of a rectangle with a radiused transition. It's also used to create circles by setting the radius to large value (`LV_RADIUS_CIRCLE`)
|
||||
- `LV_DRAW_MASK_TYPE_ANGLE` Removes a circular sector. It is used by `lv_draw_arc` to remove the "empty" sector.
|
||||
- `LV_DRAW_MASK_TYPE_FADE` Create a vertical fade (change opacity)
|
||||
- `LV_DRAW_MASK_TYPE_MAP` The mask is stored in a bitmap array and the necessary parts are applied
|
||||
|
||||
Masks are used to create almost every basic primitive:
|
||||
- **letters** Create a mask from the letter and draw a rectangle with the letter's color using the mask.
|
||||
- **line** Created from four "line masks" to mask out the left, right, top and bottom part of the line to get a perfectly perpendicular perimeter.
|
||||
- **rounded rectangle** A mask is created real-time to add a radius to the corners.
|
||||
- **clip corner** To clip overflowing content (usually children) on rounded corners, a rounded rectangle mask is also applied.
|
||||
- **rectangle border** Same as a rounded rectangle but the inner part is masked out too.
|
||||
- **arc drawing** A circular border is drawn but an arc mask is applied too.
|
||||
- **ARGB images** The alpha channel is separated into a mask and the image is drawn as a normal RGB image.
|
||||
|
||||
### Using masks
|
||||
|
||||
Every mask type has a related parameter structure to describe the mask's data. The following parameter types exist:
|
||||
- `lv_draw_mask_line_param_t`
|
||||
- `lv_draw_mask_radius_param_t`
|
||||
- `lv_draw_mask_angle_param_t`
|
||||
- `lv_draw_mask_fade_param_t`
|
||||
- `lv_draw_mask_map_param_t`
|
||||
|
||||
1. Initialize a mask parameter with `lv_draw_mask_<type>_init`. See `lv_draw_mask.h` for the whole API.
|
||||
2. Add the mask parameter to the draw engine with `int16_t mask_id = lv_draw_mask_add(¶m, ptr)`. `ptr` can be any pointer to identify the mask, (`NULL` if unused).
|
||||
3. Call the draw functions
|
||||
4. Remove the mask from the draw engine with `lv_draw_mask_remove_id(mask_id)` or `lv_draw_mask_remove_custom(ptr)`.
|
||||
5. Free the parameter with `lv_draw_mask_free_param(¶m)`.
|
||||
|
||||
A parameter can be added and removed any number of times, but it needs to be freed when not required anymore.
|
||||
|
||||
`lv_draw_mask_add` saves only the pointer of the mask so the parameter needs to be valid while in use.
|
||||
|
||||
## Hook drawing
|
||||
Although widgets can be easily customized by styles there might be cases when something more custom is required.
|
||||
To ensure a great level of flexibility LVGL sends a lot of events during drawing with parameters that tell what LVGL is about to draw.
|
||||
Some fields of these parameters can be modified to draw something else or any custom drawing operations can be added manually.
|
||||
|
||||
A good use case for this is the [Button matrix](/widgets/core/btnmatrix) widget. By default, its buttons can be styled in different states, but you can't style the buttons one by one.
|
||||
However, an event is sent for every button and you can, for example, tell LVGL to use different colors on a specific button or to manually draw an image on some buttons.
|
||||
|
||||
Each of these events is described in detail below.
|
||||
|
||||
### Main drawing
|
||||
|
||||
These events are related to the actual drawing of an object. E.g. the drawing of buttons, texts, etc. happens here.
|
||||
|
||||
`lv_event_get_clip_area(event)` can be used to get the current clip area. The clip area is required in draw functions to make them draw only on a limited area.
|
||||
|
||||
#### LV_EVENT_DRAW_MAIN_BEGIN
|
||||
|
||||
Sent before starting to draw an object. This is a good place to add masks manually. E.g. add a line mask that "removes" the right side of an object.
|
||||
|
||||
#### LV_EVENT_DRAW_MAIN
|
||||
|
||||
The actual drawing of an object happens in this event. E.g. a rectangle for a button is drawn here. First, the widgets' internal events are called to perform drawing and after that you can draw anything on top of them.
|
||||
For example you can add a custom text or an image.
|
||||
|
||||
#### LV_EVENT_DRAW_MAIN_END
|
||||
|
||||
Called when the main drawing is finished. You can draw anything here as well and it's also a good place to remove any masks created in `LV_EVENT_DRAW_MAIN_BEGIN`.
|
||||
|
||||
### Post drawing
|
||||
|
||||
Post drawing events are called when all the children of an object are drawn. For example LVGL use the post drawing phase to draw scrollbars because they should be above all of the children.
|
||||
|
||||
`lv_event_get_clip_area(event)` can be used to get the current clip area.
|
||||
|
||||
#### LV_EVENT_DRAW_POST_BEGIN
|
||||
|
||||
Sent before starting the post draw phase. Masks can be added here too to mask out the post drawn content.
|
||||
|
||||
#### LV_EVENT_DRAW_POST
|
||||
|
||||
The actual drawing should happen here.
|
||||
|
||||
#### LV_EVENT_DRAW_POST_END
|
||||
|
||||
Called when post drawing has finished. If masks were not removed in `LV_EVENT_DRAW_MAIN_END` they should be removed here.
|
||||
|
||||
### Part drawing
|
||||
|
||||
When LVGL draws a part of an object (e.g. a slider's indicator, a table's cell or a button matrix's button) it sends events before and after drawing that part with some context of the drawing.
|
||||
This allows changing the parts on a very low level with masks, extra drawing, or changing the parameters that LVGL is planning to use for drawing.
|
||||
|
||||
In these events an `lv_obj_draw_part_t` structure is used to describe the context of the drawing. Not all fields are set for every part and widget.
|
||||
To see which fields are set for a widget refer to the widget's documentation.
|
||||
|
||||
`lv_obj_draw_part_t` has the following fields:
|
||||
|
||||
```c
|
||||
// Always set
|
||||
const lv_area_t * clip_area; // The current clip area, required if you need to draw something in the event
|
||||
uint32_t part; // The current part for which the event is sent
|
||||
uint32_t id; // The index of the part. E.g. a button's index on button matrix or table cell index.
|
||||
|
||||
// Draw desciptors, set only if related
|
||||
lv_draw_rect_dsc_t * rect_dsc; // A draw descriptor that can be modified to changed what LVGL will draw. Set only for rectangle-like parts
|
||||
lv_draw_label_dsc_t * label_dsc; // A draw descriptor that can be modified to changed what LVGL will draw. Set only for text-like parts
|
||||
lv_draw_line_dsc_t * line_dsc; // A draw descriptor that can be modified to changed what LVGL will draw. Set only for line-like parts
|
||||
lv_draw_img_dsc_t * img_dsc; // A draw descriptor that can be modified to changed what LVGL will draw. Set only for image-like parts
|
||||
lv_draw_arc_dsc_t * arc_dsc; // A draw descriptor that can be modified to changed what LVGL will draw. Set only for arc-like parts
|
||||
|
||||
// Other parameters
|
||||
lv_area_t * draw_area; // The area of the part being drawn
|
||||
const lv_point_t * p1; // A point calculated during drawing. E.g. a point of a chart or the center of an arc.
|
||||
const lv_point_t * p2; // A point calculated during drawing. E.g. a point of a chart.
|
||||
char text[16]; // A text calculated during drawing. Can be modified. E.g. tick labels on a chart axis.
|
||||
lv_coord_t radius; // E.g. the radius of an arc (not the corner radius).
|
||||
int32_t value; // A value calculated during drawing. E.g. Chart's tick line value.
|
||||
const void * sub_part_ptr; // A pointer the identifies something in the part. E.g. chart series.
|
||||
```
|
||||
|
||||
`lv_event_get_draw_part_dsc(event)` can be used to get a pointer to `lv_obj_draw_part_t`.
|
||||
|
||||
#### LV_EVENT_DRAW_PART_BEGIN
|
||||
|
||||
Start the drawing of a part. This is a good place to modify the draw descriptors (e.g. `rect_dsc`), or add masks.
|
||||
|
||||
#### LV_EVENT_DRAW_PART_END
|
||||
|
||||
Finish the drawing of a part. This is a good place to draw extra content on the part or remove masks added in `LV_EVENT_DRAW_PART_BEGIN`.
|
||||
|
||||
### Others
|
||||
|
||||
#### LV_EVENT_COVER_CHECK
|
||||
|
||||
This event is used to check whether an object fully covers an area or not.
|
||||
|
||||
`lv_event_get_cover_area(event)` returns a pointer to an area to check and `lv_event_set_cover_res(event, res)` can be used to set one of these results:
|
||||
- `LV_COVER_RES_COVER` the area is fully covered by the object
|
||||
- `LV_COVER_RES_NOT_COVER` the area is not covered by the object
|
||||
- `LV_COVER_RES_MASKED` there is a mask on the object, so it does not fully cover the area
|
||||
|
||||
Here are some reasons why an object would be unable to fully cover an area:
|
||||
- It's simply not fully in area
|
||||
- It has a radius
|
||||
- It doesn't have 100% background opacity
|
||||
- It's an ARGB or chroma keyed image
|
||||
- It does not have normal blending mode. In this case LVGL needs to know the colors under the object to apply blending properly
|
||||
- It's a text, etc
|
||||
|
||||
In short if for any reason the area below an object is visible than the object doesn't cover that area.
|
||||
|
||||
Before sending this event LVGL checks if at least the widget's coordinates fully cover the area or not. If not the event is not called.
|
||||
|
||||
You need to check only the drawing you have added. The existing properties known by a widget are handled in its internal events.
|
||||
E.g. if a widget has > 0 radius it might not cover an area, but you need to handle `radius` only if you will modify it and the widget won't know about it.
|
||||
|
||||
#### LV_EVENT_REFR_EXT_DRAW_SIZE
|
||||
|
||||
If you need to draw outside a widget, LVGL needs to know about it to provide extra space for drawing.
|
||||
Let's say you create an event which writes the current value of a slider above its knob. In this case LVGL needs to know that the slider's draw area should be larger with the size required for the text.
|
||||
|
||||
You can simply set the required draw area with `lv_event_set_ext_draw_size(e, size)`.
|
||||
|
||||
177
LVGL.Simulator/lvgl/docs/overview/event.md
Normal file
@@ -0,0 +1,177 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/event.md
|
||||
```
|
||||
# Events
|
||||
|
||||
Events are triggered in LVGL when something happens which might be interesting to the user, e.g. when an object
|
||||
- is clicked
|
||||
- is scrolled
|
||||
- has its value changed
|
||||
- is redrawn, etc.
|
||||
|
||||
## Add events to the object
|
||||
|
||||
The user can assign callback functions to an object to see its events. In practice, it looks like this:
|
||||
```c
|
||||
lv_obj_t * btn = lv_btn_create(lv_scr_act());
|
||||
lv_obj_add_event_cb(btn, my_event_cb, LV_EVENT_CLICKED, NULL); /*Assign an event callback*/
|
||||
|
||||
...
|
||||
|
||||
static void my_event_cb(lv_event_t * event)
|
||||
{
|
||||
printf("Clicked\n");
|
||||
}
|
||||
```
|
||||
In the example `LV_EVENT_CLICKED` means that only the click event will call `my_event_cb`. See the [list of event codes](#event-codes) for all the options.
|
||||
`LV_EVENT_ALL` can be used to receive all events.
|
||||
|
||||
The last parameter of `lv_obj_add_event_cb` is a pointer to any custom data that will be available in the event. It will be described later in more detail.
|
||||
|
||||
More events can be added to an object, like this:
|
||||
```c
|
||||
lv_obj_add_event_cb(obj, my_event_cb_1, LV_EVENT_CLICKED, NULL);
|
||||
lv_obj_add_event_cb(obj, my_event_cb_2, LV_EVENT_PRESSED, NULL);
|
||||
lv_obj_add_event_cb(obj, my_event_cb_3, LV_EVENT_ALL, NULL); /*No filtering, receive all events*/
|
||||
```
|
||||
|
||||
Even the same event callback can be used on an object with different `user_data`. For example:
|
||||
```c
|
||||
lv_obj_add_event_cb(obj, increment_on_click, LV_EVENT_CLICKED, &num1);
|
||||
lv_obj_add_event_cb(obj, increment_on_click, LV_EVENT_CLICKED, &num2);
|
||||
```
|
||||
|
||||
The events will be called in the order as they were added.
|
||||
|
||||
|
||||
Other objects can use the same *event callback*.
|
||||
|
||||
|
||||
## Remove event(s) from an object
|
||||
|
||||
Events can be removed from an object with the `lv_obj_remove_event_cb(obj, event_cb)` function or `lv_obj_remove_event_dsc(obj, event_dsc)`. `event_dsc` is a pointer returned by `lv_obj_add_event_cb`.
|
||||
|
||||
## Event codes
|
||||
|
||||
The event codes can be grouped into these categories:
|
||||
- Input device events
|
||||
- Drawing events
|
||||
- Other events
|
||||
- Special events
|
||||
- Custom events
|
||||
|
||||
All objects (such as Buttons/Labels/Sliders etc.) regardless their type receive the *Input device*, *Drawing* and *Other* events.
|
||||
|
||||
However, the *Special events* are specific to a particular widget type. See the [widgets' documentation](/widgets/index) to learn when they are sent,
|
||||
|
||||
*Custom events* are added by the user and are never sent by LVGL.
|
||||
|
||||
The following event codes exist:
|
||||
|
||||
### Input device events
|
||||
- `LV_EVENT_PRESSED` An object has been pressed
|
||||
- `LV_EVENT_PRESSING` An object is being pressed (called continuously while pressing)
|
||||
- `LV_EVENT_PRESS_LOST` An object is still being pressed but slid cursor/finger off of the object
|
||||
- `LV_EVENT_SHORT_CLICKED` An object was pressed for a short period of time, then released. Not called if scrolled.
|
||||
- `LV_EVENT_LONG_PRESSED` An object has been pressed for at least the `long_press_time` specified in the input device driver. Not called if scrolled.
|
||||
- `LV_EVENT_LONG_PRESSED_REPEAT` Called after `long_press_time` in every `long_press_repeat_time` ms. Not called if scrolled.
|
||||
- `LV_EVENT_CLICKED` Called on release if an object did not scroll (regardless of long press)
|
||||
- `LV_EVENT_RELEASED` Called in every case when an object has been released
|
||||
- `LV_EVENT_SCROLL_BEGIN` Scrolling begins. The event parameter is `NULL` or an `lv_anim_t *` with a scroll animation descriptor that can be modified if required.
|
||||
- `LV_EVENT_SCROLL_END` Scrolling ends.
|
||||
- `LV_EVENT_SCROLL` An object was scrolled
|
||||
- `LV_EVENT_GESTURE` A gesture is detected. Get the gesture with `lv_indev_get_gesture_dir(lv_indev_get_act());`
|
||||
- `LV_EVENT_KEY` A key is sent to an object. Get the key with `lv_indev_get_key(lv_indev_get_act());`
|
||||
- `LV_EVENT_FOCUSED` An object is focused
|
||||
- `LV_EVENT_DEFOCUSED` An object is unfocused
|
||||
- `LV_EVENT_LEAVE` An object is unfocused but still selected
|
||||
- `LV_EVENT_HIT_TEST` Perform advanced hit-testing. Use `lv_hit_test_info_t * a = lv_event_get_hit_test_info(e)` and check if `a->point` can click the object or not. If not set `a->res = false`
|
||||
|
||||
|
||||
### Drawing events
|
||||
- `LV_EVENT_COVER_CHECK` Check if an object fully covers an area. The event parameter is `lv_cover_check_info_t *`.
|
||||
- `LV_EVENT_REFR_EXT_DRAW_SIZE` Get the required extra draw area around an object (e.g. for a shadow). The event parameter is `lv_coord_t *` to store the size. Only overwrite it with a larger value.
|
||||
- `LV_EVENT_DRAW_MAIN_BEGIN` Starting the main drawing phase.
|
||||
- `LV_EVENT_DRAW_MAIN` Perform the main drawing
|
||||
- `LV_EVENT_DRAW_MAIN_END` Finishing the main drawing phase
|
||||
- `LV_EVENT_DRAW_POST_BEGIN` Starting the post draw phase (when all children are drawn)
|
||||
- `LV_EVENT_DRAW_POST` Perform the post draw phase (when all children are drawn)
|
||||
- `LV_EVENT_DRAW_POST_END` Finishing the post draw phase (when all children are drawn)
|
||||
- `LV_EVENT_DRAW_PART_BEGIN` Starting to draw a part. The event parameter is `lv_obj_draw_dsc_t *`. Learn more [here](/overview/drawing).
|
||||
- `LV_EVENT_DRAW_PART_END` Finishing to draw a part. The event parameter is `lv_obj_draw_dsc_t *`. Learn more [here](/overview/drawing).
|
||||
|
||||
In `LV_EVENT_DRAW_...` events it's not allowed to adjust the widgets' properties. E.g. you can not call `lv_obj_set_width()`.
|
||||
In other words only `get` functions can be called.
|
||||
|
||||
### Other events
|
||||
- `LV_EVENT_DELETE` Object is being deleted
|
||||
- `LV_EVENT_CHILD_CHANGED` Child was removed/added
|
||||
- `LV_EVENT_CHILD_CREATED` Child was created, always bubbles up to all parents
|
||||
- `LV_EVENT_CHILD_DELETED` Child was deleted, always bubbles up to all parents
|
||||
- `LV_EVENT_SIZE_CHANGED` Object coordinates/size have changed
|
||||
- `LV_EVENT_STYLE_CHANGED` Object's style has changed
|
||||
- `LV_EVENT_BASE_DIR_CHANGED` The base dir has changed
|
||||
- `LV_EVENT_GET_SELF_SIZE` Get the internal size of a widget
|
||||
- `LV_EVENT_SCREEN_UNLOAD_START` A screen unload started, fired immediately when lv_scr_load/lv_scr_load_anim is called
|
||||
- `LV_EVENT_SCREEN_LOAD_START` A screen load started, fired when the screen change delay is expired
|
||||
- `LV_EVENT_SCREEN_LOADED` A screen was loaded, called when all animations are finished
|
||||
- `LV_EVENT_SCREEN_UNLOADED` A screen was unloaded, called when all animations are finished
|
||||
|
||||
### Special events
|
||||
- `LV_EVENT_VALUE_CHANGED` The object's value has changed (i.e. slider moved)
|
||||
- `LV_EVENT_INSERT` Text is being inserted into the object. The event data is `char *` being inserted.
|
||||
- `LV_EVENT_REFRESH` Notify the object to refresh something on it (for the user)
|
||||
- `LV_EVENT_READY` A process has finished
|
||||
- `LV_EVENT_CANCEL` A process has been canceled
|
||||
|
||||
|
||||
### Custom events
|
||||
Any custom event codes can be registered by `uint32_t MY_EVENT_1 = lv_event_register_id();`
|
||||
|
||||
They can be sent to any object with `lv_event_send(obj, MY_EVENT_1, &some_data)`
|
||||
|
||||
## Sending events
|
||||
|
||||
To manually send events to an object, use `lv_event_send(obj, <EVENT_CODE> &some_data)`.
|
||||
|
||||
For example, this can be used to manually close a message box by simulating a button press (although there are simpler ways to do this):
|
||||
```c
|
||||
/*Simulate the press of the first button (indexes start from zero)*/
|
||||
uint32_t btn_id = 0;
|
||||
lv_event_send(mbox, LV_EVENT_VALUE_CHANGED, &btn_id);
|
||||
```
|
||||
|
||||
### Refresh event
|
||||
|
||||
`LV_EVENT_REFRESH` is a special event because it's designed to let the user notify an object to refresh itself. Some examples:
|
||||
- notify a label to refresh its text according to one or more variables (e.g. current time)
|
||||
- refresh a label when the language changes
|
||||
- enable a button if some conditions are met (e.g. the correct PIN is entered)
|
||||
- add/remove styles to/from an object if a limit is exceeded, etc
|
||||
|
||||
## Fields of lv_event_t
|
||||
|
||||
`lv_event_t` is the only parameter passed to the event callback and it contains all data about the event. The following values can be gotten from it:
|
||||
- `lv_event_get_code(e)` get the event code
|
||||
- `lv_event_get_current_target(e)` get the object to which an event was sent. I.e. the object whose event handler is being called.
|
||||
- `lv_event_get_target(e)` get the object that originally triggered the event (different from `lv_event_get_target` if [event bubbling](#event-bubbling) is enabled)
|
||||
- `lv_event_get_user_data(e)` get the pointer passed as the last parameter of `lv_obj_add_event_cb`.
|
||||
- `lv_event_get_param(e)` get the parameter passed as the last parameter of `lv_event_send`
|
||||
|
||||
|
||||
## Event bubbling
|
||||
|
||||
If `lv_obj_add_flag(obj, LV_OBJ_FLAG_EVENT_BUBBLE)` is enabled all events will be sent to an object's parent too. If the parent also has `LV_OBJ_FLAG_EVENT_BUBBLE` enabled the event will be sent to its parent and so on.
|
||||
|
||||
The *target* parameter of the event is always the current target object, not the original object. To get the original target call `lv_event_get_original_target(e)` in the event handler.
|
||||
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. include:: ../../examples/event/index.rst
|
||||
|
||||
```
|
||||
135
LVGL.Simulator/lvgl/docs/overview/file-system.md
Normal file
@@ -0,0 +1,135 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/file-system.md
|
||||
```
|
||||
# File system
|
||||
|
||||
LVGL has a 'File system' abstraction module that enables you to attach any type of file system.
|
||||
A file system is identified by an assigned drive letter.
|
||||
For example, if an SD card is associated with the letter `'S'`, a file can be reached using `"S:path/to/file.txt"`.
|
||||
|
||||
## Ready to use drivers
|
||||
The [lv_fs_if](https://github.com/lvgl/lv_fs_if) repository contains prepared drivers using POSIX, standard C and the [FATFS](http://elm-chan.org/fsw/ff/00index_e.html) API.
|
||||
See its [README](https://github.com/lvgl/lv_fs_if#readme) for the details.
|
||||
|
||||
## Adding a driver
|
||||
|
||||
### Registering a driver
|
||||
To add a driver, a `lv_fs_drv_t` needs to be initialized like below. The `lv_fs_drv_t` needs to be static, global or dynamically allocated and not a local variable.
|
||||
```c
|
||||
static lv_fs_drv_t drv; /*Needs to be static or global*/
|
||||
lv_fs_drv_init(&drv); /*Basic initialization*/
|
||||
|
||||
drv.letter = 'S'; /*An uppercase letter to identify the drive */
|
||||
drv.cache_size = my_cache_size; /*Cache size for reading in bytes. 0 to not cache.*/
|
||||
|
||||
drv.ready_cb = my_ready_cb; /*Callback to tell if the drive is ready to use */
|
||||
drv.open_cb = my_open_cb; /*Callback to open a file */
|
||||
drv.close_cb = my_close_cb; /*Callback to close a file */
|
||||
drv.read_cb = my_read_cb; /*Callback to read a file */
|
||||
drv.write_cb = my_write_cb; /*Callback to write a file */
|
||||
drv.seek_cb = my_seek_cb; /*Callback to seek in a file (Move cursor) */
|
||||
drv.tell_cb = my_tell_cb; /*Callback to tell the cursor position */
|
||||
|
||||
drv.dir_open_cb = my_dir_open_cb; /*Callback to open directory to read its content */
|
||||
drv.dir_read_cb = my_dir_read_cb; /*Callback to read a directory's content */
|
||||
drv.dir_close_cb = my_dir_close_cb; /*Callback to close a directory */
|
||||
|
||||
drv.user_data = my_user_data; /*Any custom data if required*/
|
||||
|
||||
lv_fs_drv_register(&drv); /*Finally register the drive*/
|
||||
|
||||
```
|
||||
|
||||
Any of the callbacks can be `NULL` to indicate that operation is not supported.
|
||||
|
||||
|
||||
### Implementing the callbacks
|
||||
|
||||
#### Open callback
|
||||
The prototype of `open_cb` looks like this:
|
||||
```c
|
||||
void * (*open_cb)(lv_fs_drv_t * drv, const char * path, lv_fs_mode_t mode);
|
||||
```
|
||||
|
||||
`path` is the path after the drive letter (e.g. "S:path/to/file.txt" -> "path/to/file.txt"). `mode` can be `LV_FS_MODE_WR` or `LV_FS_MODE_RD` to open for writes or reads.
|
||||
|
||||
The return value is a pointer to a *file object* that describes the opened file or `NULL` if there were any issues (e.g. the file wasn't found).
|
||||
The returned file object will be passed to other file system related callbacks. (see below)
|
||||
|
||||
### Other callbacks
|
||||
The other callbacks are quite similar. For example `write_cb` looks like this:
|
||||
```c
|
||||
lv_fs_res_t (*write_cb)(lv_fs_drv_t * drv, void * file_p, const void * buf, uint32_t btw, uint32_t * bw);
|
||||
```
|
||||
|
||||
For `file_p`, LVGL passes the return value of `open_cb`, `buf` is the data to write, `btw` is the Bytes To Write, `bw` is the actually written bytes.
|
||||
|
||||
For a template of these callbacks see [lv_fs_template.c](https://github.com/lvgl/lvgl/blob/master/examples/porting/lv_port_fs_template.c).
|
||||
|
||||
|
||||
## Usage example
|
||||
|
||||
The example below shows how to read from a file:
|
||||
```c
|
||||
lv_fs_file_t f;
|
||||
lv_fs_res_t res;
|
||||
res = lv_fs_open(&f, "S:folder/file.txt", LV_FS_MODE_RD);
|
||||
if(res != LV_FS_RES_OK) my_error_handling();
|
||||
|
||||
uint32_t read_num;
|
||||
uint8_t buf[8];
|
||||
res = lv_fs_read(&f, buf, 8, &read_num);
|
||||
if(res != LV_FS_RES_OK || read_num != 8) my_error_handling();
|
||||
|
||||
lv_fs_close(&f);
|
||||
```
|
||||
*The mode in `lv_fs_open` can be `LV_FS_MODE_WR` to open for writes only or `LV_FS_MODE_RD | LV_FS_MODE_WR` for both*
|
||||
|
||||
This example shows how to read a directory's content. It's up to the driver how to mark directories in the result but it can be a good practice to insert a `'/'` in front of each directory name.
|
||||
```c
|
||||
lv_fs_dir_t dir;
|
||||
lv_fs_res_t res;
|
||||
res = lv_fs_dir_open(&dir, "S:/folder");
|
||||
if(res != LV_FS_RES_OK) my_error_handling();
|
||||
|
||||
char fn[256];
|
||||
while(1) {
|
||||
res = lv_fs_dir_read(&dir, fn);
|
||||
if(res != LV_FS_RES_OK) {
|
||||
my_error_handling();
|
||||
break;
|
||||
}
|
||||
|
||||
/*fn is empty, if not more files to read*/
|
||||
if(strlen(fn) == 0) {
|
||||
break;
|
||||
}
|
||||
|
||||
printf("%s\n", fn);
|
||||
}
|
||||
|
||||
lv_fs_dir_close(&dir);
|
||||
```
|
||||
|
||||
## Use drives for images
|
||||
|
||||
[Image](/widgets/core/img) objects can be opened from files too (besides variables stored in the compiled program).
|
||||
|
||||
To use files in image widgets the following callbacks are required:
|
||||
- open
|
||||
- close
|
||||
- read
|
||||
- seek
|
||||
- tell
|
||||
|
||||
|
||||
|
||||
## API
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_fs.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
269
LVGL.Simulator/lvgl/docs/overview/font.md
Normal file
@@ -0,0 +1,269 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/font.md
|
||||
```
|
||||
# Fonts
|
||||
|
||||
In LVGL fonts are collections of bitmaps and other information required to render images of individual letters (glyph).
|
||||
A font is stored in a `lv_font_t` variable and can be set in a style's *text_font* field. For example:
|
||||
```c
|
||||
lv_style_set_text_font(&my_style, &lv_font_montserrat_28); /*Set a larger font*/
|
||||
```
|
||||
|
||||
Fonts have a **bpp (bits per pixel)** property. It shows how many bits are used to describe a pixel in a font. The value stored for a pixel determines the pixel's opacity.
|
||||
This way, with higher *bpp*, the edges of the letter can be smoother. The possible *bpp* values are 1, 2, 4 and 8 (higher values mean better quality).
|
||||
|
||||
The *bpp* property also affects the amount of memory needed to store a font. For example, *bpp = 4* makes a font nearly four times larger compared to *bpp = 1*.
|
||||
|
||||
## Unicode support
|
||||
|
||||
LVGL supports **UTF-8** encoded Unicode characters.
|
||||
Your editor needs to be configured to save your code/text as UTF-8 (usually this the default) and be sure that, `LV_TXT_ENC` is set to `LV_TXT_ENC_UTF8` in *lv_conf.h*. (This is the default value)
|
||||
|
||||
To test it try
|
||||
```c
|
||||
lv_obj_t * label1 = lv_label_create(lv_scr_act(), NULL);
|
||||
lv_label_set_text(label1, LV_SYMBOL_OK);
|
||||
```
|
||||
|
||||
If all works well, a ✓ character should be displayed.
|
||||
|
||||
## Built-in fonts
|
||||
|
||||
There are several built-in fonts in different sizes, which can be enabled in `lv_conf.h` with *LV_FONT_...* defines.
|
||||
### Normal fonts
|
||||
Containing all the ASCII characters, the degree symbol (U+00B0), the bullet symbol (U+2022) and the built-in symbols (see below).
|
||||
- `LV_FONT_MONTSERRAT_12` 12 px font
|
||||
- `LV_FONT_MONTSERRAT_14` 14 px font
|
||||
- `LV_FONT_MONTSERRAT_16` 16 px font
|
||||
- `LV_FONT_MONTSERRAT_18` 18 px font
|
||||
- `LV_FONT_MONTSERRAT_20` 20 px font
|
||||
- `LV_FONT_MONTSERRAT_22` 22 px font
|
||||
- `LV_FONT_MONTSERRAT_24` 24 px font
|
||||
- `LV_FONT_MONTSERRAT_26` 26 px font
|
||||
- `LV_FONT_MONTSERRAT_28` 28 px font
|
||||
- `LV_FONT_MONTSERRAT_30` 30 px font
|
||||
- `LV_FONT_MONTSERRAT_32` 32 px font
|
||||
- `LV_FONT_MONTSERRAT_34` 34 px font
|
||||
- `LV_FONT_MONTSERRAT_36` 36 px font
|
||||
- `LV_FONT_MONTSERRAT_38` 38 px font
|
||||
- `LV_FONT_MONTSERRAT_40` 40 px font
|
||||
- `LV_FONT_MONTSERRAT_42` 42 px font
|
||||
- `LV_FONT_MONTSERRAT_44` 44 px font
|
||||
- `LV_FONT_MONTSERRAT_46` 46 px font
|
||||
- `LV_FONT_MONTSERRAT_48` 48 px font
|
||||
|
||||
### Special fonts
|
||||
- `LV_FONT_MONTSERRAT_12_SUBPX` Same as normal 12 px font but with [subpixel rendering](#subpixel-rendering)
|
||||
- `LV_FONT_MONTSERRAT_28_COMPRESSED` Same as normal 28 px font but stored as a [compressed font](#compress-fonts) with 3 bpp
|
||||
- `LV_FONT_DEJAVU_16_PERSIAN_HEBREW` 16 px font with normal range + Hebrew, Arabic, Persian letters and all their forms
|
||||
- `LV_FONT_SIMSUN_16_CJK`16 px font with normal range plus 1000 of the most common CJK radicals
|
||||
- `LV_FONT_UNSCII_8` 8 px pixel perfect font with only ASCII characters
|
||||
- `LV_FONT_UNSCII_16` 16 px pixel perfect font with only ASCII characters
|
||||
|
||||
|
||||
The built-in fonts are **global variables** with names like `lv_font_montserrat_16` for a 16 px height font. To use them in a style, just add a pointer to a font variable like shown above.
|
||||
|
||||
The built-in fonts with *bpp = 4* contain the ASCII characters and use the [Montserrat](https://fonts.google.com/specimen/Montserrat) font.
|
||||
|
||||
In addition to the ASCII range, the following symbols are also added to the built-in fonts from the [FontAwesome](https://fontawesome.com/) font.
|
||||
|
||||

|
||||
|
||||
The symbols can be used singly as:
|
||||
```c
|
||||
lv_label_set_text(my_label, LV_SYMBOL_OK);
|
||||
```
|
||||
|
||||
Or together with strings (compile time string concatenation):
|
||||
```c
|
||||
lv_label_set_text(my_label, LV_SYMBOL_OK "Apply");
|
||||
```
|
||||
|
||||
Or more symbols together:
|
||||
```c
|
||||
lv_label_set_text(my_label, LV_SYMBOL_OK LV_SYMBOL_WIFI LV_SYMBOL_PLAY);
|
||||
```
|
||||
|
||||
## Special features
|
||||
|
||||
### Bidirectional support
|
||||
Most languages use a Left-to-Right (LTR for short) writing direction, however some languages (such as Hebrew, Persian or Arabic) use Right-to-Left (RTL for short) direction.
|
||||
|
||||
LVGL not only supports RTL texts but supports mixed (a.k.a. bidirectional, BiDi) text rendering too. Some examples:
|
||||
|
||||

|
||||
|
||||
BiDi support is enabled by `LV_USE_BIDI` in *lv_conf.h*
|
||||
|
||||
All texts have a base direction (LTR or RTL) which determines some rendering rules and the default alignment of the text (Left or Right).
|
||||
However, in LVGL, the base direction is not only applied to labels. It's a general property which can be set for every object.
|
||||
If not set then it will be inherited from the parent.
|
||||
This means it's enough to set the base direction of a screen and every object will inherit it.
|
||||
|
||||
The default base direction for screens can be set by `LV_BIDI_BASE_DIR_DEF` in *lv_conf.h* and other objects inherit the base direction from their parent.
|
||||
|
||||
To set an object's base direction use `lv_obj_set_base_dir(obj, base_dir)`. The possible base directions are:
|
||||
- `LV_BIDI_DIR_LTR`: Left to Right base direction
|
||||
- `LV_BIDI_DIR_RTL`: Right to Left base direction
|
||||
- `LV_BIDI_DIR_AUTO`: Auto detect base direction
|
||||
- `LV_BIDI_DIR_INHERIT`: Inherit base direction from the parent (or a default value for non-screen objects)
|
||||
|
||||
This list summarizes the effect of RTL base direction on objects:
|
||||
- Create objects by default on the right
|
||||
- `lv_tabview`: Displays tabs from right to left
|
||||
- `lv_checkbox`: Shows the box on the right
|
||||
- `lv_btnmatrix`: Shows buttons from right to left
|
||||
- `lv_list`: Shows icons on the right
|
||||
- `lv_dropdown`: Aligns options to the right
|
||||
- The texts in `lv_table`, `lv_btnmatrix`, `lv_keyboard`, `lv_tabview`, `lv_dropdown`, `lv_roller` are "BiDi processed" to be displayed correctly
|
||||
|
||||
### Arabic and Persian support
|
||||
There are some special rules to display Arabic and Persian characters: the *form* of a character depends on its position in the text.
|
||||
A different form of the same letter needs to be used when it is isolated, at start, middle or end positions. Besides these, some conjunction rules should also be taken into account.
|
||||
|
||||
LVGL supports these rules if `LV_USE_ARABIC_PERSIAN_CHARS` is enabled.
|
||||
|
||||
However, there are some limitations:
|
||||
- Only displaying text is supported (e.g. on labels), text inputs (e.g. text area) don't support this feature.
|
||||
- Static text (i.e. const) is not processed. E.g. texts set by `lv_label_set_text()` will be "Arabic processed" but `lv_lable_set_text_static()` won't.
|
||||
- Text get functions (e.g. `lv_label_get_text()`) will return the processed text.
|
||||
|
||||
### Subpixel rendering
|
||||
|
||||
Subpixel rendering allows for tripling the horizontal resolution by rendering anti-aliased edges on Red, Green and Blue channels instead of at pixel level granularity. This takes advantage of the position of physical color channels of each pixel, resulting in higher quality letter anti-aliasing. Learn more [here](https://en.wikipedia.org/wiki/Subpixel_rendering).
|
||||
|
||||
For subpixel rendering, the fonts need to be generated with special settings:
|
||||
- In the online converter tick the `Subpixel` box
|
||||
- In the command line tool use `--lcd` flag. Note that the generated font needs about three times more memory.
|
||||
|
||||
Subpixel rendering works only if the color channels of the pixels have a horizontal layout. That is the R, G, B channels are next to each other and not above each other.
|
||||
The order of color channels also needs to match with the library settings. By default, LVGL assumes `RGB` order, however this can be swapped by setting `LV_SUBPX_BGR 1` in *lv_conf.h*.
|
||||
|
||||
### Compressed fonts
|
||||
The bitmaps of fonts can be compressed by
|
||||
- ticking the `Compressed` check box in the online converter
|
||||
- not passing the `--no-compress` flag to the offline converter (compression is applied by default)
|
||||
|
||||
Compression is more effective with larger fonts and higher bpp. However, it's about 30% slower to render compressed fonts.
|
||||
Therefore, it's recommended to compress only the largest fonts of a user interface, because
|
||||
- they need the most memory
|
||||
- they can be compressed better
|
||||
- and probably they are used less frequently then the medium-sized fonts, so the performance cost is smaller.
|
||||
|
||||
## Add a new font
|
||||
|
||||
There are several ways to add a new font to your project:
|
||||
1. The simplest method is to use the [Online font converter](https://lvgl.io/tools/fontconverter). Just set the parameters, click the *Convert* button, copy the font to your project and use it. **Be sure to carefully read the steps provided on that site or you will get an error while converting.**
|
||||
2. Use the [Offline font converter](https://github.com/lvgl/lv_font_conv). (Requires Node.js to be installed)
|
||||
3. If you want to create something like the built-in fonts (Montserrat font and symbols) but in a different size and/or ranges, you can use the `built_in_font_gen.py` script in `lvgl/scripts/built_in_font` folder.
|
||||
(This requires Python and `lv_font_conv` to be installed)
|
||||
|
||||
To declare a font in a file, use `LV_FONT_DECLARE(my_font_name)`.
|
||||
|
||||
To make fonts globally available (like the built-in fonts), add them to `LV_FONT_CUSTOM_DECLARE` in *lv_conf.h*.
|
||||
|
||||
## Add new symbols
|
||||
The built-in symbols are created from the [FontAwesome](https://fontawesome.com/) font.
|
||||
|
||||
1. Search for a symbol on [https://fontawesome.com](https://fontawesome.com). For example the [USB symbol](https://fontawesome.com/icons/usb?style=brands). Copy its Unicode ID which is `0xf287` in this case.
|
||||
2. Open the [Online font converter](https://lvgl.io/tools/fontconverter). Add [FontAwesome.woff](https://lvgl.io/assets/others/FontAwesome5-Solid+Brands+Regular.woff). .
|
||||
3. Set the parameters such as Name, Size, BPP. You'll use this name to declare and use the font in your code.
|
||||
4. Add the Unicode ID of the symbol to the range field. E.g.` 0xf287` for the USB symbol. More symbols can be enumerated with `,`.
|
||||
5. Convert the font and copy the generated source code to your project. Make sure to compile the .c file of your font.
|
||||
6. Declare the font using `extern lv_font_t my_font_name;` or simply use `LV_FONT_DECLARE(my_font_name);`.
|
||||
|
||||
**Using the symbol**
|
||||
1. Convert the Unicode value to UTF8, for example on [this site](http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=f287&mode=hex). For `0xf287` the *Hex UTF-8 bytes* are `EF 8A 87`.
|
||||
2. Create a `define` string from the UTF8 values: `#define MY_USB_SYMBOL "\xEF\x8A\x87"`
|
||||
3. Create a label and set the text. Eg. `lv_label_set_text(label, MY_USB_SYMBOL)`
|
||||
|
||||
Note - `lv_label_set_text(label, MY_USB_SYMBOL)` searches for this symbol in the font defined in `style.text.font` properties. To use the symbol you may need to change it. Eg ` style.text.font = my_font_name`
|
||||
|
||||
## Load a font at run-time
|
||||
`lv_font_load` can be used to load a font from a file. The font needs to have a special binary format. (Not TTF or WOFF).
|
||||
Use [lv_font_conv](https://github.com/lvgl/lv_font_conv/) with the `--format bin` option to generate an LVGL compatible font file.
|
||||
|
||||
Note that to load a font [LVGL's filesystem](/overview/file-system) needs to be enabled and a driver must be added.
|
||||
|
||||
Example
|
||||
```c
|
||||
lv_font_t * my_font;
|
||||
my_font = lv_font_load(X/path/to/my_font.bin);
|
||||
|
||||
/*Use the font*/
|
||||
|
||||
/*Free the font if not required anymore*/
|
||||
lv_font_free(my_font);
|
||||
```
|
||||
|
||||
|
||||
## Add a new font engine
|
||||
|
||||
LVGL's font interface is designed to be very flexible but, even so, you can add your own font engine in place of LVGL's internal one.
|
||||
For example, you can use [FreeType](https://www.freetype.org/) to real-time render glyphs from TTF fonts or use an external flash to store the font's bitmap and read them when the library needs them.
|
||||
|
||||
A ready to use FreeType can be found in [lv_freetype](https://github.com/lvgl/lv_lib_freetype) repository.
|
||||
|
||||
To do this, a custom `lv_font_t` variable needs to be created:
|
||||
```c
|
||||
/*Describe the properties of a font*/
|
||||
lv_font_t my_font;
|
||||
my_font.get_glyph_dsc = my_get_glyph_dsc_cb; /*Set a callback to get info about glyphs*/
|
||||
my_font.get_glyph_bitmap = my_get_glyph_bitmap_cb; /*Set a callback to get bitmap of a glyph*/
|
||||
my_font.line_height = height; /*The real line height where any text fits*/
|
||||
my_font.base_line = base_line; /*Base line measured from the top of line_height*/
|
||||
my_font.dsc = something_required; /*Store any implementation specific data here*/
|
||||
my_font.user_data = user_data; /*Optionally some extra user data*/
|
||||
|
||||
...
|
||||
|
||||
/* Get info about glyph of `unicode_letter` in `font` font.
|
||||
* Store the result in `dsc_out`.
|
||||
* The next letter (`unicode_letter_next`) might be used to calculate the width required by this glyph (kerning)
|
||||
*/
|
||||
bool my_get_glyph_dsc_cb(const lv_font_t * font, lv_font_glyph_dsc_t * dsc_out, uint32_t unicode_letter, uint32_t unicode_letter_next)
|
||||
{
|
||||
/*Your code here*/
|
||||
|
||||
/* Store the result.
|
||||
* For example ...
|
||||
*/
|
||||
dsc_out->adv_w = 12; /*Horizontal space required by the glyph in [px]*/
|
||||
dsc_out->box_h = 8; /*Height of the bitmap in [px]*/
|
||||
dsc_out->box_w = 6; /*Width of the bitmap in [px]*/
|
||||
dsc_out->ofs_x = 0; /*X offset of the bitmap in [pf]*/
|
||||
dsc_out->ofs_y = 3; /*Y offset of the bitmap measured from the as line*/
|
||||
dsc_out->bpp = 2; /*Bits per pixel: 1/2/4/8*/
|
||||
|
||||
return true; /*true: glyph found; false: glyph was not found*/
|
||||
}
|
||||
|
||||
|
||||
/* Get the bitmap of `unicode_letter` from `font`. */
|
||||
const uint8_t * my_get_glyph_bitmap_cb(const lv_font_t * font, uint32_t unicode_letter)
|
||||
{
|
||||
/* Your code here */
|
||||
|
||||
/* The bitmap should be a continuous bitstream where
|
||||
* each pixel is represented by `bpp` bits */
|
||||
|
||||
return bitmap; /*Or NULL if not found*/
|
||||
}
|
||||
```
|
||||
|
||||
## Use font fallback
|
||||
|
||||
You can specify `fallback` in `lv_font_t` to provide fallback to the font. When the font
|
||||
fails to find glyph to a letter, it will try to let font from `fallback` to handle.
|
||||
|
||||
`fallback` can be chained, so it will try to solve until there is no `fallback` set.
|
||||
|
||||
```c
|
||||
/* Roboto font doesn't have support for CJK glyphs */
|
||||
lv_font_t *roboto = my_font_load_function();
|
||||
/* Droid Sans Fallback has more glyphs but its typeface doesn't look good as Roboto */
|
||||
lv_font_t *droid_sans_fallback = my_font_load_function();
|
||||
/* So now we can display Roboto for supported characters while having wider characters set support */
|
||||
roboto->fallback = droid_sans_fallback;
|
||||
```
|
||||
334
LVGL.Simulator/lvgl/docs/overview/image.md
Normal file
@@ -0,0 +1,334 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/image.md
|
||||
```
|
||||
# Images
|
||||
|
||||
An image can be a file or a variable which stores the bitmap itself and some metadata.
|
||||
|
||||
## Store images
|
||||
You can store images in two places
|
||||
- as a variable in internal memory (RAM or ROM)
|
||||
- as a file
|
||||
|
||||
### Variables
|
||||
Images stored internally in a variable are composed mainly of an `lv_img_dsc_t` structure with the following fields:
|
||||
- **header**
|
||||
- *cf* Color format. See [below](#color-format)
|
||||
- *w* width in pixels (<= 2048)
|
||||
- *h* height in pixels (<= 2048)
|
||||
- *always zero* 3 bits which need to be always zero
|
||||
- *reserved* reserved for future use
|
||||
- **data** pointer to an array where the image itself is stored
|
||||
- **data_size** length of `data` in bytes
|
||||
|
||||
These are usually stored within a project as C files. They are linked into the resulting executable like any other constant data.
|
||||
|
||||
### Files
|
||||
To deal with files you need to add a storage *Drive* to LVGL. In short, a *Drive* is a collection of functions (*open*, *read*, *close*, etc.) registered in LVGL to make file operations.
|
||||
You can add an interface to a standard file system (FAT32 on SD card) or you create your simple file system to read data from an SPI Flash memory.
|
||||
In every case, a *Drive* is just an abstraction to read and/or write data to memory.
|
||||
See the [File system](/overview/file-system) section to learn more.
|
||||
|
||||
Images stored as files are not linked into the resulting executable, and must be read into RAM before being drawn. As a result, they are not as resource-friendly as images linked at compile time. However, they are easier to replace without needing to rebuild the main program.
|
||||
|
||||
## Color formats
|
||||
Various built-in color formats are supported:
|
||||
- **LV_IMG_CF_TRUE_COLOR** Simply stores the RGB colors (in whatever color depth LVGL is configured for).
|
||||
- **LV_IMG_CF_TRUE_COLOR_ALPHA** Like `LV_IMG_CF_TRUE_COLOR` but it also adds an alpha (transparency) byte for every pixel.
|
||||
- **LV_IMG_CF_TRUE_COLOR_CHROMA_KEYED** Like `LV_IMG_CF_TRUE_COLOR` but if a pixel has the `LV_COLOR_TRANSP` color (set in *lv_conf.h*) it will be transparent.
|
||||
- **LV_IMG_CF_INDEXED_1/2/4/8BIT** Uses a palette with 2, 4, 16 or 256 colors and stores each pixel in 1, 2, 4 or 8 bits.
|
||||
- **LV_IMG_CF_ALPHA_1/2/4/8BIT** **Only stores the Alpha value with 1, 2, 4 or 8 bits.** The pixels take the color of `style.img_recolor` and the set opacity. The source image has to be an alpha channel. This is ideal for bitmaps similar to fonts where the whole image is one color that can be altered.
|
||||
|
||||
The bytes of `LV_IMG_CF_TRUE_COLOR` images are stored in the following order.
|
||||
|
||||
For 32-bit color depth:
|
||||
- Byte 0: Blue
|
||||
- Byte 1: Green
|
||||
- Byte 2: Red
|
||||
- Byte 3: Alpha
|
||||
|
||||
For 16-bit color depth:
|
||||
- Byte 0: Green 3 lower bit, Blue 5 bit
|
||||
- Byte 1: Red 5 bit, Green 3 higher bit
|
||||
- Byte 2: Alpha byte (only with LV_IMG_CF_TRUE_COLOR_ALPHA)
|
||||
|
||||
For 8-bit color depth:
|
||||
- Byte 0: Red 3 bit, Green 3 bit, Blue 2 bit
|
||||
- Byte 2: Alpha byte (only with LV_IMG_CF_TRUE_COLOR_ALPHA)
|
||||
|
||||
|
||||
You can store images in a *Raw* format to indicate that it's not encoded with one of the built-in color formats and an external [Image decoder](#image-decoder) needs to be used to decode the image.
|
||||
- **LV_IMG_CF_RAW** Indicates a basic raw image (e.g. a PNG or JPG image).
|
||||
- **LV_IMG_CF_RAW_ALPHA** Indicates that an image has alpha and an alpha byte is added for every pixel.
|
||||
- **LV_IMG_CF_RAW_CHROMA_KEYED** Indicates that an image is chroma-keyed as described in `LV_IMG_CF_TRUE_COLOR_CHROMA_KEYED` above.
|
||||
|
||||
|
||||
## Add and use images
|
||||
|
||||
You can add images to LVGL in two ways:
|
||||
- using the online converter
|
||||
- manually create images
|
||||
|
||||
### Online converter
|
||||
The online Image converter is available here: https://lvgl.io/tools/imageconverter
|
||||
|
||||
Adding an image to LVGL via the online converter is easy.
|
||||
|
||||
1. You need to select a *BMP*, *PNG* or *JPG* image first.
|
||||
2. Give the image a name that will be used within LVGL.
|
||||
3. Select the [Color format](#color-formats).
|
||||
4. Select the type of image you want. Choosing a binary will generate a `.bin` file that must be stored separately and read using the [file support](#files). Choosing a variable will generate a standard C file that can be linked into your project.
|
||||
5. Hit the *Convert* button. Once the conversion is finished, your browser will automatically download the resulting file.
|
||||
|
||||
In the generated C arrays (variables), bitmaps for all the color depths (1, 8, 16 or 32) are included in the C file, but only the color depth that matches `LV_COLOR_DEPTH` in *lv_conf.h* will actually be linked into the resulting executable.
|
||||
|
||||
In the case of binary files, you need to specify the color format you want:
|
||||
- RGB332 for 8-bit color depth
|
||||
- RGB565 for 16-bit color depth
|
||||
- RGB565 Swap for 16-bit color depth (two bytes are swapped)
|
||||
- RGB888 for 32-bit color depth
|
||||
|
||||
### Manually create an image
|
||||
If you are generating an image at run-time, you can craft an image variable to display it using LVGL. For example:
|
||||
|
||||
```c
|
||||
uint8_t my_img_data[] = {0x00, 0x01, 0x02, ...};
|
||||
|
||||
static lv_img_dsc_t my_img_dsc = {
|
||||
.header.always_zero = 0,
|
||||
.header.w = 80,
|
||||
.header.h = 60,
|
||||
.data_size = 80 * 60 * LV_COLOR_DEPTH / 8,
|
||||
.header.cf = LV_IMG_CF_TRUE_COLOR, /*Set the color format*/
|
||||
.data = my_img_data,
|
||||
};
|
||||
|
||||
```
|
||||
|
||||
If the color format is `LV_IMG_CF_TRUE_COLOR_ALPHA` you can set `data_size` like `80 * 60 * LV_IMG_PX_SIZE_ALPHA_BYTE`.
|
||||
|
||||
Another (possibly simpler) option to create and display an image at run-time is to use the [Canvas](/widgets/core/canvas) object.
|
||||
|
||||
### Use images
|
||||
|
||||
The simplest way to use an image in LVGL is to display it with an [lv_img](/widgets/core/img) object:
|
||||
|
||||
```c
|
||||
lv_obj_t * icon = lv_img_create(lv_scr_act(), NULL);
|
||||
|
||||
/*From variable*/
|
||||
lv_img_set_src(icon, &my_icon_dsc);
|
||||
|
||||
/*From file*/
|
||||
lv_img_set_src(icon, "S:my_icon.bin");
|
||||
```
|
||||
|
||||
If the image was converted with the online converter, you should use `LV_IMG_DECLARE(my_icon_dsc)` to declare the image in the file where you want to use it.
|
||||
|
||||
|
||||
## Image decoder
|
||||
As you can see in the [Color formats](#color-formats) section, LVGL supports several built-in image formats. In many cases, these will be all you need. LVGL doesn't directly support, however, generic image formats like PNG or JPG.
|
||||
|
||||
To handle non-built-in image formats, you need to use external libraries and attach them to LVGL via the *Image decoder* interface.
|
||||
|
||||
An image decoder consists of 4 callbacks:
|
||||
- **info** get some basic info about the image (width, height and color format).
|
||||
- **open** open an image: either store a decoded image or set it to `NULL` to indicate the image can be read line-by-line.
|
||||
- **read** if *open* didn't fully open an image this function should give some decoded data (max 1 line) from a given position.
|
||||
- **close** close an opened image, free the allocated resources.
|
||||
|
||||
You can add any number of image decoders. When an image needs to be drawn, the library will try all the registered image decoders until it finds one which can open the image, i.e. one which knows that format.
|
||||
|
||||
The `LV_IMG_CF_TRUE_COLOR_...`, `LV_IMG_INDEXED_...` and `LV_IMG_ALPHA_...` formats (essentially, all non-`RAW` formats) are understood by the built-in decoder.
|
||||
|
||||
### Custom image formats
|
||||
|
||||
The easiest way to create a custom image is to use the online image converter and select `Raw`, `Raw with alpha` or `Raw with chroma-keyed` format. It will just take every byte of the binary file you uploaded and write it as an image "bitmap". You then need to attach an image decoder that will parse that bitmap and generate the real, renderable bitmap.
|
||||
|
||||
`header.cf` will be `LV_IMG_CF_RAW`, `LV_IMG_CF_RAW_ALPHA` or `LV_IMG_CF_RAW_CHROMA_KEYED` accordingly. You should choose the correct format according to your needs: a fully opaque image, using an alpha channel or using a chroma key.
|
||||
|
||||
After decoding, the *raw* formats are considered *True color* by the library. In other words, the image decoder must decode the *Raw* images to *True color* according to the format described in the [Color formats](#color-formats) section.
|
||||
|
||||
If you want to create a custom image, you should use `LV_IMG_CF_USER_ENCODED_0..7` color formats. However, the library can draw images only in *True color* format (or *Raw* but ultimately it will be in *True color* format).
|
||||
The `LV_IMG_CF_USER_ENCODED_...` formats are not known by the library and therefore they should be decoded to one of the known formats from the [Color formats](#color-formats) section.
|
||||
It's possible to decode an image to a non-true color format first (for example: `LV_IMG_INDEXED_4BITS`) and then call the built-in decoder functions to convert it to *True color*.
|
||||
|
||||
With *User encoded* formats, the color format in the open function (`dsc->header.cf`) should be changed according to the new format.
|
||||
|
||||
|
||||
### Register an image decoder
|
||||
|
||||
Here's an example of getting LVGL to work with PNG images.
|
||||
|
||||
First, you need to create a new image decoder and set some functions to open/close the PNG files. It should look like this:
|
||||
|
||||
```c
|
||||
/*Create a new decoder and register functions */
|
||||
lv_img_decoder_t * dec = lv_img_decoder_create();
|
||||
lv_img_decoder_set_info_cb(dec, decoder_info);
|
||||
lv_img_decoder_set_open_cb(dec, decoder_open);
|
||||
lv_img_decoder_set_close_cb(dec, decoder_close);
|
||||
|
||||
|
||||
/**
|
||||
* Get info about a PNG image
|
||||
* @param decoder pointer to the decoder where this function belongs
|
||||
* @param src can be file name or pointer to a C array
|
||||
* @param header store the info here
|
||||
* @return LV_RES_OK: no error; LV_RES_INV: can't get the info
|
||||
*/
|
||||
static lv_res_t decoder_info(lv_img_decoder_t * decoder, const void * src, lv_img_header_t * header)
|
||||
{
|
||||
/*Check whether the type `src` is known by the decoder*/
|
||||
if(is_png(src) == false) return LV_RES_INV;
|
||||
|
||||
/* Read the PNG header and find `width` and `height` */
|
||||
...
|
||||
|
||||
header->cf = LV_IMG_CF_RAW_ALPHA;
|
||||
header->w = width;
|
||||
header->h = height;
|
||||
}
|
||||
|
||||
/**
|
||||
* Open a PNG image and return the decided image
|
||||
* @param decoder pointer to the decoder where this function belongs
|
||||
* @param dsc pointer to a descriptor which describes this decoding session
|
||||
* @return LV_RES_OK: no error; LV_RES_INV: can't get the info
|
||||
*/
|
||||
static lv_res_t decoder_open(lv_img_decoder_t * decoder, lv_img_decoder_dsc_t * dsc)
|
||||
{
|
||||
|
||||
/*Check whether the type `src` is known by the decoder*/
|
||||
if(is_png(src) == false) return LV_RES_INV;
|
||||
|
||||
/*Decode and store the image. If `dsc->img_data` is `NULL`, the `read_line` function will be called to get the image data line-by-line*/
|
||||
dsc->img_data = my_png_decoder(src);
|
||||
|
||||
/*Change the color format if required. For PNG usually 'Raw' is fine*/
|
||||
dsc->header.cf = LV_IMG_CF_...
|
||||
|
||||
/*Call a built in decoder function if required. It's not required if`my_png_decoder` opened the image in true color format.*/
|
||||
lv_res_t res = lv_img_decoder_built_in_open(decoder, dsc);
|
||||
|
||||
return res;
|
||||
}
|
||||
|
||||
/**
|
||||
* Decode `len` pixels starting from the given `x`, `y` coordinates and store them in `buf`.
|
||||
* Required only if the "open" function can't open the whole decoded pixel array. (dsc->img_data == NULL)
|
||||
* @param decoder pointer to the decoder the function associated with
|
||||
* @param dsc pointer to decoder descriptor
|
||||
* @param x start x coordinate
|
||||
* @param y start y coordinate
|
||||
* @param len number of pixels to decode
|
||||
* @param buf a buffer to store the decoded pixels
|
||||
* @return LV_RES_OK: ok; LV_RES_INV: failed
|
||||
*/
|
||||
lv_res_t decoder_built_in_read_line(lv_img_decoder_t * decoder, lv_img_decoder_dsc_t * dsc, lv_coord_t x,
|
||||
lv_coord_t y, lv_coord_t len, uint8_t * buf)
|
||||
{
|
||||
/*With PNG it's usually not required*/
|
||||
|
||||
/*Copy `len` pixels from `x` and `y` coordinates in True color format to `buf` */
|
||||
|
||||
}
|
||||
|
||||
/**
|
||||
* Free the allocated resources
|
||||
* @param decoder pointer to the decoder where this function belongs
|
||||
* @param dsc pointer to a descriptor which describes this decoding session
|
||||
*/
|
||||
static void decoder_close(lv_img_decoder_t * decoder, lv_img_decoder_dsc_t * dsc)
|
||||
{
|
||||
/*Free all allocated data*/
|
||||
|
||||
/*Call the built-in close function if the built-in open/read_line was used*/
|
||||
lv_img_decoder_built_in_close(decoder, dsc);
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
So in summary:
|
||||
- In `decoder_info`, you should collect some basic information about the image and store it in `header`.
|
||||
- In `decoder_open`, you should try to open the image source pointed by `dsc->src`. Its type is already in `dsc->src_type == LV_IMG_SRC_FILE/VARIABLE`.
|
||||
If this format/type is not supported by the decoder, return `LV_RES_INV`.
|
||||
However, if you can open the image, a pointer to the decoded *True color* image should be set in `dsc->img_data`.
|
||||
If the format is known, but you don't want to decode the entire image (e.g. no memory for it), set `dsc->img_data = NULL` and use `read_line` to get the pixel data.
|
||||
- In `decoder_close` you should free all allocated resources.
|
||||
- `decoder_read` is optional. Decoding the whole image requires extra memory and some computational overhead.
|
||||
However, it can decode one line of the image without decoding the whole image, you can save memory and time.
|
||||
To indicate that the *line read* function should be used, set `dsc->img_data = NULL` in the open function.
|
||||
|
||||
|
||||
### Manually use an image decoder
|
||||
|
||||
LVGL will use registered image decoders automatically if you try and draw a raw image (i.e. using the `lv_img` object) but you can use them manually too. Create an `lv_img_decoder_dsc_t` variable to describe the decoding session and call `lv_img_decoder_open()`.
|
||||
|
||||
The `color` parameter is used only with `LV_IMG_CF_ALPHA_1/2/4/8BIT` images to tell color of the image.
|
||||
`frame_id` can be used if the image to open is an animation.
|
||||
|
||||
|
||||
```c
|
||||
|
||||
lv_res_t res;
|
||||
lv_img_decoder_dsc_t dsc;
|
||||
res = lv_img_decoder_open(&dsc, &my_img_dsc, color, frame_id);
|
||||
|
||||
if(res == LV_RES_OK) {
|
||||
/*Do something with `dsc->img_data`*/
|
||||
lv_img_decoder_close(&dsc);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
|
||||
## Image caching
|
||||
Sometimes it takes a lot of time to open an image.
|
||||
Continuously decoding a PNG image or loading images from a slow external memory would be inefficient and detrimental to the user experience.
|
||||
|
||||
Therefore, LVGL caches a given number of images. Caching means some images will be left open, hence LVGL can quickly access them from `dsc->img_data` instead of needing to decode them again.
|
||||
|
||||
Of course, caching images is resource intensive as it uses more RAM to store the decoded image. LVGL tries to optimize the process as much as possible (see below), but you will still need to evaluate if this would be beneficial for your platform or not. Image caching may not be worth it if you have a deeply embedded target which decodes small images from a relatively fast storage medium.
|
||||
|
||||
### Cache size
|
||||
The number of cache entries can be defined with `LV_IMG_CACHE_DEF_SIZE` in *lv_conf.h*. The default value is 1 so only the most recently used image will be left open.
|
||||
|
||||
The size of the cache can be changed at run-time with `lv_img_cache_set_size(entry_num)`.
|
||||
|
||||
### Value of images
|
||||
When you use more images than cache entries, LVGL can't cache all the images. Instead, the library will close one of the cached images to free space.
|
||||
|
||||
To decide which image to close, LVGL uses a measurement it previously made of how long it took to open the image. Cache entries that hold slower-to-open images are considered more valuable and are kept in the cache as long as possible.
|
||||
|
||||
If you want or need to override LVGL's measurement, you can manually set the *time to open* value in the decoder open function in `dsc->time_to_open = time_ms` to give a higher or lower value. (Leave it unchanged to let LVGL control it.)
|
||||
|
||||
Every cache entry has a *"life"* value. Every time an image is opened through the cache, the *life* value of all entries is decreased to make them older.
|
||||
When a cached image is used, its *life* value is increased by the *time to open* value to make it more alive.
|
||||
|
||||
If there is no more space in the cache, the entry with the lowest life value will be closed.
|
||||
|
||||
### Memory usage
|
||||
Note that a cached image might continuously consume memory. For example, if three PNG images are cached, they will consume memory while they are open.
|
||||
|
||||
Therefore, it's the user's responsibility to be sure there is enough RAM to cache even the largest images at the same time.
|
||||
|
||||
### Clean the cache
|
||||
Let's say you have loaded a PNG image into a `lv_img_dsc_t my_png` variable and use it in an `lv_img` object. If the image is already cached and you then change the underlying PNG file, you need to notify LVGL to cache the image again. Otherwise, there is no easy way of detecting that the underlying file changed and LVGL will still draw the old image from cache.
|
||||
|
||||
To do this, use `lv_img_cache_invalidate_src(&my_png)`. If `NULL` is passed as a parameter, the whole cache will be cleaned.
|
||||
|
||||
|
||||
## API
|
||||
|
||||
|
||||
### Image buffer
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_img_buf.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
152
LVGL.Simulator/lvgl/docs/overview/indev.md
Normal file
@@ -0,0 +1,152 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/indev.md
|
||||
```
|
||||
# Input devices
|
||||
|
||||
An input device usually means:
|
||||
- Pointer-like input device like touchpad or mouse
|
||||
- Keypads like a normal keyboard or simple numeric keypad
|
||||
- Encoders with left/right turn and push options
|
||||
- External hardware buttons which are assigned to specific points on the screen
|
||||
|
||||
|
||||
``` important:: Before reading further, please read the [Porting](/porting/indev) section of Input devices
|
||||
```
|
||||
|
||||
## Pointers
|
||||
|
||||
### Cursor
|
||||
|
||||
Pointer input devices (like a mouse) can have a cursor.
|
||||
|
||||
```c
|
||||
...
|
||||
lv_indev_t * mouse_indev = lv_indev_drv_register(&indev_drv);
|
||||
|
||||
LV_IMG_DECLARE(mouse_cursor_icon); /*Declare the image source.*/
|
||||
lv_obj_t * cursor_obj = lv_img_create(lv_scr_act()); /*Create an image object for the cursor */
|
||||
lv_img_set_src(cursor_obj, &mouse_cursor_icon); /*Set the image source*/
|
||||
lv_indev_set_cursor(mouse_indev, cursor_obj); /*Connect the image object to the driver*/
|
||||
```
|
||||
|
||||
Note that the cursor object should have `lv_obj_clear_flag(cursor_obj, LV_OBJ_FLAG_CLICKABLE)`.
|
||||
For images, *clicking* is disabled by default.
|
||||
|
||||
### Gestures
|
||||
Pointer input devices can detect basic gestures. By default, most of the widgets send the gestures to its parent, so finally the gestures can be detected on the screen object in a form of an `LV_EVENT_GESTURE` event. For example:
|
||||
|
||||
```c
|
||||
void my_event(lv_event_t * e)
|
||||
{
|
||||
lv_obj_t * screen = lv_event_get_current_target(e);
|
||||
lv_dir_t dir = lv_indev_get_gesture_dir(lv_indev_act());
|
||||
switch(dir) {
|
||||
case LV_DIR_LEFT:
|
||||
...
|
||||
break;
|
||||
case LV_DIR_RIGHT:
|
||||
...
|
||||
break;
|
||||
case LV_DIR_TOP:
|
||||
...
|
||||
break;
|
||||
case LV_DIR_BOTTOM:
|
||||
...
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
lv_obj_add_event_cb(screen1, my_event, LV_EVENT_GESTURE, NULL);
|
||||
```
|
||||
|
||||
To prevent passing the gesture event to the parent from an object use `lv_obj_clear_flag(obj, LV_OBJ_FLAG_GESTURE_BUBBLE)`.
|
||||
|
||||
Note that, gestures are not triggered if an object is being scrolled.
|
||||
|
||||
## Keypad and encoder
|
||||
|
||||
You can fully control the user interface without a touchpad or mouse by using a keypad or encoder(s). It works similar to the *TAB* key on the PC to select an element in an application or a web page.
|
||||
|
||||
### Groups
|
||||
|
||||
Objects you want to control with a keypad or encoder need to be added to a *Group*.
|
||||
In every group there is exactly one focused object which receives the pressed keys or the encoder actions.
|
||||
For example, if a [Text area](/widgets/core/textarea) is focused and you press some letter on a keyboard, the keys will be sent and inserted into the text area.
|
||||
Similarly, if a [Slider](/widgets/core/slider) is focused and you press the left or right arrows, the slider's value will be changed.
|
||||
|
||||
You need to associate an input device with a group. An input device can send key events to only one group but a group can receive data from more than one input device.
|
||||
|
||||
To create a group use `lv_group_t * g = lv_group_create()` and to add an object to the group use `lv_group_add_obj(g, obj)`.
|
||||
|
||||
To associate a group with an input device use `lv_indev_set_group(indev, g)`, where `indev` is the return value of `lv_indev_drv_register()`
|
||||
|
||||
#### Keys
|
||||
There are some predefined keys which have special meaning:
|
||||
- **LV_KEY_NEXT** Focus on the next object
|
||||
- **LV_KEY_PREV** Focus on the previous object
|
||||
- **LV_KEY_ENTER** Triggers `LV_EVENT_PRESSED/CLICKED/LONG_PRESSED` etc. events
|
||||
- **LV_KEY_UP** Increase value or move upwards
|
||||
- **LV_KEY_DOWN** Decrease value or move downwards
|
||||
- **LV_KEY_RIGHT** Increase value or move to the right
|
||||
- **LV_KEY_LEFT** Decrease value or move to the left
|
||||
- **LV_KEY_ESC** Close or exit (E.g. close a [Drop down list](/widgets/core/dropdown))
|
||||
- **LV_KEY_DEL** Delete (E.g. a character on the right in a [Text area](/widgets/core/textarea))
|
||||
- **LV_KEY_BACKSPACE** Delete a character on the left (E.g. in a [Text area](/widgets/core/textarea))
|
||||
- **LV_KEY_HOME** Go to the beginning/top (E.g. in a [Text area](/widgets/core/textarea))
|
||||
- **LV_KEY_END** Go to the end (E.g. in a [Text area](/widgets/core/textarea))
|
||||
|
||||
The most important special keys are `LV_KEY_NEXT/PREV`, `LV_KEY_ENTER` and `LV_KEY_UP/DOWN/LEFT/RIGHT`.
|
||||
In your `read_cb` function, you should translate some of your keys to these special keys to support navigation in a group and interact with selected objects.
|
||||
|
||||
Usually, it's enough to use only `LV_KEY_LEFT/RIGHT` because most objects can be fully controlled with them.
|
||||
|
||||
With an encoder you should use only `LV_KEY_LEFT`, `LV_KEY_RIGHT`, and `LV_KEY_ENTER`.
|
||||
|
||||
#### Edit and navigate mode
|
||||
|
||||
Since a keypad has plenty of keys, it's easy to navigate between objects and edit them using the keypad. But encoders have a limited number of "keys" and hence it is difficult to navigate using the default options. *Navigate* and *Edit* modes are used to avoid this problem with encoders.
|
||||
|
||||
In *Navigate* mode, an encoder's `LV_KEY_LEFT/RIGHT` is translated to `LV_KEY_NEXT/PREV`. Therefore, the next or previous object will be selected by turning the encoder.
|
||||
Pressing `LV_KEY_ENTER` will change to *Edit* mode.
|
||||
|
||||
In *Edit* mode, `LV_KEY_NEXT/PREV` is usually used to modify an object.
|
||||
Depending on the object's type, a short or long press of `LV_KEY_ENTER` changes back to *Navigate* mode.
|
||||
Usually, an object which cannot be pressed (like a [Slider](/widgets/core/slider)) leaves *Edit* mode upon a short click. But with objects where a short click has meaning (e.g. [Button](/widgets/core/btn)), a long press is required.
|
||||
|
||||
#### Default group
|
||||
Interactive widgets - such as buttons, checkboxes, sliders, etc. - can be automatically added to a default group.
|
||||
Just create a group with `lv_group_t * g = lv_group_create();` and set the default group with `lv_group_set_default(g);`
|
||||
|
||||
Don't forget to assign one or more input devices to the default group with ` lv_indev_set_group(my_indev, g);`.
|
||||
|
||||
### Styling
|
||||
|
||||
If an object is focused either by clicking it via touchpad or focused via an encoder or keypad it goes to the `LV_STATE_FOCUSED` state. Hence, focused styles will be applied to it.
|
||||
|
||||
If an object switches to edit mode it enters the `LV_STATE_FOCUSED | LV_STATE_EDITED` states so these style properties will be shown.
|
||||
|
||||
For a more detailed description read the [Style](https://docs.lvgl.io/v7/en/html/overview/style.html) section.
|
||||
|
||||
## API
|
||||
|
||||
|
||||
### Input device
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_indev.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
|
||||
### Groups
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. doxygenfile:: lv_group.h
|
||||
:project: lvgl
|
||||
|
||||
```
|
||||
33
LVGL.Simulator/lvgl/docs/overview/index.md
Normal file
@@ -0,0 +1,33 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/index.md
|
||||
```
|
||||
|
||||
# Overview
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
object
|
||||
coords
|
||||
style
|
||||
style-props
|
||||
scroll
|
||||
layer
|
||||
event
|
||||
indev
|
||||
display
|
||||
color
|
||||
font
|
||||
image
|
||||
file-system
|
||||
animation
|
||||
timer
|
||||
drawing
|
||||
renderers/index
|
||||
new_widget
|
||||
```
|
||||
|
||||
60
LVGL.Simulator/lvgl/docs/overview/layer.md
Normal file
@@ -0,0 +1,60 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/layer.md
|
||||
```
|
||||
|
||||
# Layers
|
||||
|
||||
## Order of creation
|
||||
|
||||
By default, LVGL draws new objects on top of old objects.
|
||||
|
||||
For example, assume we add a button to a parent object named button1 and then another button named button2. Then button1 (along with its child object(s)) will be in the background and can be covered by button2 and its children.
|
||||
|
||||
|
||||

|
||||
|
||||
```c
|
||||
/*Create a screen*/
|
||||
lv_obj_t * scr = lv_obj_create(NULL, NULL);
|
||||
lv_scr_load(scr); /*Load the screen*/
|
||||
|
||||
/*Create 2 buttons*/
|
||||
lv_obj_t * btn1 = lv_btn_create(scr, NULL); /*Create a button on the screen*/
|
||||
lv_btn_set_fit(btn1, true, true); /*Enable automatically setting the size according to content*/
|
||||
lv_obj_set_pos(btn1, 60, 40); /*Set the position of the button*/
|
||||
|
||||
lv_obj_t * btn2 = lv_btn_create(scr, btn1); /*Copy the first button*/
|
||||
lv_obj_set_pos(btn2, 180, 80); /*Set the position of the button*/
|
||||
|
||||
/*Add labels to the buttons*/
|
||||
lv_obj_t * label1 = lv_label_create(btn1, NULL); /*Create a label on the first button*/
|
||||
lv_label_set_text(label1, "Button 1"); /*Set the text of the label*/
|
||||
|
||||
lv_obj_t * label2 = lv_label_create(btn2, NULL); /*Create a label on the second button*/
|
||||
lv_label_set_text(label2, "Button 2"); /*Set the text of the label*/
|
||||
|
||||
/*Delete the second label*/
|
||||
lv_obj_del(label2);
|
||||
```
|
||||
|
||||
## Bring to the foreground
|
||||
|
||||
There are four explicit ways to bring an object to the foreground:
|
||||
- Use `lv_obj_move_foreground(obj)` to bring an object to the foreground. Similarly, use `lv_obj_move_background(obj)` to move it to the background.
|
||||
- Use `lv_obj_move_up(obj)` to move an object one position up in the hierarchy, Similarly, use `lv_obj_move_down(obj)` to move an object one position down in the hierarchy.
|
||||
- Use `lv_obj_swap(obj1, obj2)` to swap the relative layer position of two objects.
|
||||
- When `lv_obj_set_parent(obj, new_parent)` is used, `obj` will be on the foreground of the `new_parent`.
|
||||
|
||||
|
||||
## Top and sys layers
|
||||
|
||||
LVGL uses two special layers named `layer_top` and `layer_sys`.
|
||||
Both are visible and common on all screens of a display. **They are not, however, shared among multiple physical displays.** The `layer_top` is always on top of the default screen (`lv_scr_act()`), and `layer_sys` is on top of `layer_top`.
|
||||
|
||||
The `layer_top` can be used by the user to create some content visible everywhere. For example, a menu bar, a pop-up, etc. If the `click` attribute is enabled, then `layer_top` will absorb all user clicks and acts as a modal.
|
||||
```c
|
||||
lv_obj_add_flag(lv_layer_top(), LV_OBJ_FLAG_CLICKABLE);
|
||||
```
|
||||
|
||||
The `layer_sys` is also used for similar purposes in LVGL. For example, it places the mouse cursor above all layers to be sure it's always visible.
|
||||
7
LVGL.Simulator/lvgl/docs/overview/new_widget.md
Normal file
@@ -0,0 +1,7 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/new_widget.md
|
||||
```
|
||||
|
||||
# New widget
|
||||
|
||||
227
LVGL.Simulator/lvgl/docs/overview/object.md
Normal file
@@ -0,0 +1,227 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/object.md
|
||||
```
|
||||
# Objects
|
||||
|
||||
In LVGL the **basic building blocks** of a user interface are the objects, also called *Widgets*.
|
||||
For example a [Button](/widgets/core/btn), [Label](/widgets/core/label), [Image](/widgets/core/img), [List](/widgets/extra/list), [Chart](/widgets/extra/chart) or [Text area](/widgets/core/textarea).
|
||||
|
||||
You can see all the [Object types](/widgets/index) here.
|
||||
|
||||
All objects are referenced using an `lv_obj_t` pointer as a handle. This pointer can later be used to set or get the attributes of the object.
|
||||
|
||||
## Attributes
|
||||
|
||||
### Basic attributes
|
||||
|
||||
All object types share some basic attributes:
|
||||
- Position
|
||||
- Size
|
||||
- Parent
|
||||
- Styles
|
||||
- Event handlers
|
||||
- Etc
|
||||
|
||||
You can set/get these attributes with `lv_obj_set_...` and `lv_obj_get_...` functions. For example:
|
||||
|
||||
```c
|
||||
/*Set basic object attributes*/
|
||||
lv_obj_set_size(btn1, 100, 50); /*Set a button's size*/
|
||||
lv_obj_set_pos(btn1, 20,30); /*Set a button's position*/
|
||||
```
|
||||
|
||||
To see all the available functions visit the [Base object's documentation](/widgets/obj).
|
||||
|
||||
### Specific attributes
|
||||
|
||||
The object types have special attributes too. For example, a slider has
|
||||
- Minimum and maximum values
|
||||
- Current value
|
||||
|
||||
For these special attributes, every object type may have unique API functions. For example for a slider:
|
||||
|
||||
```c
|
||||
/*Set slider specific attributes*/
|
||||
lv_slider_set_range(slider1, 0, 100); /*Set the min. and max. values*/
|
||||
lv_slider_set_value(slider1, 40, LV_ANIM_ON); /*Set the current value (position)*/
|
||||
```
|
||||
|
||||
The API of the widgets is described in their [Documentation](/widgets/index) but you can also check the respective header files (e.g. *widgets/lv_slider.h*)
|
||||
|
||||
## Working mechanisms
|
||||
|
||||
### Parent-child structure
|
||||
|
||||
A parent object can be considered as the container of its children. Every object has exactly one parent object (except screens), but a parent can have any number of children.
|
||||
There is no limitation for the type of the parent but there are objects which are typically a parent (e.g. button) or a child (e.g. label).
|
||||
|
||||
### Moving together
|
||||
|
||||
If the position of a parent changes, the children will move along with it.
|
||||
Therefore, all positions are relative to the parent.
|
||||
|
||||

|
||||
|
||||
```c
|
||||
lv_obj_t * parent = lv_obj_create(lv_scr_act()); /*Create a parent object on the current screen*/
|
||||
lv_obj_set_size(parent, 100, 80); /*Set the size of the parent*/
|
||||
|
||||
lv_obj_t * obj1 = lv_obj_create(parent); /*Create an object on the previously created parent object*/
|
||||
lv_obj_set_pos(obj1, 10, 10); /*Set the position of the new object*/
|
||||
```
|
||||
|
||||
Modify the position of the parent:
|
||||
|
||||

|
||||
|
||||
```c
|
||||
lv_obj_set_pos(parent, 50, 50); /*Move the parent. The child will move with it.*/
|
||||
```
|
||||
|
||||
(For simplicity the adjusting of colors of the objects is not shown in the example.)
|
||||
|
||||
### Visibility only on the parent
|
||||
|
||||
If a child is partially or fully outside its parent then the parts outside will not be visible.
|
||||
|
||||

|
||||
|
||||
```c
|
||||
lv_obj_set_x(obj1, -30); /*Move the child a little bit off the parent*/
|
||||
```
|
||||
|
||||
This behavior can be overwritten with `lv_obj_add_flag(obj, LV_OBJ_FLAG_OVERFLOW_VISIBLE);` which allow the children to be drawn out of the parent.
|
||||
|
||||
|
||||
### Create and delete objects
|
||||
|
||||
In LVGL, objects can be created and deleted dynamically at run time. It means only the currently created (existing) objects consume RAM.
|
||||
|
||||
This allows for the creation of a screen just when a button is clicked to open it, and for deletion of screens when a new screen is loaded.
|
||||
|
||||
UIs can be created based on the current environment of the device. For example one can create meters, charts, bars and sliders based on the currently attached sensors.
|
||||
|
||||
Every widget has its own **create** function with a prototype like this:
|
||||
```c
|
||||
lv_obj_t * lv_<widget>_create(lv_obj_t * parent, <other parameters if any>);
|
||||
```
|
||||
|
||||
Typically, the create functions only have a *parent* parameter telling them on which object to create the new widget.
|
||||
|
||||
The return value is a pointer to the created object with `lv_obj_t *` type.
|
||||
|
||||
|
||||
There is a common **delete** function for all object types. It deletes the object and all of its children.
|
||||
|
||||
```c
|
||||
void lv_obj_del(lv_obj_t * obj);
|
||||
```
|
||||
|
||||
`lv_obj_del` will delete the object immediately.
|
||||
If for any reason you can't delete the object immediately you can use `lv_obj_del_async(obj)` which will perform the deletion on the next call of `lv_timer_handler()`.
|
||||
This is useful e.g. if you want to delete the parent of an object in the child's `LV_EVENT_DELETE` handler.
|
||||
|
||||
You can remove all the children of an object (but not the object itself) using `lv_obj_clean(obj)`.
|
||||
|
||||
You can use `lv_obj_del_delayed(obj, 1000)` to delete an object after some time. The delay is expressed in milliseconds.
|
||||
|
||||
|
||||
## Screens
|
||||
|
||||
### Create screens
|
||||
The screens are special objects which have no parent object. So they can be created like:
|
||||
```c
|
||||
lv_obj_t * scr1 = lv_obj_create(NULL);
|
||||
```
|
||||
|
||||
Screens can be created with any object type. For example, a [Base object](/widgets/obj) or an image to make a wallpaper.
|
||||
|
||||
### Get the active screen
|
||||
There is always an active screen on each display. By default, the library creates and loads a "Base object" as a screen for each display.
|
||||
|
||||
To get the currently active screen use the `lv_scr_act()` function.
|
||||
|
||||
### Load screens
|
||||
|
||||
To load a new screen, use `lv_scr_load(scr1)`.
|
||||
|
||||
### Layers
|
||||
There are two automatically generated layers:
|
||||
- top layer
|
||||
- system layer
|
||||
|
||||
They are independent of the screens and they will be shown on every screen. The *top layer* is above every object on the screen and the *system layer* is above the *top layer*.
|
||||
You can add any pop-up windows to the *top layer* freely. But, the *system layer* is restricted to system-level things (e.g. mouse cursor will be placed there with `lv_indev_set_cursor()`).
|
||||
|
||||
The `lv_layer_top()` and `lv_layer_sys()` functions return pointers to the top and system layers respectively.
|
||||
|
||||
Read the [Layer overview](/overview/layer) section to learn more about layers.
|
||||
|
||||
|
||||
#### Load screen with animation
|
||||
|
||||
A new screen can be loaded with animation by using `lv_scr_load_anim(scr, transition_type, time, delay, auto_del)`. The following transition types exist:
|
||||
- `LV_SCR_LOAD_ANIM_NONE` Switch immediately after `delay` milliseconds
|
||||
- `LV_SCR_LOAD_ANIM_OVER_LEFT/RIGHT/TOP/BOTTOM` Move the new screen over the current towards the given direction
|
||||
- `LV_SCR_LOAD_ANIM_OUT_LEFT/RIGHT/TOP/BOTTOM` Move out the old screen over the current towards the given direction
|
||||
- `LV_SCR_LOAD_ANIM_MOVE_LEFT/RIGHT/TOP/BOTTOM` Move both the current and new screens towards the given direction
|
||||
- `LV_SCR_LOAD_ANIM_FADE_IN/OUT` Fade the new screen over the old screen, or vice versa
|
||||
|
||||
Setting `auto_del` to `true` will automatically delete the old screen when the animation is finished.
|
||||
|
||||
The new screen will become active (returned by `lv_scr_act()`) when the animation starts after `delay` time.
|
||||
All inputs are disabled during the screen animation.
|
||||
|
||||
### Handling multiple displays
|
||||
Screens are created on the currently selected *default display*.
|
||||
The *default display* is the last registered display with `lv_disp_drv_register`. You can also explicitly select a new default display using `lv_disp_set_default(disp)`.
|
||||
|
||||
`lv_scr_act()`, `lv_scr_load()` and `lv_scr_load_anim()` operate on the default screen.
|
||||
|
||||
Visit [Multi-display support](/overview/display) to learn more.
|
||||
|
||||
## Parts
|
||||
|
||||
The widgets are built from multiple parts. For example a [Base object](/widgets/obj) uses the main and scrollbar parts but a [Slider](/widgets/core/slider) uses the main, indicator and knob parts.
|
||||
Parts are similar to *pseudo-elements* in CSS.
|
||||
|
||||
The following predefined parts exist in LVGL:
|
||||
- `LV_PART_MAIN` A background like rectangle
|
||||
- `LV_PART_SCROLLBAR` The scrollbar(s)
|
||||
- `LV_PART_INDICATOR` Indicator, e.g. for slider, bar, switch, or the tick box of the checkbox
|
||||
- `LV_PART_KNOB` Like a handle to grab to adjust the value
|
||||
- `LV_PART_SELECTED` Indicate the currently selected option or section
|
||||
- `LV_PART_ITEMS` Used if the widget has multiple similar elements (e.g. table cells)
|
||||
- `LV_PART_TICKS` Ticks on scales e.g. for a chart or meter
|
||||
- `LV_PART_CURSOR` Mark a specific place e.g. text area's or chart's cursor
|
||||
- `LV_PART_CUSTOM_FIRST` Custom parts can be added from here.
|
||||
|
||||
The main purpose of parts is to allow styling the "components" of the widgets.
|
||||
They are described in more detail in the [Style overview](/overview/style) section.
|
||||
|
||||
## States
|
||||
The object can be in a combination of the following states:
|
||||
- `LV_STATE_DEFAULT` Normal, released state
|
||||
- `LV_STATE_CHECKED` Toggled or checked state
|
||||
- `LV_STATE_FOCUSED` Focused via keypad or encoder or clicked via touchpad/mouse
|
||||
- `LV_STATE_FOCUS_KEY` Focused via keypad or encoder but not via touchpad/mouse
|
||||
- `LV_STATE_EDITED` Edit by an encoder
|
||||
- `LV_STATE_HOVERED` Hovered by mouse (not supported now)
|
||||
- `LV_STATE_PRESSED` Being pressed
|
||||
- `LV_STATE_SCROLLED` Being scrolled
|
||||
- `LV_STATE_DISABLED` Disabled state
|
||||
- `LV_STATE_USER_1` Custom state
|
||||
- `LV_STATE_USER_2` Custom state
|
||||
- `LV_STATE_USER_3` Custom state
|
||||
- `LV_STATE_USER_4` Custom state
|
||||
|
||||
The states are usually automatically changed by the library as the user interacts with an object (presses, releases, focuses, etc.).
|
||||
However, the states can be changed manually too.
|
||||
To set or clear given state (but leave the other states untouched) use `lv_obj_add/clear_state(obj, LV_STATE_...)`
|
||||
In both cases OR-ed state values can be used as well. E.g. `lv_obj_add_state(obj, part, LV_STATE_PRESSED | LV_PRESSED_CHECKED)`.
|
||||
|
||||
To learn more about the states read the related section of the [Style overview](/overview/style).
|
||||
|
||||
## Snapshot
|
||||
A snapshot image can be generated for an object together with its children. Check details in [Snapshot](/others/snapshot).
|
||||
8
LVGL.Simulator/lvgl/docs/overview/renderers/arm-2d.md
Normal file
@@ -0,0 +1,8 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/renderers/arm-2d.md
|
||||
```
|
||||
# ARM-2D GPU
|
||||
|
||||
TODO
|
||||
|
||||
8
LVGL.Simulator/lvgl/docs/overview/renderers/dma2d.md
Normal file
@@ -0,0 +1,8 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/renderers/dma2d.md
|
||||
```
|
||||
# DMA2D GPU
|
||||
|
||||
TODO
|
||||
|
||||
20
LVGL.Simulator/lvgl/docs/overview/renderers/index.md
Normal file
@@ -0,0 +1,20 @@
|
||||
```eval_rst
|
||||
.. include:: /header.rst
|
||||
:github_url: |github_link_base|/overview/renderers/index.md
|
||||
```
|
||||
|
||||
# Renderers and GPUs
|
||||
|
||||
|
||||
```eval_rst
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
sw
|
||||
sdl
|
||||
arm-2d
|
||||
pxp-vglite
|
||||
dma2d
|
||||
```
|
||||
|
||||