Different parts of the project are available in documented form:
Code Documentation generated by Doxygen
"Brainstorming Documentation" of specific problems or thoughts
TODO / Roadmap
- Implement basic operations like copying, linking and renaming of icons
- do not forget to implement observer pattern for icon links as described [here](Concept/Brainstorming/Linking Icons.md)
- emit signals by MainWindow to specific slots in the Coordinator class that handle those actions. The data modification itself is to be handled by the IconSet class, where
notifyObserversis to be called
- work on current feature branch
- Implement basic operations on categories?
- Implement advananced operations like inserting icons
- Start implementing a general Parsing strategy that can be extended using a simple language like XML or JSON, so icon set definitions can be easily applied by "non programmers"
Icon Set Forge is written in C++ using the C++11 language standard. Using the Qt library (4.8.4) the program should be able to compile, run (and look and feel native) on Linux, OS X and Windows.
Concept and Design
The screen mockup has been created with the free and open source mockup tool pencil.
The UML class diagram has been created with PlantUML which can be called from the commandline for integration with your favourite buildscript / text editor.
Doxygen is used to generate docs from special documentation comments within the source code.
To generate the project's documentation run
doxygen Doxyfile in the top level folder of the
gh-pages branch, as this branch is used to display Icon Set Forge's
Where Can I start to Help?
AbstractScannerStrategy for the icon set type of your interest is always a great opportunity to contribute to this project.
If you want to join general development have a look at the roadmap and development that has been going on lately or ask where a helping hand could be of use.
How Can I Join?
Just leave a comment on what you are about to implement or at least commit to your fork asap (.e.g on a branch with self-explanatory name) so other developers are aware that that particular feature is taken care of by you. Before contributing make sure to have a look at the following guidelines and conventions.
Guidelines and Code Convention
I will not accept pull requests, that break consistency with the existing code base. This is to ensure maintainability and readability of the whole project. That being said nobody is perfect and I am generally up for both: Assisting in fixing "irregularities" and finding compromises :-)
Implementatation Specific Requirements
- Memory management has to be taken care of by implementing strict ownership policies
QOBjectderived classes come into play use parent/child mechanism properly
- use smart pointers wisely where they make sense (technically & semantically)
std::unique_ptras it has the strictest form of ownership rule
- e.g. use as function parameter, to indicate, that the functions "consumes ownership"
- or use for class members, that must be allocated by
newfor whatever reason to bind them to the classes scope and life time
std::shared_ptris about to be used, check if it is the best options and double check for potential cyclic references!
- Try to enforce const correctness as strict as possible (yeah I know my code can also be improved regarding that :-)
- Qt containers (
QVector, QList, ...) are to be used for compatibility with the Qt library
- STL smart pointers are to be used, as they support C++11's move semantics and should not induce any Qt compatibility problems
As mentioned above, the whole concept of smart pointers, move semantics and Qt in general is new to me, so there are probably many people out there with better understanding of certain details and C++ in general. If you think you are of such kind, do not hesistate to give me a hint or correct me where necessary.
Code Style Conventions
- Brackets and indentation as defined by 1TBS
- Tab: 4 spaces (Qt Creator's default setting)
- Inline documentation is to be written and generated with Doxygen
- Use Qt style (
/*! ... \param ...) for documentation.
- Do not use
BRIEFAUTOis active and thus the first line until the first dot is treated as brief description
- Do not use commands that resemble information that GIT already takes care of (
\author, \version, \date)
- Document (Doxygen) every class. At least a one-liner should be possible :-)
- Document (Doxygen) every function, that does not have a 100% self-explanatory name and implementation
- Implementation specific documentation (
// doc...) is to be applied wherever the code does not explain itself
- but first: check if restructuring (e.g. making 3 functions out of one) would make things clearer
- Do not pollute namespaces by commands like
using namespace std- especially in header files!
- Lines must not be longer than 80 characters
- Generally: It is advised to have a quick look as existing code to have an idea of what I would love to see
- In case you have any more questions you can ask me
- If you find myself violating the above, don't hesitate to tell me! :-)