Différencier le fichier .lfm selon l'OS

Version imprimable

29/04/2018, 11h03
ChPr

Différencier le fichier .lfm selon l'OS

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
29/04/2018, 12h35
Jipété

Salut,

Citation:

Envoyé par ChPr

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.
29/04/2018, 13h23
ChPr

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

Cordialement.

Pierre

Citation:

Envoyé par ChPr

...

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:

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:

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.

29/04/2018, 14h47
ChPr
Citation:
Envoyé par FChrisF

... Par exemple:

Code:

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
29/04/2018, 15h47
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. :?

Citation:

Envoyé par FChrisF

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é.

Citation:

Envoyé par BeanzMaster

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 !

Citation:

Envoyé par BeanzMaster

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:

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 !
:plusser:

30/04/2018, 09h27
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
30/04/2018, 10h29
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.
30/04/2018, 22h51
BeanzMaster

Salut

Comme Tintinux :plusser:, 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.
02/05/2018, 16h45
ChPr

Citation:

Envoyé par BeanzMaster

... 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ù :

Citation:

Envoyé par ChPr

... 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
02/05/2018, 22h56
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 ;)
02/05/2018, 23h11
Jipété

2 pièce(s) jointe(s)

Salut,

Citation:

Envoyé par BeanzMaster

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...

Pièce jointe 375695

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 :
Pièce jointe 375699

In fine, je ne crois pas qu'il y ait de solution universelle et définitive.
C'est comm' ça...
03/05/2018, 18h46
tourlourou

UniGUI ?