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

From OpenPetra Wiki
Revision as of 12:39, 15 December 2010 by Christiankatict (talk | contribs) (Created page with '==Introduction== This project involves the creation of a component for the openPETRA GUI which can deal better with varying string lengths due to translations. A serious layout …')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

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

A serious layout problem with mono's TableLayoutPanel when used with percentages instead of absolute values for widths/heights should also be overcome.


Description of Problem #1: varying string lengths

Imagine the following situation:

  • The Labels in Column #1 in GroupBox #1 are let's say 100px wide when auto-sized with German texts.
  • The Labels in Column #1 in GroupBox #2 (which is located underneath GroupBox #1) are let's say 130px wide when auto-sized with German texts.

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 Labels in Column #1 could suddenly be wider in GroupBox #1 than in GroupBox #2!

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

Desired Outcome

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 the varying string length problems and the mono issue and has a GPL compatible licence.


Outline of the Solution

TODO Needs more investigation!

If we create a Layout Manager which we will use in replacement of .NET WinForm's TableLayoutPanel

Sun's Java SWING UI solutions for overcoming the problems of varying string lengths should be looked at in detail, tested and - after approving of them - a .NET layout manager with similar capabilities should be designed (which doesn’t give problems with mono, of course!)

If we create a Class which would correct the widths of certain columns of TableLayoutPanel-layed out screen parts at runtime

TODO

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, 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 mono issue must be found as well for this to be a valid soluition!!!

If we find something out on the Internet already

TODO


Approval of Functionality and Program Code

TODO

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 should address!