This section is simply a gathering of wisdom, general style guidelines and hints to creating good GTK applications. Currently this section is very short, but I hope it will get longer in future editions of this tutorial.
If you've got this far - or maybe if you've just looked at a few other bits of this tutorial - you may have been slightly surprised at the way the code has been laid out. You may have thought it a bit old-style to have all of those BEGIN's and END's etc. in big capitals. Lower-case can look so great can't it? Personally I think that the capitals help to demarkate the separate parts of the program. The same idea is behind the use of comments at the beginning and end of each function or procedure. You might think it unecessary for short functions, but being consistent is a big help towards being clear.
The way you lay out your code on the page is important for both readability and maintainability. For example, there's nothing to stop you from squashing all your lines of code together so as to make a really short file. The Pascal compiler certainly doesn't need the spaces or indentations. When you come to debug or update your program, though, you'll be glad that you did in fact indent the contents of each for-loop etc. etc.
The FPC is quite happy with C++ style comments (//) and you'll find quite a lot of them in existing Pascal code. For purists the following comment symbols should be used:
(* *) type comments can be enclosed within { } type comments. For example, if you were debugging a program and wanted to comment-out a block of code which contained some (* *) type comments. However, the opposite is not allowed in Pascal.
With all of these great-looking widgets at your disposal it's possible to create something really imaginative. Good, be imaginative - create something beautiful. There is a balance to be struck, though, between attractive and intuitive. In other words, if your app works too differently to what the average person is used to, you may just succeed in confusing your users. Make it easy for them to get the most out of your efforts.
Making things intuitive can be easier said than done. Try to put yourself in the place of the ordinary user. What will they want to try to do? More importantly how will they try to do it? Ideally, get somebody to use your application as early in its development as possible. Watch what they do, and if necessary, change things.
Some applications have the ability to present the user with a lot of information. Again, be careful. Take pity on those using your software - many of them are easily intimidated by complexity. On the other hand you may have some 'advanced' users who just can't get enough detail - maybe create a separate menu for them...