This file is indexed.

/usr/share/qgis/doc/CODING.html is in qgis-common 2.0.1-2build2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674
 675
 676
 677
 678
 679
 680
 681
 682
 683
 684
 685
 686
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786
 787
 788
 789
 790
 791
 792
 793
 794
 795
 796
 797
 798
 799
 800
 801
 802
 803
 804
 805
 806
 807
 808
 809
 810
 811
 812
 813
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868
 869
 870
 871
 872
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898
 899
 900
 901
 902
 903
 904
 905
 906
 907
 908
 909
 910
 911
 912
 913
 914
 915
 916
 917
 918
 919
 920
 921
 922
 923
 924
 925
 926
 927
 928
 929
 930
 931
 932
 933
 934
 935
 936
 937
 938
 939
 940
 941
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952
 953
 954
 955
 956
 957
 958
 959
 960
 961
 962
 963
 964
 965
 966
 967
 968
 969
 970
 971
 972
 973
 974
 975
 976
 977
 978
 979
 980
 981
 982
 983
 984
 985
 986
 987
 988
 989
 990
 991
 992
 993
 994
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META NAME="generator" CONTENT="http://txt2tags.org">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>QGIS</TITLE>

<!-- Included /build/buildd/qgis-2.0.1/doc/style.css -->
<STYLE TYPE="text/css">
body{  background: white;
  color: black;
  font-family: arial,sans-serif;
}
pre { margin-left: 2em;
      border: 1;
      padding: 4px;
      background: #ececec; }
pre, code { font-family: monospace } 


.overview{ font: 1.82em; font-weight: bold;}

h1{  background-color: #F6F6F6;
  color: #8FB171; 
  font-size: large;  
  font-weight: bold;
  font-family: luxi serif, georgia, times new roman, times, serif;
  background: none;
  padding: 0.75em 0 0;
  margin: 0;
  line-height: 1.1em;
  border-bottom: 5px solid #DCEB5C;
}
h2{  background-color: #F6F6F6;
  color: #8FB171; 
  font-size: large;  
  font-weight: normal;
  font-family: luxi serif, georgia, times new roman, times, serif;
  background: none;
  padding: 0.75em 0 0;
  margin: 0;
  line-height: 1.1em;
}
h3{  background-color: #F6F6F6;
  color: #729FCF;
  font-family: luxi serif, georgia, times new roman, times, serif;
  font-weight: bold;
  font-size: medium;
}
h4{  background-color: #F6F6F6;
  color: #729FCF;
  font-family: luxi serif, georgia, times new roman, times, serif;
  font-weight: normal;
  font-size: medium;
}
h5{    background-color: #F6F6F6;
   color: #729FCF;
   font-family: luxi serif, georgia, times new roman, times, serif;
   font-weight: bold;
   font-size: small;
}
a{  color: #729FCF;
  font-family: arial,sans-serif;
  font-size: small;
}
label{  background-color: #FFFFCC;
  border: 1px solid black;
  margin: 1px;
  padding: 0px 3px; 
  font-size: small;
}
</STYLE>

</HEAD>
<BODY>

<DIV CLASS="header" ID="header">
<H1>QGIS</H1>
<H3>Developers guide for QGIS</H3>
</DIV>

<DIV CLASS="toc">

  <OL>
  <LI><A HREF="#toc1">QGIS Coding Standards</A>
    <UL>
    <LI><A HREF="#toc2">1.1. Classes</A>
      <UL>
      <LI><A HREF="#toc3">1.1.1. Names</A>
      <LI><A HREF="#toc4">1.1.2. Members</A>
      <LI><A HREF="#toc5">1.1.3. Accessor Functions</A>
      <LI><A HREF="#toc6">1.1.4. Functions</A>
      </UL>
    <LI><A HREF="#toc7">1.2. Qt Designer</A>
      <UL>
      <LI><A HREF="#toc8">1.2.1. Generated Classes</A>
      <LI><A HREF="#toc9">1.2.2. Dialogs</A>
      </UL>
    <LI><A HREF="#toc10">1.3. C++ Files</A>
      <UL>
      <LI><A HREF="#toc11">1.3.1. Names</A>
      <LI><A HREF="#toc12">1.3.2. Standard Header and License</A>
      <LI><A HREF="#toc13">1.3.3. Keyword Substitution</A>
      </UL>
    <LI><A HREF="#toc14">1.4. Variable Names</A>
    <LI><A HREF="#toc15">1.5. Enumerated Types</A>
    <LI><A HREF="#toc16">1.6. Global Constants</A>
    <LI><A HREF="#toc17">1.7. Editing</A>
      <UL>
      <LI><A HREF="#toc18">1.7.1. Tabs</A>
      <LI><A HREF="#toc19">1.7.2. Indentation</A>
      <LI><A HREF="#toc20">1.7.3. Braces</A>
      </UL>
    <LI><A HREF="#toc21">1.8. API Compatibility</A>
    <LI><A HREF="#toc22">1.9. Coding Style</A>
      <UL>
      <LI><A HREF="#toc23">1.9.1. Where-ever Possible Generalize Code</A>
      <LI><A HREF="#toc24">1.9.2. Prefer Having Constants First in Predicates</A>
      <LI><A HREF="#toc25">1.9.3. Whitespace Can Be Your Friend</A>
      <LI><A HREF="#toc26">1.9.4. Add Trailing Identifying Comments</A>
      <LI><A HREF="#toc27">1.9.5. Use Braces Even for Single Line Statements</A>
      <LI><A HREF="#toc28">1.9.6. Book recommendations</A>
      </UL>
    </UL>
  <LI><A HREF="#toc29">GIT Access</A>
    <UL>
    <LI><A HREF="#toc30">2.1. Installation</A>
      <UL>
      <LI><A HREF="#toc31">2.1.1. Install git for GNU/Linux</A>
      <LI><A HREF="#toc32">2.1.2. Install git for Windows</A>
      <LI><A HREF="#toc33">2.1.3. Install git for OSX</A>
      </UL>
    <LI><A HREF="#toc34">2.2. Accessing the Repository</A>
    <LI><A HREF="#toc35">2.3. Check out a branch</A>
    <LI><A HREF="#toc36">2.4. QGIS documentation sources</A>
    <LI><A HREF="#toc37">2.5. GIT Documentation</A>
    <LI><A HREF="#toc38">2.6. Development in branches</A>
      <UL>
      <LI><A HREF="#toc39">2.6.1. Purpose</A>
      <LI><A HREF="#toc40">2.6.2. Procedure</A>
      </UL>
    <LI><A HREF="#toc41">2.7. Submitting Patches</A>
      <UL>
      <LI><A HREF="#toc42">2.7.1. Patch file naming</A>
      <LI><A HREF="#toc43">2.7.2. Create your patch in the top level QGIS source dir</A>
      <LI><A HREF="#toc44">2.7.3. Getting your patch noticed</A>
      <LI><A HREF="#toc45">2.7.4. Due Diligence</A>
      </UL>
    <LI><A HREF="#toc46">2.8. Obtaining GIT Write Access</A>
    </UL>
  <LI><A HREF="#toc47">Unit Testing</A>
    <UL>
    <LI><A HREF="#toc48">3.1. The QGIS testing framework  - an overview</A>
    <LI><A HREF="#toc49">3.2. Creating a unit test</A>
    <LI><A HREF="#toc50">3.3. Adding your unit test to CMakeLists.txt</A>
    <LI><A HREF="#toc51">3.4. The ADD_QGIS_TEST macro explained</A>
    <LI><A HREF="#toc52">3.5. Building your unit test</A>
    <LI><A HREF="#toc53">3.6. Run your tests</A>
    </UL>
  <LI><A HREF="#toc54">Getting up and running with QtCreator and QGIS</A>
    <UL>
    <LI><A HREF="#toc55">4.1. Installing QtCreator</A>
    <LI><A HREF="#toc56">4.2. Setting up your project</A>
    <LI><A HREF="#toc57">4.3. Setting up your build environment</A>
    <LI><A HREF="#toc58">4.4. Setting your run environment</A>
    <LI><A HREF="#toc59">4.5. Running and debugging</A>
    </UL>
  <LI><A HREF="#toc60">HIG (Human Interface Guidelines)</A>
  <LI><A HREF="#toc61">Authors</A>
  </OL>

</DIV>
<DIV CLASS="body" ID="body">

<A NAME="toc1"></A>
<H1>1. QGIS Coding Standards</H1>

<P>
These standards should be followed by all QGIS developers.
</P>

<A NAME="toc2"></A>
<H2>1.1. Classes</H2>

<A NAME="toc3"></A>
<H3>1.1.1. Names</H3>

<P>
Class in QGIS begin with Qgs and are formed using mixed case. 
</P>

<div class="code"><PRE>
Examples:
  QgsPoint
  QgsMapCanvas
  QgsRasterLayer
</PRE></div>

<A NAME="toc4"></A>
<H3>1.1.2. Members</H3>

<P>
Class member names begin with a lower case <I>m</I> and are formed using mixed
case.
</P>

<div class="code"><PRE>
  mMapCanvas  
  mCurrentExtent
</PRE></div>

<P>
All class members should be private.
<B>Public class members are STRONGLY discouraged</B>
</P>

<A NAME="toc5"></A>
<H3>1.1.3. Accessor Functions</H3>

<P>
Class member values should be obtained through accesssor functions. The
function should be named without a <I>get</I> prefix. Accessor functions for the
two private members above would be: 
</P>

<div class="code"><PRE>
  mapCanvas()
  currentExtent()
</PRE></div>

<A NAME="toc6"></A>
<H3>1.1.4. Functions</H3>

<P>
Function names begin with a lowercase letter and are formed using mixed case.
The function name should convey something about the purpose of the function.
</P>

<div class="code"><PRE>
  updateMapExtent()
  setUserOptions()
</PRE></div>

<A NAME="toc7"></A>
<H2>1.2. Qt Designer</H2>

<A NAME="toc8"></A>
<H3>1.2.1. Generated Classes</H3>

<P>
QGIS classes that are generated from Qt Designer (ui) files should have a
<I>Base</I> suffix. This identifies the class as a generated base class.
</P>

<div class="code"><PRE>
Examples:
  QgsPluginManagerBase
  QgsUserOptionsBase
</PRE></div>

<A NAME="toc9"></A>
<H3>1.2.2. Dialogs</H3>

<P>
All dialogs should implement the following:
 * Tooltip help for all toolbar icons and other relevant widgets
 * WhatsThis help for <B>all</B> widgets on the dialog
 * An optional (though highly recommended) context sensitive <I>Help</I> button
   that directs the user to the appropriate help page by launching their web
   browser
</P>

<A NAME="toc10"></A>
<H2>1.3. C++ Files</H2>

<A NAME="toc11"></A>
<H3>1.3.1. Names</H3>

<P>
C++ implementation and header files should be have a .cpp and .h extension
respectively.  Filename should be all lowercase and, in the case of classes,
match the class name.
</P>

<div class="code"><PRE>
Example:
  Class QgsFeatureAttribute source files are 
    qgsfeatureattribute.cpp and qgsfeatureattribute.h
</PRE></div>

<P>
/!\ <B>Note:</B> in case it is not clear from the statement above, for a filename 
to match a class name it implicitly means that each class should be declared 
and implemented in its own file. This makes it much easier for newcomers to 
identify where the code is relating to specific class.
</P>

<A NAME="toc12"></A>
<H3>1.3.2. Standard Header and License</H3>

<P>
Each source file should contain a header section patterned after the following
example:
</P>

<div class="code"><PRE>
/***************************************************************************
    qgsfield.cpp - Describes a field in a layer or table
     --------------------------------------
    Date                 : 01-Jan-2004
    Copyright            : (C) 2004 by Gary E.Sherman
    Email                : sherman at mrcc.com
/***************************************************************************
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.                                   *
 *                                                                         *
 ***************************************************************************/
</PRE></div>

<A NAME="toc13"></A>
<H3>1.3.3. Keyword Substitution</H3>

<P>
In the days of SVN we used to require that each source file should contain the
$Id$ keyword. Keyword substitution is not supported by GIT and so should no
longer be used.
</P>

<A NAME="toc14"></A>
<H2>1.4. Variable Names</H2>

<P>
Variable names begin with a lower case letter and are formed using mixed case.
</P>

<div class="code"><PRE>
Examples:
  mapCanvas
  currentExtent
</PRE></div>

<A NAME="toc15"></A>
<H2>1.5. Enumerated Types</H2>

<P>
Enumerated types should be named in CamelCase with a leading capital e.g.:
</P>

<div class="code"><PRE>
    enum UnitType
    {
      Meters,
      Feet,
      Degrees,
      UnknownUnit
    } ;
</PRE></div>

<P>
Do not use generic type names that will conflict with other types. e.g. use
"UnkownUnit" rather than "Unknown"
</P>

<A NAME="toc16"></A>
<H2>1.6. Global Constants</H2>

<P>
Global constants should be written in upper case underscore separated e.g.:
</P>

<div class="code"><PRE>
const long GEOCRS_ID = 3344;
</PRE></div>

<A NAME="toc17"></A>
<H2>1.7. Editing</H2>

<P>
Any text editor/IDE can be used to edit QGIS code, providing the following
requirements are met.
</P>

<A NAME="toc18"></A>
<H3>1.7.1. Tabs</H3>

<P>
Set your editor to emulate tabs with spaces. Tab spacing should be set to 2
spaces.
</P>

<A NAME="toc19"></A>
<H3>1.7.2. Indentation</H3>

<P>
Source code should be indented to improve readability. There is a .indent.pro
file in the QGIS src directory that contains the switches to be used when
indenting code using the GNU indent program. If you don't use GNU indent, you
should emulate these settings.
</P>

<A NAME="toc20"></A>
<H3>1.7.3. Braces</H3>

<P>
Braces should start on the line following the expression:
</P>

<div class="code"><PRE>
  if(foo == 1)
  {
    // do stuff
    ...
   }else
  {
    // do something else
    ...
  }
</PRE></div>

<P>
There is a scripts/prepare-commit.sh that looks up the changed files and
reindents them using astyle.  This should be run before committing.
</P>
<P>
As newer versions of astyle indent differently than the version used to do a
complete reindentation of the source, the script uses an old astyle version,
that we include in our repository.
</P>

<A NAME="toc21"></A>
<H2>1.8. API Compatibility</H2>

<P>
From QGIS 1.0 we will provide a stable, backwards compatible API. This will
provide a stable basis for people to develop against, knowing their code will
work against any of the 1.x QGIS releases (although recompiling may be
required).Cleanups to the API should be done in a manner similar to the
Trolltech developers e.g.
</P>

<div class="code"><PRE>
class Foo 
{
  public:
    /** This method will be deprecated, you are encouraged to use 
      doSomethingBetter() rather.
      @see doSomethingBetter()
     */
    bool doSomething();

    /** Does something a better way.
      @note This method was introduced in QGIS version 1.1
     */
    bool doSomethingBetter();

}
</PRE></div>

<A NAME="toc22"></A>
<H2>1.9. Coding Style</H2>

<P>
Here are described some programming hints and tips that will hopefully reduce
errors, development time, and maintenance.
</P>

<A NAME="toc23"></A>
<H3>1.9.1. Where-ever Possible Generalize Code</H3>

<div class="code"><PRE>
If you are cut-n-pasting code, or otherwise writing the same thing more than
once, consider consolidating the code into a single function.
</PRE></div>

<P>
This will:
</P>

<UL>
<LI>allow changes to be made in one location instead of in multiple places
<LI>help prevent code bloat
<LI>make it more difficult for multiple copies to evolve differences over time,
  thus making it harder to understand and maintain for others
</UL>

<A NAME="toc24"></A>
<H3>1.9.2. Prefer Having Constants First in Predicates</H3>

<P>
Prefer to put constants first in predicates. 
</P>

<div class="code"><PRE>
"0 == value" instead of "value == 0"
</PRE></div>

<P>
This will help prevent programmers from accidentally using "=" when they meant
to use "==", which can introduce very subtle logic bugs.  The compiler will
generate an error if you accidentally use "=" instead of "==" for comparisons
since constants inherently cannot be assigned values.
</P>

<A NAME="toc25"></A>
<H3>1.9.3. Whitespace Can Be Your Friend</H3>

<P>
Adding spaces between operators, statements, and functions makes it easier for
humans to parse code.
</P>
<P>
Which is easier to read, this:
</P>

<div class="code"><PRE>
if (!a&amp;&amp;b)
</PRE></div>

<P>
or this:
</P>

<div class="code"><PRE>
if ( ! a &amp;&amp; b )
</PRE></div>

<A NAME="toc26"></A>
<H3>1.9.4. Add Trailing Identifying Comments</H3>

<P>
Adding comments at the end of function, struct and class implementations makes
it easier to find them later.
</P>
<P>
Consider that you're at the bottom of a source file and need to find a very
long function -- without these kinds of trailing comments you will have to page
up past the body of the function to find its name.  Of course this is ok if you
wanted to find the beginning of the function; but what if you were interested
at code near its end?  You'd have to page up and then back down again to the
desired part.
</P>
<P>
e.g.,
</P>

<div class="code"><PRE>
void foo::bar()
{ 
    // ... imagine a lot of code here 
} // foo::bar()
</PRE></div>

<A NAME="toc27"></A>
<H3>1.9.5. Use Braces Even for Single Line Statements</H3>

<P>
Using braces for code in if/then blocks or similar code structures even for
single line statements means that adding another statement is less likely to
generate broken code.
</P>
<P>
Consider:
</P>

<div class="code"><PRE>
  if (foo)
    bar();
 else
    baz();
</PRE></div>

<P>
Adding code after bar() or baz() without adding enclosing braces would create
broken code.  Though most programmers would naturally do that, some may forget
to do so in haste.
</P>
<P>
So, prefer this:
</P>

<div class="code"><PRE>
 if (foo)
 {
   bar();
 }
 else
 { 
    baz();
 } 
</PRE></div>

<A NAME="toc28"></A>
<H3>1.9.6. Book recommendations</H3>

<UL>
<LI><A HREF="http://www.awprofessional.com/title/0321334876">Effective C++</A>, Scott Meyers
<LI><A HREF="http://www.awprofessional.com/bookstore/product.asp?isbn=020163371X&amp;rl=1">More Effective C++</A>, Scott Meyers
<LI><A HREF="http://www.awprofessional.com/title/0201749629">Effective STL</A>, Scott Meyers
<LI><A HREF="http://www.awprofessional.com/title/0201634988">Design Patterns</A>, GoF
</UL>

<P>
You should also really read this article from Qt Quarterly on 
<A HREF="APIs">http://doc.trolltech.com/qq/qq13-apis.html designing Qt style</A>
</P>

<A NAME="toc29"></A>
<H1>2. GIT Access</H1>

<P>
This section describes how to get started using the QGIS GIT repository. Before you can do this, you need to first have a git client installed on your system.
</P>

<A NAME="toc30"></A>
<H2>2.1. Installation</H2>

<A NAME="toc31"></A>
<H3>2.1.1. Install git for GNU/Linux</H3>

<P>
Debian based distro users can do:
</P>

<div class="code"><PRE>
sudo apt-get install git
</PRE></div>

<A NAME="toc32"></A>
<H3>2.1.2. Install git for Windows</H3>

<P>
Windows users can obtain <A HREF="http://code.google.com/p/msysgit/">msys git</A>.
</P>

<A NAME="toc33"></A>
<H3>2.1.3. Install git for OSX</H3>

<P>
The <A HREF="http://git-scm.com/">git</A> project has a downloadable build of git.
Make sure to get the package matching your processor (x86_64 most likely, only the first Intel Macs need the i386 package).
</P>
<P>
Once downloaded open the disk image and run the installer.
</P>
<P>
<U>PPC/source note</U>
</P>
<P>
The git site does not offer PPC builds.  If you need a PPC build, or you just want
a little more control over the installation, you need to compile it yourself.
</P>
<P>
Download the source from <A HREF="http://git-scm.com/">http://git-scm.com/</A>.  Unzip it, and in a Terminal cd to the source folder, then:
</P>

<div class="code"><PRE>
make prefix=/usr/local
sudo make prefix=/usr/local install
</PRE></div>

<P>
If you don't need any of the extras, Perl, Python or TclTk (GUI), you can disable them before running make with:
</P>

<div class="code"><PRE>
export NO_PERL=
export NO_TCLTK=
export NO_PYTHON=
</PRE></div>

<A NAME="toc34"></A>
<H2>2.2. Accessing the Repository</H2>

<P>
To clone QGIS master:
</P>

<div class="code"><PRE>
git://github.com/qgis/Quantum-GIS.git
</PRE></div>

<A NAME="toc35"></A>
<H2>2.3. Check out a branch</H2>

<P>
To check out a branch, for example the release 1.7.0 branch do:
</P>

<div class="code"><PRE>
  cd QGIS
  git fetch
  git branch --track origin release-1_7_0
  git checkout release-1_7_0
  
</PRE></div>

<P>
To check out the master branch:
</P>

<div class="code"><PRE>
  cd QGIS
  git checkout master
</PRE></div>

<P>
/!\ <B>Note:</B> In QGIS we keep our most stable code in the current release branch.
Master contains code for the so called 'unstable' release series. Periodically
we will branch a release off master, and then continue stabilisation and selective
incorporation of new features into master.
</P>
<P>
See the INSTALL file in the source tree for specific instructions on building
development versions. 
</P>

<A NAME="toc36"></A>
<H2>2.4. QGIS documentation sources</H2>

<P>
If you're interested in checking out QGIS documentation sources:
</P>

<div class="code"><PRE>
  svn co https://svn.osgeo.org/qgis/docs/trunk qgis_docs
</PRE></div>

<P>
/!\ <B>Note:</B> This url will change to a git URL in the near future.
</P>
<P>
You can also take a look at DocumentationWritersCorner for more information.
</P>

<A NAME="toc37"></A>
<H2>2.5. GIT Documentation</H2>

<P>
See the following sites for information on becoming a GIT master.
</P>
<P>
<A HREF="http://gitref.org">http://gitref.org</A>
<A HREF="http://progit.org">http://progit.org</A>
<A HREF="http://gitready.com">http://gitready.com</A>
</P>

<A NAME="toc38"></A>
<H2>2.6. Development in branches</H2>

<A NAME="toc39"></A>
<H3>2.6.1. Purpose</H3>

<P>
The complexity of the QGIS source code has increased considerably during the
last years. Therefore it is hard to anticipate the side effects that the
addition of a feature will have. In the past, the QGIS project had very long
release cycles because it was a lot of work to reetablish the stability of the
software system after new features were added. To overcome these problems, QGIS
switched to a development model where new features are coded in GIT branches
first and merged to master (the main branch) when they are finished and stable.
This section describes the procedure for branching and merging in the QGIS
project.
</P>

<A NAME="toc40"></A>
<H3>2.6.2. Procedure</H3>

<UL>
<LI><B>Initial announcement on mailing list:</B>
Before starting, make an announcement on the developer mailing list to see if
another developer is already working on the same feature. Also contact the
technical advisor of the project steering committee (PSC). If the new feature
requires any changes to the QGIS architecture, a request for comment (RFC) is
needed. 
<P></P>
<B>Create a branch:</B> 
Create a new GIT branch for the development of the new feature. 
<P></P>
<div class="code"><PRE>
git branch newfeature
git checkout newfeature
</PRE></div>

<P></P>
Now you can start developing. If you plan to do extensive on that branch, would
like to share the work with other developers, and have write access to the
upstream repo, you can push your repo up to the QGIS official repo by doing:
<P></P>
<div class="code"><PRE>
git push origin newfeature
</PRE></div>

<P></P>
<B>Note:</B> if the branch already exists your changes will be pushed into it.
<P></P>
<B>Merge from master regularly:</B>
It is recommended to merge the changes in master to the branch on a regular
basis. This makes it easier to merge the branch back to master later.
<P></P>
<div class="code"><PRE>
git merge master
</PRE></div>

<P></P>
<B>Documentation on wiki:</B> 
It is also recommended to document the intended changes and the current status
of the work on a wiki page.
<P></P>
<B>Testing before merging back to master:</B> 
When you are finished with the new feature and happy with the stability, make
an announcement on the developer list.  Before merging back, the changes will
be tested by developers and users. Binary packages (especially for OsX and
Windows) will be generated to also involve non-developers. In trac, a new
Component will be opened to file tickets against.  Once there are no remaining
issues left, the technical advisor of the PSC merges the changes into master.
</UL>

<A NAME="toc41"></A>
<H2>2.7. Submitting Patches</H2>

<P>
There are a few guidelines that will help you to get your patches into QGIS
easily, and help us deal with the patches that are sent to use easily.
</P>

<A NAME="toc42"></A>
<H3>2.7.1. Patch file naming</H3>

<P>
If the patch is a fix for a specific bug, please name the file with the bug
number in it e.g.  <B>bug777fix.patch</B>, and attach it to the original bug report
in trac (<A HREF="http://hub.qgis.org/projects/quantum-gis">http://hub.qgis.org/projects/quantum-gis</A>).
</P>
<P>
If the bug is an enhancement or new feature, its usually a good idea to create
a ticket in trac (<A HREF="http://hub.qgis.org/projects/quantum-gis">http://hub.qgis.org/projects/quantum-gis</A>) first and then attach you 
</P>

<A NAME="toc43"></A>
<H3>2.7.2. Create your patch in the top level QGIS source dir</H3>

<P>
This makes it easier for us to apply the patches since we don't need to
navigate to a specific place in the source tree to apply the patch. Also when I
receive patches I usually evaluate them using merge, and having the patch
from the top level dir makes this much easier. Below is an example of how you
can include multiple changed files into your patch from the top level
directory:
</P>

<div class="code"><PRE>
cd QGIS
git checkout master
git pull origin master
git checkout newfeature
git format-patch master --stdout &gt; bug777fix.patch
</PRE></div>

<P>
This will make sure your master branch is in sync with the upstream repository,
and then generate a patch which contains the delta between your feature branch
and what is in the master branch.
</P>

<A NAME="toc44"></A>
<H3>2.7.3. Getting your patch noticed</H3>

<P>
QGIS developers are busy folk. We do scan the incoming patches on bug reports
but sometimes we miss things.  Don't be offended or alarmed. Try to identify a
developer to help you - using the <A HREF="http://www.qgis.org/wiki/Project_Organigram">Project Organigram</A> and contact them
asking them if they can look at your patch. If you don't get any response, you
can escalate your query to one of the Project Steering Committee members
(contact details also available on the Project Organigram).
</P>

<A NAME="toc45"></A>
<H3>2.7.4. Due Diligence</H3>

<P>
QGIS is licensed under the GPL. You should make every effort to ensure you only
submit patches which are unencumbered by conflicting intellectual property
rights. Also do not submit code that you are not happy to have made available
under the GPL.
</P>

<A NAME="toc46"></A>
<H2>2.8. Obtaining GIT Write Access</H2>

<P>
Write access to QGIS source tree is by invitation. Typically when a person
submits several (there is no fixed number here) substantial patches that
demonstrate basic competence and understanding of C++ and QGIS coding
conventions, one of the PSC members or other existing developers can nominate
that person to the PSC for granting of write access. The nominator should give
a basic promotional paragraph of why they think that person should gain write
access. In some cases we will grant write access to non C++ developers e.g. for
translators and documentors.  In these cases, the person should still have
demonstrated ability to submit patches and should ideally have submitted several
substantial patches that demonstrate their understanding of modifying the code
base without breaking things, etc.
</P>
<P>
<B>Note:</B> Since moving to GIT, we are less likely to grant write access to new
developers since it is trivial to share code within github by forking QGIS and
then issuing pull requests.
</P>
<P>
Always check that everything compiles before making any commits / pull
requests.  Try to be aware of possible breakages your commits may cause for
people building on other platforms and with older / newer versions of
libraries.
</P>
<P>
When making a commit, your editor (as defined in $EDITOR environment variable)
will appear and you should make a comment at the top of the file (above the
area that says 'don't change this'. Put a descriptive comment and rather do
several small commits if the changes across a number of files are unrelated.
Conversely we prefer you to group related changes into a single commit.
</P>

<A NAME="toc47"></A>
<H1>3. Unit Testing</H1>

<P>
As of November 2007 we require all new features going into master to be
accompanied with a unit test. Initially we have limited this requirement to
<B>qgis_core</B>, and we will extend this requirement to other parts of the code base
once people are familiar with the procedures for unit testing explained in the
sections that follow.
</P>

<A NAME="toc48"></A>
<H2>3.1. The QGIS testing framework  - an overview</H2>

<P>
Unit testing is carried out using a combination of QTestLib (the Qt testing
library) and CTest (a framework for compiling and running tests as part of the
CMake build process).  Lets take an overview of the process before I delve into
the details:
</P>

<UL>
<LI><B>There is some code you want to test</B>, e.g. a class or function. Extreme
   programming advocates suggest that the code should not even be written yet 
   when you start building your tests, and then as you implement your code you can
   immediately validate each new functional part you add with your test. In
   practive you will probably need to write tests for pre-existing code in QGIS
   since we are starting with a testing framework well after much application
   logic has already been implemented.
<P></P>
<LI><B>You create a unit test.</B> This happens under &lt;QGIS Source Dir&gt;/tests/src/core 
   in the case of the core lib. The test is basically a client that creates an
   instance of a class and calls some methods on that class. It will check the
   return from each method to make sure it matches the expected value. If any
   one of the calls fails, the unit will fail.
<P></P>
<LI><B>You include QtTestLib macros in your test class.</B> This macro is processed by 
   the Qt meta object compiler (moc) and expands your test class into a
   runnable application. 
<P></P>
<LI><B>You add a section to the CMakeLists.txt</B> in your tests directory that will
   build your test.
<P></P>
<LI><B>You ensure you have ENABLE_TESTING enabled in ccmake / cmakesetup.</B> This 
   will ensure your tests actually get compiled when you type make.
<P></P>
<LI><B>You optionally add test data to &lt;QGIS Source Dir&gt;/tests/testdata</B> if your 
   test is data driven (e.g. needs to load a shapefile). These test data should
   be as small as possible and wherever possible you should use the existing
   datasets already there. Your tests should never modify this data in situ,
   but rather may a temporary copy somewhere if needed.
<P></P>
<LI><B>You compile your sources and install.</B> Do this using normal make &amp;&amp; (sudo) 
   make install procedure.
<P></P>
<LI><B>You run your tests.</B> This is normally done simply by doing <B>make test</B> 
 after the make install step, though I will explain other aproaches that offer
 more fine grained control over running tests.
<P></P>
</UL>

<P>
Right with that overview in mind, I will delve into a bit of detail. I've
already done much of the configuration for you in CMake and other places in the
source tree so all you need to do are the easy bits - writing unit tests!
</P>

<A NAME="toc49"></A>
<H2>3.2. Creating a unit test</H2>

<P>
Creating a unit test is easy - typically you will do this by just creating a
single .cpp file (not .h file is used) and implement all your test methods as
public methods that return void. I'll use a simple test class for
QgsRasterLayer throughout the section that follows to illustrate. By convention
we will name our test with the same name as the class they are testing but
prefixed with 'Test'.  So our test implementation goes in a file called
testqgsrasterlayer.cpp and the class itself will be TestQgsRasterLayer. First
we add our standard copyright banner:
</P>

<div class="code"><PRE>
/***************************************************************************
     testqgsvectorfilewriter.cpp
     --------------------------------------
    Date                 : Frida  Nov 23  2007
    Copyright            : (C) 2007 by Tim Sutton
    Email                : tim@linfiniti.com
 ***************************************************************************
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.                                   *
 *                                                                         *
 ***************************************************************************/
</PRE></div>

<P>
Next we use start our includes needed for the tests we plan to run. There is 
one special include all tests should have:
</P>

<div class="code"><PRE>
#include &lt;QtTest&gt;
</PRE></div>

<P>
<B>Note</B> that we use the new style Qt4 includes - i.e. QtTest is included not
qttest.h
</P>
<P>
Beyond that you just continue implementing your class as per normal, pulling 
in whatever headers you may need:
</P>

<div class="code"><PRE>
//Qt includes...
#include &lt;QObject&gt;
#include &lt;QString&gt;
#include &lt;QObject&gt;
#include &lt;QApplication&gt;
#include &lt;QFileInfo&gt;
#include &lt;QDir&gt;

//qgis includes...
#include &lt;qgsrasterlayer.h&gt; 
#include &lt;qgsrasterbandstats.h&gt; 
#include &lt;qgsapplication.h&gt;
</PRE></div>

<P>
Since we are combining both class declaration and implementation in a single
file the class declaration comes next. We start with our doxygen documentation.
Every test case should be properly documented. We use the doxygen <B>ingroup</B>
directive so that all the UnitTests appear as a module in the generated Doxygen
documentation. After that comes a short description of the unit test:
</P>

<div class="code"><PRE>
/** \ingroup UnitTests
 * This is a unit test for the QgsRasterLayer class.
 */
</PRE></div>

<P>
The class <B>must</B> inherit from QObject and include the Q_OBJECT macro.
</P>

<div class="code"><PRE>
class TestQgsRasterLayer: public QObject
{
  Q_OBJECT;
</PRE></div>

<P>
All our test methods are implemented as <B>private slots</B>. The QtTest framework
will sequentially call each private slot method in the test class. There are
four 'special' methods which if implemented will be called at the start of the
unit test (<B>initTestCase</B>), at the end of the unit test
(<B>cleanupTestCase</B>).  Before each test method is called, the <B>init()</B>
method will be called and after each test method is called the <B>cleanup()</B>
method is called. These methods are handy in that they allow you to allocate
and cleanup resources prior to running each test, and the test unit as a whole.
</P>

<div class="code"><PRE>
private slots:
  // will be called before the first testfunction is executed.
  void initTestCase();
  // will be called after the last testfunction was executed.
  void cleanupTestCase(){};
  // will be called before each testfunction is executed.
  void init(){};
  // will be called after every testfunction.
  void cleanup();
</PRE></div>

<P>
Then come your test methods, all of which should take <B>no parameters</B> and
should <B>return void</B>. The methods will be called in order of declaration.  I
am implementing two methods here which illustrates to types of testing. In the
first case I want to generally test the various parts of the class are working,
I can use a <B>functional testing</B> approach. Once again, extreme programmers
would advocate writing these tests <B>before</B> implementing the class. Then as
you work your way through your class implementation you iteratively run your
unit tests. More and more test functions should complete sucessfully as your
class implementation work progresses, and when the whole unit test passes, your
new class is done and is now complete with a repeatable way to validate it.
</P>
<P>
Typically your unit tests would only cover the <B>public</B> API of your class,
and normally you do not need to write tests for accessors and mutators.  If it
should happen that an acccessor or mutator is not working as expected you would
normally implement a <B>regression</B> test to check for this (see lower down).
</P>

<div class="code"><PRE>
  //
  // Functional Testing
  //
  
  /** Check if a raster is valid. */
  void isValid();

  // more functional tests here ...
</PRE></div>

<P>
Next we implement our <B>regression tests</B>. Regression tests should be
implemented to replicate the conditions of a particular bug. For example I
recently received a report by email that the cell count by rasters was off by
1, throwing off all the statistics for the raster bands. I opened a bug (ticket
#832) and then created a regression test that replicated the bug using a small
test dataset (a 10x10 raster). Then I ran the test and ran it, verifying that
it did indeed fail (the cell count was 99 instead of 100). Then I went to fix
the bug and reran the unit test and the regression test passed. I committed the
regression test along with the bug fix. Now if anybody breakes this in the
source code again in the future, we can immediatly identify that the code has
regressed. Better yet before committing any changes in the future, running our
tests will ensure our changes don't have unexpected side effects - like breaking
existing functionality.
</P>
<P>
There is one more benifit to regression tests - they can save you time.  If you
ever fixed a bug that involved making changes to the source, and then running
the application and performing a series of convoluted steps to replicate the
issue, it will be immediately apparent that simply implementing your regression
test <B>before</B> fixing the bug will let you automate the testing for bug
resolution in an efficient manner.
</P>
<P>
To implement your regression test, you should follow the naming convention of
regression&lt;TicketID&gt; for your test functions. If no redmine ticket exists for the
regression, you should create one first.  Using this approach allows the person
running a failed regression test easily go and find out more information.
</P>

<div class="code"><PRE>
  //
  // Regression Testing
  //
  
  /** This is our second test case...to check if a raster
   reports its dimensions properly. It is a regression test 
   for ticket #832 which was fixed with change r7650. 
   */
  void regression832(); 
  
  // more regression tests go here ...
</PRE></div>

<P>
Finally in our test class declaration you can declare privately any data
members and helper methods your unit test may need. In our case I will declare
a QgsRasterLayer * which can be used by any of our test methods. The raster
layer will be created in the initTestCase() function which is run before any
other tests, and then destroyed using cleanupTestCase() which is run after all
tests. By declaring helper methods (which may be called by various test
functions) privately, you can ensure that they wont be automatically run by the
QTest executeable that is created when we compile our test.
</P>

<div class="code"><PRE>
  private:
    // Here we have any data structures that may need to 
    // be used in many test cases.
    QgsRasterLayer * mpLayer;
};

</PRE></div>

<P>
That ends our class declaration. The implementation is simply inlined in the
same file lower down. First our init and cleanup functions:
</P>

<div class="code"><PRE>
void TestQgsRasterLayer::initTestCase()
{
  // init QGIS's paths - true means that all path will be inited from prefix
  QString qgisPath = QCoreApplication::applicationDirPath ();
  QgsApplication::setPrefixPath(qgisPath, TRUE);
#ifdef Q_OS_LINUX
  QgsApplication::setPkgDataPath(qgisPath + "/../share/qgis");
#endif
  //create some objects that will be used in all tests...

  std::cout &lt;&lt; "Prefix  PATH: " &lt;&lt; QgsApplication::prefixPath().toLocal8Bit().data() &lt;&lt; std::endl;
  std::cout &lt;&lt; "Plugin  PATH: " &lt;&lt; QgsApplication::pluginPath().toLocal8Bit().data() &lt;&lt; std::endl;
  std::cout &lt;&lt; "PkgData PATH: " &lt;&lt; QgsApplication::pkgDataPath().toLocal8Bit().data() &lt;&lt; std::endl;
  std::cout &lt;&lt; "User DB PATH: " &lt;&lt; QgsApplication::qgisUserDbFilePath().toLocal8Bit().data() &lt;&lt; std::endl;

  //create a raster layer that will be used in all tests...
  QString myFileName (TEST_DATA_DIR); //defined in CmakeLists.txt
  myFileName = myFileName + QDir::separator() + "tenbytenraster.asc";
  QFileInfo myRasterFileInfo ( myFileName );
  mpLayer = new QgsRasterLayer ( myRasterFileInfo.filePath(),
            myRasterFileInfo.completeBaseName() );
}

void TestQgsRasterLayer::cleanupTestCase()
{
  delete mpLayer;
}

</PRE></div>

<P>
The above init function illustrates a couple of interesting things.
</P>
<P>
 1. I needed to manually set the QGIS application data path so that
   resources such as srs.db can be found properly.
 2. Secondly, this is a data driven test so we needed to provide a 
   way to generically locate the 'tenbytenraster.asc file. This was 
   achieved by using the compiler define <B>TEST_DATA_PATH</B>. The 
   define is created in the CMakeLists.txt configuration file under 
   &lt;QGIS Source Root&gt;/tests/CMakeLists.txt and is available to all 
   QGIS unit tests. If you need test data for your test, commit it 
   under &lt;QGIS Source Root&gt;/tests/testdata. You should only commit 
   very small datasets here. If your test needs to modify the test 
   data, it should make a copy of if first.
</P>
<P>
Qt also provides some other interesting mechanisms for data driven 
testing, so if you are interested to know more on the topic, consult 
the Qt documentation.
</P>
<P>
Next lets look at our functional test. The isValid() test simply checks the
raster layer was correctly loaded in the initTestCase.  QVERIFY is a Qt macro
that you can use to evaluate a test condition.  There are a few other use
macros Qt provide for use in your tests including:
</P>

<div class="code"><PRE>
QCOMPARE ( actual, expected )
QEXPECT_FAIL ( dataIndex, comment, mode )
QFAIL ( message )
QFETCH ( type, name )
QSKIP ( description, mode )
QTEST ( actual, testElement )
QTEST_APPLESS_MAIN ( TestClass )
QTEST_MAIN ( TestClass )
QTEST_NOOP_MAIN ()
QVERIFY2 ( condition, message )
QVERIFY ( condition )
QWARN ( message ) 
</PRE></div>

<P>
Some of these macros are useful only when using the Qt framework for data
driven testing (see the Qt docs for more detail).
</P>

<div class="code"><PRE>
void TestQgsRasterLayer::isValid()
{
  QVERIFY ( mpLayer-&gt;isValid() );
}
</PRE></div>

<P>
Normally your functional tests would cover all the range of functionality of
your classes public API where feasible. With our functional tests out the way,
we can look at our regression test example.
</P>
<P>
Since the issue in bug #832 is a misreported cell count, writing our test if
simply a matter of using QVERIFY to check that the cell count meets the
expected value:
</P>

<div class="code"><PRE>
void TestQgsRasterLayer::regression832()
{
   QVERIFY ( mpLayer-&gt;getRasterXDim() == 10 );
   QVERIFY ( mpLayer-&gt;getRasterYDim() == 10 );
   // regression check for ticket #832
   // note getRasterBandStats call is base 1
   QVERIFY ( mpLayer-&gt;getRasterBandStats(1).elementCountInt == 100 );
}
</PRE></div>

<P>
With all the unit test functions implemented, there one final thing we need to
add to our test class:
</P>

<div class="code"><PRE>
QTEST_MAIN(TestQgsRasterLayer)
#include "moc_testqgsrasterlayer.cxx"
</PRE></div>

<P>
The purpose of these two lines is to signal to Qt's moc that his is a QtTest
(it will generate a main method that in turn calls each test funtion.  The last
line is the include for the MOC generated sources. You should replace
'testqgsrasterlayer' with the name of your class in lower case.
</P>

<A NAME="toc50"></A>
<H2>3.3. Adding your unit test to CMakeLists.txt</H2>

<P>
Adding your unit test to the build system is simply a matter of editing the
CMakeLists.txt in the test directory, cloning one of the existing test blocks,
and then replacing your test class name into it.  For example:
</P>

<div class="code"><PRE>
# QgsRasterLayer test
ADD_QGIS_TEST(rasterlayertest testqgsrasterlayer.cpp)
</PRE></div>

<A NAME="toc51"></A>
<H2>3.4. The ADD_QGIS_TEST macro explained</H2>

<P>
I'll run through these lines briefly to explain what they do, but if you are
not interested, just do the step explained in the above section and section.
</P>

<div class="code"><PRE>
MACRO (ADD_QGIS_TEST testname testsrc)
  SET(qgis_${testname}_SRCS ${testsrc} ${util_SRCS})
  SET(qgis_${testname}_MOC_CPPS ${testsrc})
  QT4_WRAP_CPP(qgis_${testname}_MOC_SRCS ${qgis_${testname}_MOC_CPPS})
  ADD_CUSTOM_TARGET(qgis_${testname}moc ALL DEPENDS ${qgis_${testname}_MOC_SRCS})
  ADD_EXECUTABLE(qgis_${testname} ${qgis_${testname}_SRCS})
  ADD_DEPENDENCIES(qgis_${testname} qgis_${testname}moc)
  TARGET_LINK_LIBRARIES(qgis_${testname} ${QT_LIBRARIES} qgis_core)
  SET_TARGET_PROPERTIES(qgis_${testname}
    PROPERTIES
    # skip the full RPATH for the build tree
    SKIP_BUILD_RPATH  TRUE
    # when building, use the install RPATH already
    # (so it doesn't need to relink when installing)
    BUILD_WITH_INSTALL_RPATH TRUE
    # the RPATH to be used when installing
    INSTALL_RPATH ${QGIS_LIB_DIR}
    # add the automatically determined parts of the RPATH
    # which point to directories outside the build tree to the install RPATH
    INSTALL_RPATH_USE_LINK_PATH true)
  IF (APPLE)
    # For Mac OS X, the executable must be at the root of the bundle's executable folder
    INSTALL(TARGETS qgis_${testname} RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX})
    ADD_TEST(qgis_${testname} ${CMAKE_INSTALL_PREFIX}/qgis_${testname})
  ELSE (APPLE)
    INSTALL(TARGETS qgis_${testname} RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
    ADD_TEST(qgis_${testname} ${CMAKE_INSTALL_PREFIX}/bin/qgis_${testname})
  ENDIF (APPLE)
ENDMACRO (ADD_QGIS_TEST)
</PRE></div>

<P>
Lets look a little more in detail at the individual lines. First we define the
list of sources for our test. Since we have only one source file (following the
methodology I described above where class declaration and definition are in the
same file) its a simple statement:
</P>

<div class="code"><PRE>
SET(qgis_${testname}_SRCS ${testsrc} ${util_SRCS})
</PRE></div>

<P>
Since our test class needs to be run through the Qt meta object compiler (moc)
we need to provide a couple of lines to make that happen too:
</P>

<div class="code"><PRE>
SET(qgis_${testname}_MOC_CPPS ${testsrc})
QT4_WRAP_CPP(qgis_${testname}_MOC_SRCS ${qgis_${testname}_MOC_CPPS})
ADD_CUSTOM_TARGET(qgis_${testname}moc ALL DEPENDS ${qgis_${testname}_MOC_SRCS})
</PRE></div>

<P>
Next we tell cmake that it must make an executeable from the test class.
Remember in the previous section on the last line of the class implementation I
included the moc outputs directly into our test class, so that will give it
(among other things) a main method so the class can be compiled as an
executeable:
</P>

<div class="code"><PRE>
ADD_EXECUTABLE(qgis_${testname} ${qgis_${testname}_SRCS})
ADD_DEPENDENCIES(qgis_${testname} qgis_${testname}moc)
</PRE></div>

<P>
Next we need to specify any library dependencies. At the moment classes have
been implemented with a catch-all QT_LIBRARIES dependency, but I will be
working to replace that with the specific Qt libraries that each class needs
only. Of course you also need to link to the relevant qgis libraries as
required by your unit test.
</P>

<div class="code"><PRE>
TARGET_LINK_LIBRARIES(qgis_${testname} ${QT_LIBRARIES} qgis_core)
</PRE></div>

<P>
Next I tell cmake to install the tests to the same place as the qgis binaries
itself. This is something I plan to remove in the future so that the tests can
run directly from inside the source tree.
</P>

<div class="code"><PRE>
SET_TARGET_PROPERTIES(qgis_${testname}
  PROPERTIES
  # skip the full RPATH for the build tree
  SKIP_BUILD_RPATH  TRUE
  # when building, use the install RPATH already
  # (so it doesn't need to relink when installing)
  BUILD_WITH_INSTALL_RPATH TRUE
  # the RPATH to be used when installing
  INSTALL_RPATH ${QGIS_LIB_DIR}
  # add the automatically determined parts of the RPATH
  # which point to directories outside the build tree to the install RPATH
  INSTALL_RPATH_USE_LINK_PATH true)
IF (APPLE)
  # For Mac OS X, the executable must be at the root of the bundle's executable folder
  INSTALL(TARGETS qgis_${testname} RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX})
  ADD_TEST(qgis_${testname} ${CMAKE_INSTALL_PREFIX}/qgis_${testname})
ELSE (APPLE)
  INSTALL(TARGETS qgis_${testname} RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
  ADD_TEST(qgis_${testname} ${CMAKE_INSTALL_PREFIX}/bin/qgis_${testname})
ENDIF (APPLE)
</PRE></div>

<P>
Finally the above uses ADD_TEST to register the test with cmake / ctest . Here
is where the best magic happens - we register the class with ctest. If you
recall in the overview I gave in the beginning of this section we are using
both QtTest and CTest together. To recap, <B>QtTest</B> adds a main method to your
test unit and handles calling your test methods within the class. It also
provides some macros like QVERIFY that you can use as to test for failure of
the tests using conditions. The output from a QtTest unit test is an
executeable which you can run from the command line.  However when you have a
suite of tests and you want to run each executeable in turn, and better yet
integrate running tests into the build process, the <B>CTest</B> is what we use. 
</P>

<A NAME="toc52"></A>
<H2>3.5. Building your unit test</H2>

<P>
To build the unit test you need only to make sure that ENABLE_TESTS=true in the
cmake configuration. There are two ways to do this:
</P>
<P>
 1. Run ccmake .. (cmakesetup .. under windows) and interactively set 
 the ENABLE_TESTS flag to ON.
 1. Add a command line flag to cmake e.g. cmake -DENABLE_TESTS=true ..
</P>
<P>
Other than that, just build QGIS as per normal and the tests should build too.
</P>

<A NAME="toc53"></A>
<H2>3.6. Run your tests</H2>

<P>
The simplest way to run the tests is as part of your normal build process:
</P>

<div class="code"><PRE>
make &amp;&amp; make install &amp;&amp; make test
</PRE></div>

<P>
The make test command will invoke CTest which will run each test that was
registered using the ADD_TEST CMake directive described above. Typical output
from make test will look like this:
</P>

<div class="code"><PRE>
Running tests...
Start processing tests
Test project /Users/tim/dev/cpp/qgis/build
1/  3 Testing qgis_applicationtest          ***Exception: Other
2/  3 Testing qgis_filewritertest           *** Passed
3/  3 Testing qgis_rasterlayertest          *** Passed

0% tests passed, 3 tests failed out of 3

  The following tests FAILED:
  1 - qgis_applicationtest (OTHER_FAULT)
  Errors while running CTest
  make: *** [test] Error 8
</PRE></div>

<P>
If a test fails, you can use the ctest command to examine more closely why it
failed. User the -R option to specify a regex for which tests you want to run
and -V to get verbose output:
</P>

<div class="code"><PRE>
[build] ctest -R appl -V
Start processing tests
Test project /Users/tim/dev/cpp/qgis/build
Constructing a list of tests
Done constructing a list of tests
Changing directory into /Users/tim/dev/cpp/qgis/build/tests/src/core
1/  3 Testing qgis_applicationtest          
Test command: /Users/tim/dev/cpp/qgis/build/tests/src/core/qgis_applicationtest
********* Start testing of TestQgsApplication *********
  Config: Using QTest library 4.3.0, Qt 4.3.0
PASS   : TestQgsApplication::initTestCase()
  Prefix  PATH: /Users/tim/dev/cpp/qgis/build/tests/src/core/../
  Plugin  PATH: /Users/tim/dev/cpp/qgis/build/tests/src/core/..//lib/qgis
  PkgData PATH: /Users/tim/dev/cpp/qgis/build/tests/src/core/..//share/qgis
  User DB PATH: /Users/tim/.qgis/qgis.db
PASS   : TestQgsApplication::getPaths()
  Prefix  PATH: /Users/tim/dev/cpp/qgis/build/tests/src/core/../
  Plugin  PATH: /Users/tim/dev/cpp/qgis/build/tests/src/core/..//lib/qgis
  PkgData PATH: /Users/tim/dev/cpp/qgis/build/tests/src/core/..//share/qgis
  User DB PATH: /Users/tim/.qgis/qgis.db
  QDEBUG : TestQgsApplication::checkTheme() Checking if a theme icon exists:
  QDEBUG : TestQgsApplication::checkTheme() 
  /Users/tim/dev/cpp/qgis/build/tests/src/core/..//share/qgis/themes/default//mIconProjectionDisabled.png
  FAIL!  : TestQgsApplication::checkTheme() '!myPixmap.isNull()' returned FALSE. ()
  Loc: [/Users/tim/dev/cpp/qgis/tests/src/core/testqgsapplication.cpp(59)]
PASS   : TestQgsApplication::cleanupTestCase()
  Totals: 3 passed, 1 failed, 0 skipped
  ********* Finished testing of TestQgsApplication *********
  -- Process completed
  ***Failed

  0% tests passed, 1 tests failed out of 1

  The following tests FAILED:
1 - qgis_applicationtest (Failed)
  Errors while running CTest

</PRE></div>

<P>
Well that concludes this section on writing unit tests in QGIS. We hope you
will get into the habit of writing test to test new functionality and to check
for regressions. Some aspects of the test system (in particular the
CMakeLists.txt parts) are still being worked on so that the testing framework
works in a truly platform way. I will update this document as things
progress.
</P>

<A NAME="toc54"></A>
<H1>4. Getting up and running with QtCreator and QGIS</H1>

<P>
QtCreator is a newish IDE from the makers of the Qt library. With QtCreator you
can build any C++ project, but it's really optimised for people working on
Qt(4) based applications (including mobile apps). Everything I describe below
assumes you are running Ubuntu 11.04 'Natty'.
</P>

<A NAME="toc55"></A>
<H2>4.1. Installing QtCreator</H2>

<P>
This part is easy:
</P>

<div class="code"><PRE>
sudo apt-get install qtcreator qtcreator-doc
</PRE></div>

<P>
After installing you should find it in your gnome menu.
</P>

<A NAME="toc56"></A>
<H2>4.2. Setting up your project</H2>

<P>
I'm assuming you have already got a local QGIS clone containing the
source code, and have installed all needed build dependencies etc. There are
detailed in instructions on doing that here:
</P>
<P>
<A HREF="http://github.com/qgis/Quantum-GIS/blob/master/CODING">http://github.com/qgis/Quantum-GIS/blob/master/CODING</A>
</P>
<P>
On my system I have checked out the code into $HOME/dev/cpp/QGIS and the
rest of the article is written assuming that, you should update these paths as
appropriate for your local system.
</P>
<P>
On launching QtCreator do:
</P>

<div class="code"><PRE>
File-&gt;Open File or Project
</PRE></div>

<P>
Then use the resulting file selection dialog to browse to and open this file:
</P>

<div class="code"><PRE>
$HOME/dev/cpp/QGIS/CMakeLists.txt
</PRE></div>

<P>
<IMG ALIGN="middle" SRC="images/image01.jpeg" BORDER="0" ALT="">
</P>
<P>
Next you will be prompted for a build location. I create a specific build dir
for QtCreator to work in under:
</P>

<div class="code"><PRE>
$HOME/dev/cpp/QGIS/build-master-qtcreator
</PRE></div>

<P>
Its probably a good idea to create separate build directories for different
branches if you can afford the disk space.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image02.jpeg" BORDER="0" ALT="">
</P>
<P>
Next you will be asked if you have any CMake build options to pass to CMake. We
will tell CMake that we want a debug build by adding this option:
</P>

<div class="code"><PRE>
-DCMAKE_BUILD_TYPE=Debug
</PRE></div>

<P>
<IMG ALIGN="middle" SRC="images/image03.jpeg" BORDER="0" ALT="">
</P>
<P>
Thats the basics of it. When you complete the Wizard, QtCreator will start
scanning the source tree for autocompletion support and do some other
housekeeping stuff in the background. We want to tweak a few things before we
start to build though.
</P>

<A NAME="toc57"></A>
<H2>4.3. Setting up your build environment</H2>

<P>
Click on the 'Projects' icon on the left of the QtCreator window.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image04.jpeg" BORDER="0" ALT="">
</P>
<P>
Select the build settings tab (normally active by default).
</P>
<P>
<IMG ALIGN="middle" SRC="images/image05.jpeg" BORDER="0" ALT="">
</P>
<P>
We now want to add a custom process step. Why? Because QGIS can currently only
run from an install directory, not its build directory, so we need to ensure
that it is installed whenever we build it.  Under 'Build Steps', click on the
'Add Build  Step' combo button and choose 'Custom Process Step'.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image06.jpeg" BORDER="0" ALT="">
</P>
<P>
Now we set the following details:
</P>

<div class="code"><PRE>
Enable custom process step [yes]
Command: make
Working directory: $HOME/dev/cpp/QGIS/build-master-qtcreator
Command arguments: install
</PRE></div>

<P>
<IMG ALIGN="middle" SRC="images/image07.jpeg" BORDER="0" ALT="">
</P>
<P>
You are almost ready to build. Just one note: QtCreator will need write
permissions on the install prefix.  By default (which I am using here) QGIS is
going to get installed to /usr/local. For my purposes on my development
machine, I just gave myself write permissions to the /usr/local directory.
</P>
<P>
To start the build, click that big hammer icon on the bottom left of the
window.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image08.jpeg" BORDER="0" ALT="">
</P>

<A NAME="toc58"></A>
<H2>4.4. Setting your run environment</H2>

<P>
As mentioned above, we cannot run QGIS from directly in the build directly, so
we need to create a custom run target to tell QtCreator to run QGIS from the
install dir (in my case /usr/local/). To do that, return to the projects
configuration screen.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image04.jpeg" BORDER="0" ALT="">
</P>
<P>
Now select the 'Run Settings' tab
</P>
<P>
<IMG ALIGN="middle" SRC="images/image09.jpeg" BORDER="0" ALT="">
</P>
<P>
We need to update the default run settings from using the 'qgis' run
configuration to using a custom one.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image10.jpeg" BORDER="0" ALT="">
</P>
<P>
Do do that, click the 'Add v' combo button next to the <B>Run</B> configuration
combo and choose 'Custom Executable' from the top of the list.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image11.jpeg" BORDER="0" ALT="">
</P>
<P>
Now in the properties area set the following details:
</P>

<div class="code"><PRE>
Executable: /usr/local/bin/qgis
Arguments :
Working directory: $HOME
Run in terminal: [no]
Debugger: C++ [yes]
          Qml [no]
</PRE></div>

<P>
Then click the 'Rename' button and give your custom executable a meaning full
name e.g. 'Installed QGIS'
</P>
<P>
<IMG ALIGN="left" SRC="images/image12.jpeg" BORDER="0" ALT="">          
</P>

<A NAME="toc59"></A>
<H2>4.5. Running and debugging</H2>

<P>
Now you are ready to run and debug QGIS. To set a break point, simply open a
source file and click in the left column.
</P>
<P>
<IMG ALIGN="middle" SRC="images/image14.jpeg" BORDER="0" ALT="">
</P>
<P>
Now launch QGIS under the debugger by clicking the icon with a bug on it in the
bottom left of the window.
</P>
<P>
<IMG ALIGN="left" SRC="images/image13.jpeg" BORDER="0" ALT="">          
</P>

<A NAME="toc60"></A>
<H1>5. HIG (Human Interface Guidelines)</H1>

<P>
In order for all graphical user interface elements to appear consistant and to
all the user to instinctively use dialogs, it is important that the following
guidelines are followed in layout and design of GUIs.
</P>

 <OL>
 <LI>Group related elements using group boxes:
   Try to identify elements that can be grouped together and then use group
   boxes with a label to identify the topic of that group.  Avoid using group
   boxes with only a single widget / item inside.
 <LI>Capitalise first letter only in labels:
   Labels (and group box labels) should be written as a phrase with leading
   capital letter, and all remaing words written with lower case first letters 
 <LI>Do not end labels for widgets or group boxes with a colon:
   Adding a colon causes visual noise and does not impart additional meaning,
   so don't use them. An exception to this rule is when you have two labels next
   to each other e.g.: Label1 <A HREF="Path:">Plugin</A> Label2 [/path/to/plugins]
 <LI>Keep harmful actions away from harmless ones:
   If you have actions for 'delete', 'remove' etc, try to impose adequate space
   between the harmful action and innocuous actions so that the users is less
   likely to inadvertantly click on the harmful action.
 <LI>Always use a QButtonBox for 'OK', 'Cancel' etc buttons:
   Using a button box will ensure that the order of 'OK' and 'Cancel' etc,
   buttons is consistent with the operating system / locale / desktop
   environment that the user is using.
 <LI>Tabs should not be nested. If you use tabs, follow the style of the
   tabs used in QgsVectorLayerProperties / QgsProjectProperties etc.
   i.e. tabs at top with icons at 22x22.
 <LI>Widget stacks should be avoided if at all possible. They cause problems with 
   layouts and inexplicable (to the user) resizing of dialogs to accommodate 
   widgets that are not visible.
 <LI>Try to avoid technical terms and rather use a laymans equivalent e.g. use
   the word 'Transparency' rather than 'Alpha Channel' (contrived example),
   'Text' instead of 'String' and so on.
 <LI>Use consistent iconography. If you need an icon or icon elements, please
   contact Robert Szczepanek on the mailing list for assistance.
 <LI>Place long lists of widgets into scroll boxes. No dialog should exceed 580
   pixels in height and 1000 pixels in width.
 <LI>Separate advanced options from basic ones. Novice users should be able to
   quickly access the items needed for basic activities without needing to
   concern themselves with complexity of advanced features. Advanced features
   should either be located below a dividing line, or placed onto a separate tab.
 <LI>Don't add options for the sake of having lots of options. Strive to keep the
   user interface minimalistic and use sensible defaults.
 <LI>If clicking a button will spawn a new dialog, an ellipsis (...) should be
   suffixed to the button text.
 </OL>

<A NAME="toc61"></A>
<H1>6. Authors</H1>

<UL>
<LI>Tim Sutton (author and editor)
<LI>Gary Sherman
<LI>Marco Hugentobler
</UL>

<P>
Original pages from wiki to deprecate:
</P>

<UL>
<LI><A HREF="http://wiki.qgis.org/qgiswiki/CodingGuidelines">http://wiki.qgis.org/qgiswiki/CodingGuidelines</A> (./)
<LI><A HREF="http://wiki.qgis.org/qgiswiki/CodingStandards">http://wiki.qgis.org/qgiswiki/CodingStandards</A> (./)
<LI><A HREF="http://wiki.qgis.org/qgiswiki/UsingSubversion">http://wiki.qgis.org/qgiswiki/UsingSubversion</A> (./)
<LI><A HREF="http://www.qgis.org/wiki/How_to_debug_QGIS_Plugins">http://www.qgis.org/wiki/How_to_debug_QGIS_Plugins</A>
<LI><A HREF="http://wiki.qgis.org/qgiswiki/DevelopmentInBranches">http://wiki.qgis.org/qgiswiki/DevelopmentInBranches</A> (./)
<LI><A HREF="http://wiki.qgis.org/qgiswiki/SubmittingPatchesAndSvnAccess">http://wiki.qgis.org/qgiswiki/SubmittingPatchesAndSvnAccess</A> (./)
<P></P>
</UL>

</DIV>
<!-- html code generated by txt2tags 2.6 (http://txt2tags.org) -->
<!-- cmdline: txt2tags -o/build/buildd/qgis-2.0.1/obj-i686-linux-gnu/doc/CODING.html -t html /build/buildd/qgis-2.0.1/doc/CODING.t2t -->
</BODY></HTML>