Development Tricks: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
m (→‎Qt: typo)
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Development]]
[[Category:Development]]
{{TOC left}}
== Background ==
<big>'''This page shows a list of time-saving workflow tips for Devs who are developing for Scribus.'''
'''Use the "Table of Contents" to pinpoint a specific topic or for your own education feel free to browse the document. '''
'''If you have any dev tips of your own, please share them by editing this wiki page and adding it. Of course you need to login. Ask on IRC Freenode #Scribus for authorization'''</big>
{{Clear}}
== 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: 
:<code>-DWANT_GUI_LANG="en_GB;en"</code> 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.
== Debugging ==
=== Build Scribus with Debug symbols included ===
Use <code>'-DWANT-DEBUG=1'</code> flag at compile time. See [[Homebrew]] for more details.
=== 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 <code>qDebug</code> function :
:<code>qDebug() << blah << "some text";</code>
Note: Don't forget to <u>CLEAN YOU CODE</u> before issuing a patch
== Qt ==
Add your Qt related tricks below:
* Qt Creator is a powerful IDE.
:: Check out [[QtCreator_-_workflow_for_Scribus_and_Git_repository_under_Linux| QtCreator - workflow for Scribus and Git repos under Linux]]
== 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.


== Background ==
=== Patches ===
This page shows a list of time-saving workflow tips for Devs who are developing for Scribus. Feel free to add your shortcuts
==== How to get them approved faster ====
Patches should be in plain text.
<code>diff -u old_file.cpp new_file.cpp >difference1to2.diff </code> 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.


== make ==
'svn diff --revision 18833 > mypatch.diff' creates the patch from the revision 18833 to the version of your working dir.


* 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;de;fr;it;en"' to your cmake command.
Clean the patch so as to delete useless changes as tabs vs spaces.
* 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"


# perhaps there can be a script here
Please ensure that when you have changed something in the code you put a comment immediately before the change. Ensure you put a date and who made the change and what the change is for. Over time, these will be weeded out, but it useful to see what has been altered.
# That automagically does this?


== traces in the terminal==
==== Applying the right diff flags ====
Whenever you need to understand what happens un the code, it's possible to issue some traces on the terminal using qDebug function :
To apply a .diff file do <code>patch -p0 < difference1to2.diff</code>. Option '-px' enables to skip x levels of the path of the files as specified in the patch, in case the patch includes some parasite path root levels.
<pre>qDebug() << blah << "some text";</pre>


Clean your code before issuing a patch, unless its absolutely necessary to mess the user's terminal.
== MacOSX ==
* To quickly compile the latest Scribus bleeding edge trunk use [[Scribus and Homebrew|Homebrew]] to do this. Spend less time by automating the process.


== Related ==
== Related ==
* [[Low_Hanging_Fruit]]
* [[Low_Hanging_Fruit]]
* [[How_Can_I_Help]]
* [[How_Can_I_Help]]

Latest revision as of 18:41, 27 February 2014

Background

This page shows a list of time-saving workflow tips for Devs who are developing for Scribus.

Use the "Table of Contents" to pinpoint a specific topic or for your own education feel free to browse the document.

If you have any dev tips of your own, please share them by editing this wiki page and adding it. Of course you need to login. Ask on IRC Freenode #Scribus for authorization

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.

Debugging

Build Scribus with Debug symbols included

Use '-DWANT-DEBUG=1' flag at compile time. See Homebrew for more details.

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

Qt

Add your Qt related tricks below:

  • Qt Creator is a powerful IDE.
Check out QtCreator - workflow for Scribus and Git repos under Linux

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.

Patches

How to get them approved faster

Patches should be in plain text. diff -u old_file.cpp new_file.cpp >difference1to2.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.

'svn diff --revision 18833 > mypatch.diff' creates the patch from the revision 18833 to the version of your working dir.

Clean the patch so as to delete useless changes as tabs vs spaces.

Please ensure that when you have changed something in the code you put a comment immediately before the change. Ensure you put a date and who made the change and what the change is for. Over time, these will be weeded out, but it useful to see what has been altered.

Applying the right diff flags

To apply a .diff file do patch -p0 < difference1to2.diff. Option '-px' enables to skip x levels of the path of the files as specified in the patch, in case the patch includes some parasite path root levels.

MacOSX

  • To quickly compile the latest Scribus bleeding edge trunk use Homebrew to do this. Spend less time by automating the process.

Related