Discussion :

[ChPr]

Bonjour à toutes et à tous,

Dans l'application que je crée, il s'avère que les différents composants n'ont pas les mêmes dimensions selon que l'OS est Windows ou Linux.

Les tailles et positions étant données par les fichiers .lfm, je cherche à savoir s'il est possible de les différencier selon l'OS avec des balises.

Je n'ai rien trouvé sur le net et les balises de ce type {$IFDEF UNIX}...{$ELSE}...{$ENDIF}; n'y fonctionnent pas.

Y a-t-il une solution ?

Cordialement.

Pierre

[Jipété]

Salut,

Je n'ai rien trouvé sur le net et les balises de ce type {$IFDEF UNIX}...{$ELSE}...{$ENDIF}; n'y fonctionnent pas.

Y a-t-il une solution ?

Perso j'utilise les balises dans le FormCreate et j'y impose les valeurs qui vont bien.

[ChPr]

Ouais, mais vu que j'ai pratiquement tous mes composants à déplacer/redimensionner, c'est ce que j'aurais voulu éviter.

Cordialement.

Pierre

[FChrisF]

...

Je n'ai rien trouvé sur le net et les balises de ce type {$IFDEF UNIX}...{$ELSE}...{$ENDIF}; n'y fonctionnent pas.

...

Cela ne "fonctionne pas" mais uniquement au niveau de l'EDI (probablement parce que celui-ci charge le fichier .lfm correspondant au nom de l'unité "en dur").

Mais apparemment cela fonctionne lors de la compilation.

Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
{$IFNDEF UNIX}
   {$R Unit2.lfm}
{$ELSE}
   {$R Unit1.lfm}
{$ENDIF}

utilise bien la forme 2 lors de l'exécution sous Windows (i.e. c'est la bien la forme 2 "unit2.lfm" qui est mise dans les ressources de l'exécutable), et inversement si l'on modifie le test.

Bon, je reconnais que c'est loin d'être pratique pour construire les formes dans l'EDI, mais en jonglant un peu (i.e. renommage des fichiers .lfm) et s'il n'y a pas des modifs à faire trop souvent au niveau des formes, cela doit être "faisable".



*** Edit ***

Sinon, vous pourriez aussi faire la différenciation au niveau du fichier .lpr. Quelque chose comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, 
  {$IFDEF UNIX}Unit1Unix{$ELSE}Unit1Win{$ENDIF}
  { you can add units after this };

Mais cela demande de "jongler" un peu, notamment pour que le fichier .lpi soit correct. Par ailleurs, cela nécessite d'avoir les fichiers de code en double (i.e. Unit1Win.pas et Unit1Unix.pas dans mon exemple), ce qui est loin d'être idéal pour la maintenance.

[ChPr]

... Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
{$IFNDEF UNIX}
   {$R Unit2.lfm}
{$ELSE}
   {$R Unit1.lfm}
{$ENDIF}

...

Alors ça, c'est marrant, c'est ce que je viens d'essayer dans mon coin et effectivement, ça fonctionne.

Bon, évidemment, il ne faut pas avoir beaucoup de modifs à faire sinon, ça devient vite galère.

Cordialement.

Pierre

[BeanzMaster]

Le problème des composants qui sont redimensionnés en fonction des OS, est souvent causé par les polices de caractères, celle-ci ne sont souvent pas les même, ainsi que leurs tailles. Une façon de régler le problème serai de pouvoir charger une police depuis application. Mais là je n'ai aucune idée de comment procéder.

[Jipété]

Bon, je reconnais que c'est loin d'être pratique pour construire les formes dans l'EDI, mais en jonglant un peu (i.e. renommage des fichiers .lfm) et s'il n'y a pas des modifs à faire trop souvent au niveau des formes, cela doit être "faisable".

C'est bien pour ça que je ne l'ai pas proposé.

Le problème des composants qui sont redimensionnés en fonction des OS, est souvent causé par les polices de caractères, celles-ci ne sont souvent pas les mêmes, ainsi que leurs tailles.

Ah ouais, pas mal !

Une façon de régler le problème serait de pouvoir charger une police depuis l'application. Mais là je n'ai aucune idée de comment procéder.

Le chargement est automatique si la police est définie dans l'EDI car elle va se retrouver dans le .lfm et donc compilée et tout et tout, exemple (plein de lignes enlevées) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
object Form1: TForm1
  Left = 325
  Height = 213
  Top = 159
  Width = 318
  object rdgChoix: TRadioGroup
    Font.CharSet = ANSI_CHARSET
    Font.Color = clWhite
    Font.Height = -11
    Font.Name = 'Tahoma'

Il suffit donc d'avoir la même font installée dans les deux environnements, genre installer Liberation Sans de Linux (dans /usr/share/fonts/truetype/liberation) dans Windows et l'utiliser partout ensuite.
Oui, ça pourrait bien le faire !

[ChPr]

Si l'utilisation d'une fonte commune résout certains problèmes, c'est loin de tout résoudre.

Pas mal de composants ont des formes différentes (par exemple les TComboBox et autres de cette catégorie), notamment dues aux ascenseurs. Des couleurs différentes, par exemple clInfoBk qui est noir en Linux et jaune paille en Windows ...

D'une manière générale, les composants sous Linux prennent plus de place d'où l'idée que de commencer à réaliser l'interface graphique sous Linux posera moins de problème dans la transposition sous Windows.

Cordialement.

Pierre

[tintinux]

Bonjour

Je trouve ça fastidieux d'utiliser des lfm différents, et il en faudra d'autres pour Mac...

Pourquoi avez-vous besoin de dimensionner les composants en fonction de l'OS ?

Il me semble nettement préférable et plus simple de jouer sur les propriétés "Align" des composants et de les organiser dans des panels pour qu'ils prennent la position et les dimensions optimales en fonction du widgetset graphique (qui dépend certes de l'OS). C'est très performant, et très facile sous Lazarus, bien plus que sous Delphi.

[BeanzMaster]

Salut

Comme Tintinux , je procède souvent comme ça et je joue avec les panels, propriété align, borderspacing Alignment pour les textes et aussi Anchors quelques fois. Le seul truc il faut que les panels aient des dimensions légèrement supérieures sous Linux par rapport à Windows à cause des dimensions des polices de caractères.

[ChPr]

... Le seul truc il faut que les panels aient des dimensions légèrement supérieures sous Linux par rapport à Windows à cause des dimensions des polices de caractères.

D'où :

... D'une manière générale, les composants sous Linux prennent plus de place d'où l'idée que de commencer à réaliser l'interface graphique sous Linux posera moins de problème dans la transposition sous Windows.

Cordialement.

Pierre

[BeanzMaster]

Sauf si tu utilise la même police et la même taille sous les différents OS comme on le disait plus haut. Options à modifier dans le OnCreate de la form. Mais je pense également comme toi c'est plus simple de passer de Linux à Windows que l'inverse

[Jipété]

Salut,

Sauf si tu utilises la même police et la même taille sous les différents OS comme on le disait plus haut.

J'ai testé et dans l'ensemble c'est correct (les pinailleurs remarqueront que le RadioGroup est 1 pixel plus bas sous Linux que sous Windows).
Le problème vient surtout de la taille de la fiche, différente au niveau des bordures (la zone "client" est identique) selon l'os, et sans doute déterminée par les thèmes.
Et pour unifier ça, laisse tomber !

Regardez : les bordures gauche-droite sous Linux sont de 1 pixel (sacrée prise de tête pour redimensionner une fenêtre, des fois...), par contre la bordure basse est plus grande que celle de Windows.
Mais la barre de titre c'est la cata...



Le centre de l'image (zoomée à 800 %) avec les 3 fiches dont la zone client a été colorée en vert pour mieux la voir :


In fine, je ne crois pas qu'il y ait de solution universelle et définitive.
C'est comm' ça...

[tourlourou]

UniGUI ?