View source for Creation of a Layout Manager for dealing better with translation and to overcome mono flaws

=Introduction=
This project involves the creation of a component for the openPETRA GUI which can deal better with varying string lengths due to translations.

It is ''very desirable'' to also overcome a serious layout problem with mono's TableLayoutPanel when used with AutoSize/percentages instead of absolute values for widths/heights for Columns/Rows.


==Description of Problem #1: Varying String Lengths Cause Non-aligned Layouts==
Imagine the following situation: 

* Column #1 in GroupBox #1 is let's say 100px wide when auto-sized with German texts in the Label controls it hosts. 
* Column #1 in GroupBox #2 (which is located underneath GroupBox #1) is let's say 130px wide when auto-sized with German texts in the Label controls it hosts. 

The resulting layout doesn't look good because the Controls in Column #2 (following after the Labels in Column #1) start at different horizontal point (e.g. at 110px) in GroupBox #1 than in GroupBox #2 (e.g. at 140px). This could all be reversed if the UI language is switched from German to Spanish; there the auto-sized Column #1 could suddenly be wider in GroupBox #1 than in GroupBox #2 because the Label texts could be longer in GroupBox #1's Column #1!

At the moment we overcome the problem of 'not-lining-up-Controls-across-GroupBoxes' by hard-coding the width of the Label Columns of both TableLayoutPanels in both GroupBoxes to the same number of pixels (here 130px would work for German texts). 
''This 'solution' does not work across different languages'', though, and ''defeats the purpose of having a largely automatic layout'' because the developer needs to find the right width in pixels (here 130px) that works for all the Labels in all the GroupBoxes!


==Description of Problem #2: Layout Issues With Mono's TableLayoutPanel==
A serious layout problem exists with mono's TableLayoutPanel. This shows up when a TableLayoutPanel is used and AutoSize/Percentages instead of absolute values are used for widths/heights for Columns/Rows.

See also the Mono Bugzilla issue: https://bugzilla.novell.com/show_bug.cgi?id=531591

Our current workaround for Mono is to run <code>nant generateWinforms</code> with GUILocalisation = en, which will active files like <code>csharp\ICT\Petra\Client\lib\MFinance\gui\GL\UC_GLBatches.en.yaml</code>. In that file we can specify the width for controls, and therefore the problem goes away for Mono, since AutoSize is replaced with an absolute width value. The commit of the workaround was [http://openpetraorg.git.sourceforge.net/git/gitweb.cgi?p=openpetraorg/openpetraorg;a=commit;h=2f888f01e2f996d8968a30a72565f69ec3e60706 commit for TableLayoutPanel workaround]

to reproduce this on Windows:
 set PATH=C:\PROGRA~2\Mono-2.8\bin;%PATH%
 cd csharp\ICT\Petra\Client\_bin\Debug
 mono PetraClient.exe -C:..\..\..\..\..\..\etc\Client.config

This is how the screen should look, and it works fine in MS.net:
[[File:TableLayoutManagerCorrect.png|center|thumb|350px|This is how the screen should look, and it works fine in MS.net]]
This is how the screen looks in Mono 2.8. notice the missing filter for the batches:
[[File:TableLayoutManagerMonoBroken.png|center|thumb|350px|This is how the screen looks in Mono 2.8. notice the missing filter for the batches]]

=Desired Outcomes=
* Being able to create complex layouts for UserControls and Forms that look the same and keep their proportions, no matter what UI Language is used.
* No need for hard-coding column widths for the sake of overcoming layout problems that should be addressed automatically.
* Layouts must not break on mono.


=Outline of the Solution=
'''TODO Needs more investigation!'''

Not sure yet of the solution: 
* Either we create our own Layout Manager which we will use in replacement of .NET WinForm's TableLayoutPanel, 
* or we create a Class which would adjust the widths of certain columns of TableLayoutPanel-layed out screen parts at runtime. ''That depends on finding a fix for the mono issue as well!!!''
* Also check if there is something out on the Internet already that addresses both 'Problem #1' and 'Problem #2' (mono issue) ''and has a GPL compatible licence''.


==If we create our own Layout Manager which we will use in replacement of .NET WinForm's TableLayoutPanel==
Sun's Java SWING is a GUI framework that has solutions for overcoming the problems of varying string lengths. This should be looked at in detail, tested (in Java) and - after approving of them - a .NET layout manager with similar capabilities should be designed. 
This will address 'Problem #1', and most likely 'Problem #2' (mono issue) as well - if the solution means we can replace all TableLayoutPanels in all openPETRA UserControls and Forms.

==If we create a Class which would correct the widths of certain columns of TableLayoutPanel-layed out screen parts at runtime==
The solution that addresses 'Problem #1' could involve the creation of a Class with a static Method which would be called by every openPETRA screen.
The Method would adjust the widths of certain auto-sized columns for Labels of TableLayoutPanel-layed out screen parts at runtime so they lign up vertically. 
The static Method of the new Class should either spot such situations automatically and correct them at run time, and/or pick up certain new layout cues that the developer puts in the YAML file and adjusts the layout according to those.

''IMPORTANT: A fix for the 'Problem #2' (mono issue) must be found as well for this to be a valid soluition!!!''

== If we find something out on the Internet that seems to address both issues==
* It must have a GPL license, or a GPL-compatible license, or be free of any license, e.g. be public domain.
* The 'Desired Outcome' must be met.
* Prove that it addresses both 'Problem #1' and 'Problem #2' (see 'Approval of Functionality and Program Code').


=Approval of Functionality and Program Code=
''TODO Needs more thinking put towards it''

Tests with existing complex layouts (e.g. the various Partner Details Tab UserControls) must be done to ensure that the chosen solution solves the problems which it purports to address!