• [^] # 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é à 1.

    Ok, donc, voila un screenshot avec mes boutons et des bordures assez epaisses.

    Ok, je veux bien admettre que c'est _un peu_ épais. Rien de très flagrant, je trouve, et surtout, rien qui ne soit pas configurable, soit par l'application, soit par le thème, iirc. Donc..


    Pour la zone de texte, je voyait pas les choses comme ca.
    Je pensait plus a taper mon texte, et a pouvoir me deplacer a l'interieur comme je le fait avec ce commentaire que je tape.
    en fait, mettre un retour chariot automatique, mais qui n'apparaisse pas dans les messages. C'est peut etre pas trés clair, mais, la ce commentaire, j'ai tout tapé sans appuyer sur entree. Pourtant Konqueror me met des retours a la ligne, et avec fleche haut, je remonte a la ligne du dessus.


    OK, tu veux simplement du wrapping (ou de l'auto-fill, comme dirait mon Emacs. :). Bon, ça, c'est pas franchement lié à Gtk+, même pas du tout, c'est simplement un choix de Gaim. Si tu mattes 30s les sources, tu verras qu'il fait un:

    gtk_text_set_word_wrap(GTK_TEXT(entry), TRUE);

    et que donc tu vas avoir du wrapping pour les mots, mais pas pour les lignes. Un simple:

    gtk_text_set_line_wrap(GTK_TEXT(entry), TRUE);

    de plus changerait le comportement de ce point de vue. Mais encore une fois, il n'est pas dit que ça ne pose pas un problème quelconque à Gaim par la suite - je ne connais pas ce soft spécifique, à toi de demander aux auteurs (#gaim@freenode est très fréquenté).

    Peut etre que Gtk2 le fait.

    GtkText le faisait - bien heureusement! tu vois bien que tu peux le faire dans GEdit de Gnome 1, par exemple, donc, comme il s'agit du même widget tu peux le faire partout -, et, bien entendu, GtkTextView le fait - de façon même plus logique, puisque c'est géré via un enum, et puis, il est assez clair qu'il s'agit bien d'un changement de vue plutôt que de contenue, grâce à la séparation contents/view (GtkTextBuffer/GtkTextView).


    En parlant de ca aussi, sur mon ordi, la molette de la souris tourne a l'envers sur les applis gtk ( 1.2 ).
    Quand je roule vers l'avant, ben, Gimp ( par exemple ) me diminue la valeur du controle glissiere ( exemple selection rectangulaire , option, adoucir, le controle pour regler ca ).


    Je t'assure que j'ai fait des efforts. J'ai demandé aux gens autour de moi, sur la tribune, sur IRC. Rien à faire, je ne comprends toujours pas ce que tu veux dire. Faudrait faire des efforts de clarté :)

    Tu parle des gens qui utilisent des widgets non maintenus, mais, ca veut bien dire que les widgets d'avant étaient pourris.

    Pourri, tout est relatif. Il me semble me souvenir qu'encore récemment, c'est à dire du Qt3, le widget texte de Qt était tout aussi pourri que celui de Gtk+1.2. Il y'a deux widgets qui n'assuraient vraiment pas dans Gtk+1.2, c'était GtkText, et GtkCList. GtkText parce qu'il était fait de façon très naïve, n'avait pas de bonnes performances, et ne supportait pas grand chose - ceci dit, il est à peine en dessous des widgets texte par défaut de la plupart des toolkits. d'ailleurs, beaucoup d'applications refont leur widget text quand ils veulent quelque chose de sympa. GtkCList parce qu'il avait pas mal de problèmes, qu'il était pas facile à utiliser, et un peu buggy - mais ça, ça se voyait pas trop. Ils n'étaient pas pour autant *pourris*.

    Sachant que les problémes que j'ai soulevé sur gtk ont été réglés il y a longtemps dans qt, j'estime que qt avait quand même beaucoup d'avance sur gtk, qui , apparement, rattrape pas mal son retard.

    Je n'ai pas sous la main les éléments de comparaison, mais, pour l'instant, tu ne fais qu'avancer sans prouver. Je ne suis pas persuadé que tout ce dont tu parles ait été fixé il y'a si longtemps dans Qt. Et, pour quelques uns, voire pas mal, des points que tu évoques, c'est lié à l'application, et vraiment pas à Gtk+.