Skip to content

Latest commit

 

History

History
91 lines (60 loc) · 5.71 KB

Development.md

File metadata and controls

91 lines (60 loc) · 5.71 KB

Developer Information

Documentation

Different parts of the project are available in documented form:

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 notifyObservers is to be called
    • work on current feature branch operations until runnable
  • 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"

Technology Used

Implementation

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.

Documentation

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 github.io page.

Contributing

Where Can I start to Help?

Implementing an 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
    • whenever QOBject derived classes come into play use parent/child mechanism properly
    • use smart pointers wisely where they make sense (technically & semantically)
      • prefer std::unique_ptr as 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 new for whatever reason to bind them to the classes scope and life time
      • if std::shared_ptr is 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 \brief as BRIEFAUTO is 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! :-)