• [^] # Re: Ca compile c'est déjà ça ...

    Posté par . En réponse à la dépêche OOo pour MacOS X : ça compile c'est déjà ça .... Évalué à 2.

    concernant les tonnes de bordures, j'ai pas utilisé de thémes particuliers.
    et c'est vrai que j'ai pe exagéré la taille. mais, ca se voit mieux sur un petit ecran...


    Franchement, même sur le thème par défaut, je ne vois pas ce que tu veux dire. Un screenshot serait bienvenu. Et pourtant il m'est arrivé de regarder - pas longtemps, je vous avoue :-) - un 14", avec des applications Gtk+, et ça ne m'a pas frappé *du tout*.

    en fait, c'est le principe, c'est le gaspillage d'une 10aine de pixels.
    je sais qu un théme peut améliorer ca. Sauf que , ca devrait etre bien par défaut.


    Si tu veux, je ne vois pas où c'est comme ça, mais bon. De toutes façons, ça n'est pas réellement lié à Gtk+ mais à un thème par défaut. Si tu arrives à réellement identifier le problème, tu peux peut-être faire une wishlist - le bugreport est assez aisé avec Gnome/Gtk+, via bug-buddy.

    Bien sur, si on veut faire mieux, on peut le faire. Tu est en train de me dire que on peut utiliser d'autres widgets plus puissants et voila ?

    Euuh? Je suis en train de te dire qu'on peut utiliser la dernière version de Gtkl+, et que parler de Gtk+1.2, qui date quand même assez, ne sert plus à grand chose maintenant: il faut juste inciter les développeurs d'application à porter leurs apps vers Gtk+2. De toutes façons, ce port est vraiment agréable à faire et rend les choses plus claires, sans compter que les nouveaux widgets sont un bonheur à utiliser (en tant que programmeur comme en tant qu'utilisateur, cf. le widget texte et les list/trees).

    Ben oui, mais par défaut ce n'est pas le cas.

    Ben, si. Au cas particulier des sépérations, c'est le cas par défaut avec Gtk+2. Pour les boutons, je peux pas te répondre, je ne vois réellement pas de quoi tu parles. Pour les listes, pareil, ceux qui choisissent d'utiliser un widget qui n'est plus maintenu et qui disparaitra avec le temps, quand on estimera que les applications majeures sont passées aux nouveaux widgets.

    Un autre exemple , gaim.
    la zone de texte est en fait un controle sur une ligne...
    donc, fleche haut ne remonte pas...


    Bon, je viens d'installer le dernier gaim, pour voir. J'imagine que tu parles de la zone de texte dans la boîte conversation (i.e., celle que tu obtiens après avoir fait New Instant Message et entré le screenname de ton interlocuteur). Bon, mais je ne comprends pas beaucoup mieux ce que tu veux dire. Ils ont mis des callbacks sur activate et sur keypress_event, de telle façon qu'un « Entrée » envoie le message. Donc, ça ne peut être que sur une ligne, hein? Ah, quoique. Je sais pas si c'est voulu, mais je peux envoyer des messages de plusieurs lignes en tapant ^M (C-m) au lieu de Entrée, et donc, ensuite, je peux remonter, redescendre, avec les flèches du haut/bas, etc.

    C'est parce que le logiciel est mal fait ?

    Euh, à vue de nez, je pense que c'est parce qu'il s'agit d'IM et qu'ils veulent des messages courts. Je sais pas dans quelle mesure le protocole utilisé change quelque chose, peut-être même que (\r)\n est se séparateur, who knows.

    Qu'est ce qu'une zone de texte a une ligne si ce n'est un controle multiligne d'une seule ligne ?

    Uh? Alors là, je te suis pas du tout. Vazy, explique ce que tu voudrais que ça fasse et que ça ne fait pas actuellement, parce que je comprends vraiment pas.

    Ca devrait etre plus cohérent au niveau de la bibli.

    Je doute que la bibliothèque ait quoi que ce soit à voir avec ça. (hmm, d'autant plus que Gaim est pour Gtk+1.2, et utilise GtkText).

    Et pour le coté non graphique de la boite de dialogue, c'est vrai que c'est bien mieux, mais c'est pour Gnome, donc a comparer avec celle de KDE, qui offre plus d'options...

    Pas seulement, non. Ce sera changé aussi dans Gtk+, très probablement.