Choix de la police inopérant dans TStatusBar

Version imprimable

03/02/2017, 22h38
Jipété

1 pièce(s) jointe(s)

Choix de la police inopérant dans TStatusBar

Bonsoir,

Pièce jointe 241288

Sur l'image ci-dessus à gauche l'inspecteur de propriétés des objets, positionné sur la section Font du StatusBar et où on peut lire que la police choisie est Libération Mono (une police Linux à chasse fixe [similaire à Courier New pour les Windowsiens], pour bien aligner les colonnes de chiffres [oui, dans un projet j'ai deux TStatusBar l'un au-dessus de l'autre, avec des nombres longs...]), et on enfonce le clou avec le pitch à fpFixed, mais comme on peut le constater sur la partie droite de l'image, ces paramètres laissent totalement indifférent le TStatusBar à qui ils s'appliquent, contrairement au TEdit placé juste au-dessus pour montrer que certains composants y réagissent bien, et même sans forcer le pitch : le nom de la police leur suffit...

Fait pour servir et valoir ce que de droit, :mouarf:

Debian 8 / FPC 3.0 / Laz 1.6.2
05/02/2017, 15h57
Alcatîz

Bonjour,

Le bug ne se produit que sous Linux, et quelle que soit la police choisie et la police de la form parent (dans les version 1.0.x et précédentes, la police était héritée du parent si je ne me trompe pas). Aucun souci sous Windows.

:koi:
05/02/2017, 16h08
Jipété

Bonjour,

Citation:

Envoyé par Alcatîz

Le bug ne se produit que sous Linux, et quelle que soit la police choisie et la police de la form parent (dans les version 1.0.x et précédentes, la police était héritée du parent si je ne me trompe pas). Aucun souci sous Windows.

:koi:

Pas la 1^re fois que je constate que Linux est le parent pauvre sous Lazarus... Alors on va me parler de WidgetSet, de Gtk2 mal ou pas supporté, etc., et c'est pour ça que j'ai pensé à montrer qu'il n'y avait pas de souci avec le TEdit (ni avec le TMemo, entre autres)...
Oublié de préciser que j'ai bien mis ParentFont := False.

Et j'ai d'autres bugs dans ma mallette : si je copie/colle un TTrackBar d'un emplacement à un autre, pas de problèmes ; si j'en copie/colle deux en même temps, les deux collés se retrouvent avec la propriété Visible à False ! Au 1^er run ça surprend...

J'en ai d'autres, je les garde au chaud pour une autre fois, j'ai des trucs à faire avancer.
05/02/2017, 21h42
gvasseur58

Citation:

Envoyé par Jipété

Bonjour,

Pas la 1^re fois que je constate que Linux est le parent pauvre sous Lazarus... Alors on va me parler de WidgetSet, de Gtk2 mal ou pas supporté, etc., et c'est pour ça que j'ai pensé à montrer qu'il n'y avait pas de souci avec le TEdit (ni avec le TMemo, entre autres)...

Bonjour,

J'ai regardé l'historique complet de TStatusbar, mais le bogue cité n'apparaît nulle part. Je te suggère d'ouvrir un signalement de bogue sur le site freepascal.

L'expression parent pauvre n'est pas totalement fausse, même si elle me semble exagérée. Il suffit de regarder le nombre de téléchargements de la version 1.6.2 de Lazarus sur sourceforge pour se rendre compte que Linux n'a pas vraiment le vent en poupe pour les applications de bureau : 3844 téléchargements W32, 6208 W64, 912 MacOS, 2153 Linux (répartis en fait en 4 catégories :calim2:). Ce n'est pas négligeable, mais la remontée des bogues est bien plus faible pour Linux et les spécialistes à même de résoudre les problèmes bien plus rares aussi.

Quand je veux obtenir quelque chose avec Lazarus, j'essaye de me repérer grâce au roadmap : il se trouve que la classe TFont n'est que partiellement implémentée pour gtk2. En revanche, TSatusbar ne souffre pas de ce problème (sauf pour sa fonte ?). Il faudrait aller voir dans le code source Linux du traitement de la Statusbar pour en avoir le cœur net.

Je précise que, très souvent, le retard de Linux est dû à des a priori de FreePascal et de Lazarus. Les concepteurs ne veulent pas s'éloigner de Delphi qui ne fonctionne pas sur Linux (au moins pour le moment :mrgreen:). Le point de vue est biaisé dès l'origine : c'est Windows qui prime. La conséquence est qu'on essaye de mimer le fonctionnement de Windows sur Linux et que la conception ne s'y prête pas toujours (par exemple, il est impossible de travailler avec des caractères Unicode avec gtk, ou telle API n'a pas de correspondance immédiate pour les deux plateformes).

Petite remarque au passage : ce n'est pas parce que TEdit ou TMemo fonctionnent bien que TStatusbar le fera. Si tous les trois descendent de TWinControl, TEdit et TMemo ont un ancêtre commun direct (TCustomEdit) qui leur confère un fonctionnement similaire alors que ce n'est pas le cas de TSattusbar (ce qui se comprend).

Cordialement,

Gilles
17/12/2017, 00h38
Jipété

1 pièce(s) jointe(s)

Bonsoir,

solution de contournement :
poser un TLabel sur la fiche, penser à lui mettre AutoSize à False dans l'inspecteur d'objets, puis dans FormCreate lui déclarer son parent comment étant le StatusBar et son alignement à alClient et voilà !
Le plus rigolo, c'est que si le StatusBar n'est pas fichu d'écrire avec la police que je lui demande gentiment d'utiliser, il est quand même capable de la transmettre au Label. :marteau:

En fonction de trucs et de machins (taille de police, etc.), il vous faudra peut-être (sans doute !) jouer avec la propriété BorderSpacing.Top que j'ai mise à 2 pour cet exemple, sinon le texte était collé en haut sous le trait, très moche :

Pièce jointe 335523

Allez hop !, c'est bientôt Noël, alors :resolu:

Bon, je ne l'ai testé qu'en mode SimplePanel, peut-être que ça fonctionnerait avec plusieurs labels et plusieurs panels : à tester.
17/12/2017, 04h01
Pierre le Grand

Citation:

Envoyé par gvasseur58

L'expression parent pauvre n'est pas totalement fausse, même si elle me semble exagérée. Il suffit de regarder le nombre de téléchargements de la version 1.6.2 de Lazarus sur sourceforge pour se rendre compte que Linux n'a pas vraiment le vent en poupe pour les applications de bureau : 3844 téléchargements W32, 6208 W64, 912 MacOS, 2153 Linux (répartis en fait en 4 catégories :calim2:). Ce n'est pas négligeable, mais la remontée des bogues est bien plus faible pour Linux et les spécialistes à même de résoudre les problèmes bien plus rares aussi.

La plupart des distros Linux permettent l'installation directe de Lazarus depuis les dépôts de logiciels sans passer par sourceforge. Ces chiffres ne sont donc pas significatifs en soi. Cependant, l'installation automatique est souvent déficiente, Free Pascal de même que la LCL n'étant pas toujours installés par les installateurs automatiques. De plus, la version de Lazarus supportée par la distro est souvent désuète, même pour les version qui ne sont pas LTS.
17/12/2017, 10h05
ApproxDev

Citation:

Envoyé par gvasseur58

Bonjour,

J'ai regardé l'historique complet de TStatusbar, mais le bogue cité n'apparaît nulle part. Je te suggère d'ouvrir un signalement de bogue sur le site freepascal.

L'expression parent pauvre n'est pas totalement fausse, même si elle me semble exagérée. Il suffit de regarder le nombre de téléchargements de la version 1.6.2 de Lazarus sur sourceforge pour se rendre compte que Linux n'a pas vraiment le vent en poupe pour les applications de bureau : 3844 téléchargements W32, 6208 W64, 912 MacOS, 2153 Linux (répartis en fait en 4 catégories :calim2:). Ce n'est pas négligeable, mais la remontée des bogues est bien plus faible pour Linux et les spécialistes à même de résoudre les problèmes bien plus rares aussi.

Bonjour, le parent pauvre de Lazarus, ce n'est pas Linux mais Mac OS. Comme je l'écrivais récemment, développer avec Lazarus sur autre chose que Windows nécessite un développement chronophage des composants en interne au point parfois d'en oublier le projet que l'on développe. Je suis comme Jipété, très mécontent de la politique de développement de Lazarus. Sous Mac, j'ai dû recompiler gdb pour pouvoir l'intégrer à la plateforme. Aucune documentation. Solution proposée : une bidouille maison toute Lazarusienne sur le site.

Je lis souvent Jipété et son mécontentent auquel je souscris totalement. Effectivement, Lazarus n'est pas réellement multiplateforme. Quand une plateforme de développement l'est, on peut produire la même chose dans les 3 OS comme on le fait avec Qt. Et ce n'est évidemment pas le cas avec Lazarus. Comme le dit Jipété, ce n'est pas dû aux spécificités des OS, mais à un simple manque d'investissement : au lieu de continuer une course en avant folle, il serait plus sage de consolider le produit et de le rendre réellement portable. Ce n'est pas un produit commercial, donc il n'y a aucune raison de ne pas prendre son temps.

Il suffit pour s'en convaincre de regarder ce qu'a fait TMS au niveau de la gestion du RichText alors que pendant des années, on a dû se contenter de 2 malheureux composants ne pouvant pas être utilisés dans les 3 OS sans correction, et même sur certains OS, non portables de 32 à 64 bits. Maintenant, ici, on utilise Lazarus comme solution de secours car même développer en C++ est plus rapide que d'utiliser Lazarus et surtout plus prévisible au niveau des délais.

Cordialement. AD.
21/12/2017, 16h08
anapurna

Salut

A priorie ils avaient le même souci en C.

Voir ici