Difference between revisions of "Development Tricks"

From Scribus Wiki
Jump to navigation Jump to search
Line 29: Line 29:
* correct { and  } positionning
* correct { and  } positionning
* use spaces where needed
* use spaces where needed
See [[Official:Coding_standards]] for a very detailed list and lots of advices.
See [[Official:Coding_Standards]] for a very detailed list and lots of advices.
=== Submitting patches ===
=== Submitting patches ===

Revision as of 18:17, 22 January 2014


This page shows a list of time-saving workflow tips for Devs who are developing for Scribus. Feel free to add your shortcuts

Time Reducing Strategies

Minimize compile time by specifying preferred language

  • Reduce the number of files copied in the "make install" step by limiting the number of used languages to the minimum necessary. For this, add:
-DWANT_GUI_LANG="en_GB;en" to your cmake command if you only want english language GUI.

Manually copying object file to binary directory

  • If you know that only a single object file has been written by "make" (as an example when you're modifying the source of a plugin), if you're on a slow computer you can speed up the compile/run/tweak cycle by manually copying the object file to the binary directory, instead of doing "make install"

Use all CPU cores

  • Use all the cores of your CPU to compile faster. That's the -j option. If you got 8 cores, use : 'make -j8' and 'make install -j8' and you will make lot faster.


Traces in the terminal

Whenever you need to understand what happens in the code, it's possible to output traces in to the terminal using qDebug function :

qDebug() << blah << "some text";

Note: Don't forget to CLEAN YOU CODE before issuing a patch


Ease of Communication

Coding standards

Please look at used standard in scribus's code and reproduce them. Sample :

  • use tabs not spaces
  • correct { and } positionning
  • use spaces where needed

See Official:Coding_Standards for a very detailed list and lots of advices.

Submitting patches

Patches should be in plain text. diff -u old_file.cpp new_file.cpp >difference.diff is the best way of sending them. Please do not send patches to the main list. Remember to use -u (unified diff) as other types of diff are painful to use.