Discussion :

[Jipété]

Bonsoir,

Rions un peu avec le multi-plateforme...
Voilà le résultat du même code (c-à-d zéro code, juste le composant TTrackBar posé sur la feuille) à gauche dans Linux 32 bits et Lazarus 1.4/FPC 2.6.4, et à droite dans XP Pro 32 bits et Lazarus 1.6rc1/FPC 3.0 :



Je ne sais pas encore comment je vais gérer cette pagaille...
Sans doute à grands coups de {IFDEF LINUX} mais pour un rendu visuel identique du compo, c'est mort.

[droggo]

Bonjour,

Affirmer Write once, compile anywhere n'implique pas qu'on obtienne le même look sur différents systèmes, et encore moins en utilisant des versions différentes.

[Jipété]

Affirmer Write once, compile anywhere n'implique pas qu'on obtienne le même look sur différents systèmes,

Pas le même look, j'aurais pu m'adapter, mais

et encore moins en utilisant des versions différentes.

quand on voit comment est traitée la TListview (c-à-d non traitée), de version en version, je ne vois pas pourquoi je me prendrais la tête à migrer pour rien, pour les points qui m'intéressent.
Parce que ce que je constate, là, c'est une perte de fonctionnalités en passant de Linux à Windows, or il se trouve que la version a évolué, du pingouin aux fenêtres, et là j'y perds en fonctionnalités !
Régression ?
Alors ? Sous Windows je redescends en 1.4.0 ?
Bah, je suis à peu près sûr que le résultat sera le même : comme pour la TListview, tout n'est pas développé...

[tourlourou]

Clairement, pour les composants qui wrappent ceux natifs des API de l'OS, le rendu ne peut être identique en passant de l'un à l'autre.

La solution résiderait peut-être (à terme) dans fpGUI ?

[Jipété]

Salut, YL !

Clairement, pour les composants qui wrappent ceux natifs des API de l'OS, le rendu ne peut être identique en passant de l'un à l'autre.

Que le rendu ne soit pas identique, j'aurais pu m'adapter, comme je le disais ; mais là (comme pour la Listview), ça va plus loin, je trouve : c'est au niveau des fonctionnalités !
Évidemment, si ça dépend de l'OS, alors là c'est mort...
J'avais envisagé un instant, lors de discussions avec Gilles à propos de la Listview de passer à Qt, mais il me l'a déconseillé. Peut-être Gtk3, alors ? Je fouillerai dès que j'aurai du temps...

La solution résiderait peut-être (à terme) dans fpGUI ?

[EDIT]
L'outil pour lequel on a vu passer une news il y a environ 2 ou 3 mois ? Je l'ai téléchargé, installé (avec un peu des misères liées à des chemins) et, suivant le tuto d'install, j'ai essayé de faire tourner le premier test, sans jamais y parvenir !
J'ai abandonné et tout viré.
C'est à se demander si les gens qui codent ça testent dans les autres environnements...
J'ai fait une confusion avec MSEGui et MSEide, désolé. [/EDIT]

Bon pont

[Jipété]

Salut !

Je voulais essayer de comprendre ce qui se passe avec un programme (venant de l'excellent site d'efg et converti laborieusement) car, lorsque juste après son lancement je passe la souris sur l'arc-en-ciel, les radio-boutons se décalent (alors qu'il y a zéro code dans la procédure ImageMouseMove concernant ce comportement : en fait, cette proc sert juste à faire afficher en grand [et plus loin et plus bas que le RadioGroup] la couleur que la souris survole : pas de quoi fouetter un chat !)
Regardez l'image (c'est un montage, pour bien montrer le décalage avant et après le MouseMove) :


Alors, oui, ça n'est pas bien grave, mais ça chatouille l'œil qui détecte que quelque chose a bougé et ne sait pas quoi : c'est perturbant.

Bref, comme j'ai toujours ces problèmes d'exécution cassée en mode pas-à-pas (j'en avais parlé il y a longtemps), j'ai décidé d'essayer le code sans en changer une virgule dans une machine XP où tourne Laz1.6rc1 et là, au lancement, avant même de voir la fiche du programme, une superbe fenêtre d'access violation avec l'assembleur qui me crache ses insultes et voilà, quoi...

Sous Windows le pas-à-pas ayant l'air de fonctionner, j'ai essayé mais je me suis retrouvé dans des fichiers .inc pas très parlants et de toute façon, je ne vais pas aller trifouiller là-dedans.
Ah, le gag c'est que le zip fourni par efg inclut un binaire (compilé avec sans doute un Delphi 3 ou 4 ou 5) pour Windows qui... s'exécute impécablement

Je ne demande pas une solution, je sais qu'il n'y en a pas, c'était juste le coup de gueule du dimanche matin -- tiens, j'vais aller faire un tour au marché, ça me changera les idées, parce que le code, il y a des jours, franchement...

[gvasseur58]

Salut, et bon marché !

Je voulais essayer de comprendre ce qui se passe avec un programme (venant de l'excellent site d'efg et converti laborieusement)

Je confirme qu'il s'agit d'un excellent site. Mais je réaffirme aussi que le comportement ET l'aspect des contrôles de base sont dépendants du système d'exploitation. Il est parfois possible d'unifier le tout en passant d'un OS à un autre, mais ce n'est pas toujours le cas. D'ailleurs, même l'aspect des fenêtres (et leur fonctionnement) est différent suivant l'OS utilisé, et ça ne gêne pas plus que de changer de voiture ou de s'adapter à une nouvelle conduite...

Le "compiler une fois" reste, à mon avis, valable : il garantit que le programme fonctionnera au mieux sur différents OS, dans les limites de la transcription des bibliothèques. Il ne peut en revanche jamais garantir un fonctionnement uniforme. La plupart des dysfonctionnements ne viennent pas de Free Pascal (LAzarus), mais de ces différences fondamentales.

Encore une petite chose : il ne faut pas utiliser les versions intermédiaires (RC1, RC2...), car elles contiennent des bogues (elles sont faites pour être testées massivement). La version 1.6RC1 de Lazarus est connue pour ses problèmes de débogueur !

Dans mon village, le marché se tient le lundi matin : je saurai patienter

[Jipété]

Mais je réaffirme aussi que le comportement ET l'aspect des contrôles de base sont dépendants du système d'exploitation. Il est parfois possible d'unifier le tout en passant d'un OS à un autre, mais ce n'est pas toujours le cas.

T'as oublié un poil de magie et un soupçon de vaudou,

D'ailleurs, même l'aspect des fenêtres (et leur fonctionnement) est différent suivant l'OS utilisé, et ça ne gêne pas plus que de changer de voiture ou de s'adapter à une nouvelle conduite...

Je réussis à masquer le défaut en bidouillant ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
procedure TFormSpectra.FormActivate(Sender: TObject);
begin
  // tout ça pour masquer le "resize" du RadioGroup...
  ImageSpectraMouseMove(nil,[ssLeft],0,0);
  ShapeColorBox.Visible    := False;
  LabelColorBoxNm.Visible  := False;
  LabelColorBoxTHz.Visible := False;
  ButtonColorBox.Enabled   := False;
  LabelRGB.Caption         := '';
end;

On ne m'ôtera pas de l'idée qu'il se passe des choses bizarres : pourquoi le RadioGroup retaille un peu ses items en mode horizontal (mais pas en vertical) si je passe la souris sur le TImage
Parce que le code du MouseMove, je le répète, n'a rien à voir avec la taille des colonnes et des items du RadioGroup, mais alors, rien de chez rien !

Bon, j'ai trouvé : c'est le fait de rendre visibles les labels en bas à droite ou le TShape blanc dans cette proc MouseMove qui fait déplacer les items dans le RadioGroup : on est bien d'accord qu'on marche sur la tête, là, non ?

[gvasseur58]

Bon, j'ai trouvé : c'est le fait de rendre visibles les labels en bas à droite ou le TShape blanc dans cette proc MouseMove qui fait déplacer les items dans le RadioGroup : on est bien d'accord qu'on marche sur la tête, là, non ?

Bon, je crois avoir trouvé aussi, car le problème est récurrent : l’affichage de nouveaux contrôles va déclencher un Repaint de la fiche et une adaptation des éléments affichés par re-calcul de leurs dimensions et de leur emplacement, avec des arrondis. Le décalage doit venir du résultat de ces calculs : je te rappelle que je ne suis pas un fan des techniques vaudous (je ne suis pas superstitieux parce que ça porte malheur ).
C'est en fait le seul réel problème que je rencontre lorsque j'écris une application qui doit tourner sur Windows et Linux : par exemple, les deux OS ne gèrent pas de la même manière l'affichage des Caption de TLabel , Linux ayant tendance à nécessiter plus de place ; idem pour les glyphes des TBitButton... Si la base du programme et 99% des procédures sont communes, l’interface graphique a souvent besoin de retouches. Personnellement, je ne retouche qu'elle, sans adapter les procédures comme tu le proposes : à mon avis, il vaut mieux une différence d'affichage qu'une rustine difficile à comprendre et par conséquent à maintenir.

Cela dit, si je me trompe, joins un fichier à compiler

[tintinux]

Hello Jipété

Tu devrais essayer de programmer avec Lazarus pour Android. Là, tu verras de vraies différences !

J'en parle parce que d'honorables geeks ont inventé il y a déjà plusieurs années les composants visuels "CustomDrawn" qui font très peu appel aux systèmes d'exploitation et dessinent et gèrent tout ou presque avec du code Pascal. Cela résout théoriquement les problèmes dont tu te gausses, et c'est à mon avis la seule solution qui permet d'espérer avoir le même code et les mêmes composants visuels sur des systèmes et interfaces très différents.

Entre Windows, Linux et OS/X, c'est opérationnel, mais pour très peu de composants, avec peu de propriétés. Il manque encore beaucoup de choses et cela semble au point mort, De plus ça ne marche plus à partir d'Android 5.

Alors si tu as le temps en rentrant du marché, tu peux regarder et aider la communauté en construisant un contrôle manquant, ou en ajoutant des propriétés et événements à ceux qui existent, comme je l'ai fait l'an dernier.

Ce sera plus utile que de râler.