BigW Consortium Gitlab

Commit 6852f6ee by Gabor

Merge branch 'beta' into lv_sw

parents 2965b351 7dfb4eb3
# 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 at [atom@github.com](mailto:atom@github.com). 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/
# Contributing to Littlev Graphics Library
First of all thank you for reading these guide before contributing!
In this guide you can read how can you help in developing the Littlev Graphic Library. These are not strict rules rather just suggestions. If you have a constructive idea just create pull request on this document!
### Table Of Content
* [Who can contribute?](#who-can-contribute)
* [How to report an issue?](#how-to-report-an-issue)
* [Simple issue](#simple-issue)
* [Complex issue](#complex-issue)
* [How to suggest a feature?](#how-to-suggest-a-feature)
* [How to implement a feature?](#how-to-implement-a-feature)
* [Styling guide](#styling-guide)
* [Git Commit Messages](#Git-commit-messages)
* [File format](#file-format)
* [Functions](#functions)
* [Variables](#variables)
* [Defines](#defines)
* [Comments](#comments)
* [Formatting](#formatting)
## Who can contribute?
Everybody is welcome in contributing independently from skills, programming level or any personal attribute.
There are several ways to contribute in the graphics library like:
* Report an issue
* Suggest feature
* Fix an issue
* Implement a feature
Please, take a look at [CODE_OF_CONDUCT](https://github.com/littlevgl/lvgl/blob/master/docs/CODE_OF_CONDUCT.md)
## How to report an issue?
There are 3 permanent branches:
* `master` for stable, released versions
* `beta` for developers, all feature branches merged here first
* `bugfix` for hotfixes, not new features
### Simple issue
If you find an issue which is very simple to fix, and you fixed it, please send a pull request against `beta` branch.
A simple issue could be:
* Misspelled names
* Comment: misspelling or grammatical error in comments
* Variable: misspelled variable name (e.g. ***ojb**_next* instead of ***obj**_next*)
* Define: only local defines in files because global defines affect API
* Function: only static function name because global functions affect API
* Not handled error case:
* A parameter can be NULL (during normal usage)
* Negative index in array or over indexing
* Overflow in variable
* Anything which is local an can be fixed with a few lines of code
### Complex issue
If you find a complex issue which:
* might be simple but you don't know its origin
* affects a whole file, module or even the architecture
* needs deeper discussion
please create a **new issue** and describe
* what you experience
* how to reproduce the issue (maybe with example code)
* version you are using (lvgl.h)
* misc library version (misc.h)
## How to suggest a feature?
If you have a good and useful idea you can use GitHub issues to suggest a new feature. Please note the followings on feature requests:
* What the new feature is about?
* Why/Where/In which case is it useful/helpful/relevant?
* Can you help in implementing it?
After a discussion we figure out the specification of the new feature and the technical details/implementation possibilities.
With the knowledge of how to do it somebody can implement the new feature.
The new feature should be in a new branch.
Keep in mind if you wouldn't like to do the implementation there is no guarantee that it will be ready in the new future.
However if you would like to force it, take a look at this page: [Feature request service](http://www.gl.littlev.hu/services#feature)
## How to implement a feature?
In [docs/TODO_MINOR.md](https://github.com/littlevgl/lvgl/blob/master/docs/TODO_MINOR.md) and [docs/TODO_PATCH.md](https://github.com/littlevgl/lvgl/blob/master/docs/TODO_PATCH.md) you can see some ideas which are waiting for somebody to realize them! If want to deal with a feature from this files, please start an issue and discusse the details.
## Styling guide
### Git Commit Messages
* Use the present tense ("Add feature" not "Added feature")
* Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
* Limit the first line to 72 characters or less
* Reference issues and pull requests liberally after the first line
### File format
Use [misc/templ/templ.c](https://github.com/littlevgl/misc/blob/master/templ/templ.c) and [misc/templ/templ.h](https://github.com/littlevgl/misc/blob/master/templ/templ.h)
### Functions
* try to write function shorter then is 40 lines
* always shorter then 100 lines (except very straightforwards)
* in function names:
* words sparated by '_'
* only lower case letters
* only clear abbreviation (OK: *lv_xy_get_title_txt*, BAD: *lv_xy_get_ttxt*)
#### Global functions names (API)
An example: *lv_btn_set_state()*
* starts with *lv*
* followed by module name: *btn*, *label*, *style* etc.
* followed by the action: *set*, *get*, *refr* etc.
* closed with subject: *name*, *size*, *state* etc.
* optional like in *lv_obj_del()* it is missing
* could contain more words: *long_mode*, *point_all*
#### Static functions names
Names can be used freely.
### Variables
* words sparated by '_'
* always lower case
* one line one declaration (BAD: char x, y;)
* use `<stdint.h>` (*uint8_t*, *int32_t* etc)
* declare variables when 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)
### Defines
* always upper case
* starts with *LV_*
* followed by the modul: *OBJ*, *BTN* etc.
* closed by the subject: *ANIM_TIME*, *VALUE_MIN*, *WIDTH_DEF*
### Comments
Before every function have a comment like this:
```
/**
* 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 */`
### Formatting
Here is example to show bracket placing and using of white spaces:
```
/**
* 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 bracket 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 start inline*/
lv_label_refr_text(label);
return;
}
.
.
.
}
```
Use 4 spaces indentation instead of tab.
# LittleV Graphics Libraray
![LittlevGL cover](http://www.gl.littlev.hu/home/main_cover.png)
![LittlevGL cover](http://www.gl.littlev.hu/home/main_cover_small.png)
The LittlevGL is a graphics library which allows you to create graphical user interfaces (GUI) from the most simple monochrome designs to amazing GUIs for high resolution TFTs. No double buffering is required to use transparency and smooth animations.
LittlevGL is a graphics library to create Graphical User Interfaces (GUI) on TFT, LCD or monochrome displays using microcontroller based embedded systems.
Transparency, anti-aliassing and smooth animations can be used with no double buffering so typically no external memories are required.
The graphics library is written in C and it is completely hardware independent. You can even run it in a PC simulator without any embedded hardware.
Visit the http://gl.littlev.hu
Homepage: http://gl.littlev.hu
## Key features
* Hardware independent
* Support any modern microcontroller
* No external RAM, FPU or GPU required
* High resolution TFTs and monochrome displays are also supported
* Scalable and modular
* Clear and well-structured source code
* Color depth options: 24 bit, 16 bit, 8 bot or 1 bit
* Hardware independent, support any modern microcontroller
* High resolution TFTs, monochrome or any type of display supported (24/16/8/1 bit color depth)
* External RAM, FPU or GPU not required just optional
* Build GUI from simple graphical objects
* Buttons, Labels, Images
* Charts, Lists, Bars, Sliders, Text areas etc.
* High level graphical features:
* High level graphical features without double buffering
* Antialiassing (font or full screen)
* Animations
* Transparency
* Gradient colors
* Smooth dragging and scrolling
* Layers
* Layers
* Customizable appearance with styles
* Applications for complex tasks
* Can run in a PC simulator
* Modular and well-structured source code
* Actively developed
## Porting
The following functions has to be provided
* hal/disp `disp_fill(x1, y1, x2, y2, color)` to fill area with a color
* hal/disp `disp_map(x1, y1, x2, y2, &color_array)` copy a color map to an area
* hal/disp `disp_color_cpy(dest, src, length, opa)` copy pixel, optional for GPU
* hal/indev `indev_get(id, &x, &y)` get the *x* and *y* coordinates from an input device (e.g. touch pad)
* hal/systick `systick_get()` get a system tick with 1 ms resolution
* hal/systick `systick_elapse(prev_time)` get the elapsed milliseconds sience *prev_time*
......@@ -74,16 +74,10 @@ If you don't have got an embedded hardware you can test the graphics library in
There is a pre-configured PC project for **Eclipse CDT** in this repository: https://github.com/littlevgl/proj_pc
## Contributing
1. Fork it!
2. Create your feature branch: `git checkout -b my-new-feature`
3. Commit your changes: `git commit -am 'Add some feature'`
4. Push to the branch: `git push origin my-new-feature`
5. Submit a pull request!
If you find an issue, please report it via GitHub!
See [CONTRIBUTING.md](https://github.com/littlevgl/lvgl/blob/master/docs/CONTRIBUTING.md)
## Donate
If you are pleased with the graphics library and found it useful pleas support its further development:
If you are pleased with the graphics library and found it useful please support its further development:
[![Donate](https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif)](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=GJV3SC5EHDANS)
# TODOs for major versions
Major versions released typically when API changes are required
## Contributing
Please create an issue to suggest a new feature instead of adding pull request to this file.
## v5
- [ ] rename repository from *lvgl* to *littlevgl*
- [ ] define renames: e.g. *USE_LV_BTN* to *LV_BTN_USE*
- [ ] Remove LV_DOWNSCALE (LV_ANTIALIAS will be used instead)
- [ ] *lv_ta_get_txt* rename to *lv_ta_get_text*
- [ ] btnm_action pass text instead of text_id
# TODOs for minor versions
Minor versions (x.1.0, x.2.0 ...) released when one or more new feature is addded without changing the API. New features can be added with major versions (1.0.0, 2.0.0 ...) too.
## Contributing
Please create an issue to suggest a new feature instead of adding pull request to this file.
## Ideas
Here are ideas which are not assigned to a minor version yet:
- label: add a horzintal line (e.g. underline or line through).
- label long mode: dot begin
- music player app
- files app update: show content as text
- GUI remote control
- automatically build GUI from file (e.g. XML, JSON or HTML)
- lv_split: new object type, a hor. or ver. line for decoration purpose
- lv_valset: new object type, a label with "+" and "-" buttons
- lv_tabview: new object type to organise content with tabs
- lv_btngrp: new object type to display more buttons to choose an option from them
- lv_switch: new object type, turn on/off by tap (a little slider)
- lv_roller: new object type, a roller to select a value (like on smartphones)
## v4.2
- [x] Double VDB support: one for rendering, another to transfer former rendered image to frame buffer in the background (e.g. with DMA) [#15](https://github.com/littlevgl/lvgl/issues/15)
- [x] lv_group: to control without touch pad. Issue [#14](https://github.com/littlevgl/lvgl/issues/14)
- [x] lv_page: scrl def fit modification: hor:false, ver:true, and always set width to parent width
- [x] lv_btn: add lv_btn_get_..._action
- [x] lv_list: add lv_list_get_element_label/img
- [x] lv_ta: lv_ta_set_one_line to configure the Text area to one lined input field
- [x] style animations add
- [x] lv_btnm: besides 0. byte (width dsc) 1. byte: hidden (\177, 0x7F, delete)
# TODOs for patch versions
Patch versions (x.y.1, x.y.2) contain bugfixes without changing the API but they can apppear in minor (x.1.0, x.2.0) or major (1.0.0, 2.0.0) versions too.
Bugfixes are done in `bugfix` branche.
The bugfixes of the still not released version are in `beta` branche.
## Contributing
Please create an issue to introduce a bug instead of adding pull request to this file.
## Next release
- [x] lv_slider: don't let indicator or bar to disappear because of hpad/vpad
- [x] lv_ta: memory leak if deleted in password mode
......@@ -45,12 +45,12 @@ extern "C" {
*********************/
/*Current version of LittlevGL*/
#define LVGL_VERSION_MAJOR 4
#define LVGL_VERSION_MINOR 1
#define LVGL_VERSION_PATH 1
#define LVGL_VERSION_MINOR 2
#define LVGL_VERSION_PATH 0
/*Required misc. library version*/
#define LV_MISC_REQ_MAJOR 4
#define LV_MISC_REQ_MINOR 1
#define LV_MISC_REQ_MINOR 2
#define LV_MISC_REQ_PATCH 0
#if MISC_VERSION_MAJOR != LV_MISC_REQ_MAJOR /*The version major has to match*/
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment