OOo pour MacOS X : ça compile c'est déjà ça ...

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
9
nov.
2002
Apple
Le portage natif d'OpenOffice pour Macos X progresse puisque maintenant on passe la compilation et l'édition des liens. Il manque toujours le principal pour qu'elle soit utilisable: le support de Quartz et Aqua. Si vous êtes à l'aise avec la programmation de la pomme vous pouvez rejoindre le projet.

Note du modérateur : En fait Il y a le support de Quartz, puisque c'est la version Quartz qui compile mais ne marche pas encore (la version X11, elle, tournait déja). Quand cette version marchera correctement, la dernière étape du portage, utiliser Aqua, commencera. (Je n'ai pas de Mac mais c'est ce que j'ai compris de la VO)

Aller plus loin

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

    Posté par  . Évalué à 1.

    Quoi ? OOo va être porté sous Aqua alors que nous on doit se taper leurs infâmes widgets à la noix ? Y a pas de version GTK ?
    • [^] # Re: Ca compile c'est déjà ça ...

      Posté par  . Évalué à 1.

      Ils devraient plutôt faire une version qt, vu que qt est déjà porté sous macOSX ET supporte l'interface aqua.
      • [^] # Re: Ca compile c'est déjà ça ...

        Posté par  . Évalué à 2.

        sauf que qt sous MacosX est payant et pas libre. et puis ça doit etre du Carbon et pas du Cocoa, mais ça m'étonnerait qu'ils puissent faire du Cocoa pour OOo dttf.
      • [^] # Re: Ca compile c'est déjà ça ...

        Posté par  . Évalué à 1.

        Ils devraient plutot faire ce qu'ils avaient annoncé. C'est à dire une version gtk.
        • [^] # Re: Ca compile c'est déjà ça ...

          Posté par  . Évalué à 1.

          oui, et pour linux une version gtk _et_ une version qt, comme ça pas de jaloux :-)
          • [^] # Re: Ca compile c'est déjà ça ...

            Posté par  . Évalué à 1.

            Perso, j'aime pas les widgets d'Office pour la meme raison que j'aime moins les widget Qt ( look&feel pensés pour mswindows), donc je vote pour un port gtk !

            Et un autre truc qui m'ennerve: Office est affreux sans anti-aliasing (voilà ce que c'est d'utiliser des fontes Truetype (oxymore)), or, y'a pleins de drivers qui n'ont pas l'extension Xrender (nottament les portables, souvent utilisés pour faire de l'office)..
            • [^] # Re: Ca compile c'est déjà ça ...

              Posté par  (site web personnel) . Évalué à 2.

              Sincerement, je veut pas donner l'impression de relancer la guerre gtk-qt, mais, il y a quand meme des pbs de nature ergonoomique dans gtk.

              avant de donner mon avis, je precise que je me base sur du gtk1. j'ai pas essayé le gtk 2, ni tenter de modifier ca avec des themes, ou autres.

              bien, donc, gtk, ennemi de l'ergonomie ?

              prenons le dialogue pour enregister un fichier. dés qu'on change de repertoire, pouf le nom du fichier disparait.
              Charmant, non ?
              J'ai pris la mauvaise habitudes de download des trucs dans /tmp, alors, ca me gonfle un peu a force...
              en plus, cette boite est graphique a souhait...

              ensuite, que quelqu'un vienne me dire que c'est utile de mettre des kilometres de bordures autour des boutons...
              enfin, tout le monde a un ecran assez grand, n'est ce pas ?

              toujours dans la meme veine, le séparateur entre deux zones redimensionnables.
              rpmdrake de la mdk 8.2 est un bonne exemple.
              le truc ou il y a une zone minuscule pour faire glisser le separateur ( je sais, ca depends du theme ). ben, c'est nulle. sous qt, tu clique n'importe ou sur la barre et c'est bon ca glisse.

              enfin, les listes. Par exemple, le plugin de gkrellm, gkrellmlaunch.
              on peut cliquer sur les boutons au dessu des listes, masi il ne se apsse rien. pour alors autoriser le click ? c'est ce qu'on appelle un mauvais feedback. On a l'impression que ca fait quelque chose, masi ca fait rien. Et le bouton passe en surbrillance quand on passe dessus, donnait l'impression qu'une action est possible...

              voila, tout cela n'existe pas dans qt.
              pour moi, tant que gtk aura ces problémes, qt sera mieux. ( pour moi )
              • [^] # Re: Ca compile c'est déjà ça ...

                Posté par  . Évalué à 1.

                Je suis sincérement d'accord avec toi ! Mais n'allons pas relancer un vieu troll. Mais je dois avouer que le fait d'avoir gkrellm en gtk 2 sur mon beau bureau kde me fait un peu de la peine !

                Pareil pour The gimp. Je sais bien que Gtk is the gimp toolkit, mais si il avait une architecture modulaire, comme je parle dans mon post si dessous, cela serait tellement mieux !
              • [^] # Re: Ca compile c'est déjà ça ...

                Posté par  . Évalué à 4.

                Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 est ThinBright2, et Gtk+1.2 une variation de Funklor qui est en fait ThinBright2 pour Gtk+1.2.

                prenons le dialogue pour enregister un fichier. dés qu'on change de repertoire, pouf le nom du fichier disparait.
                Charmant, non ?


                Gnii? Peux-tu expliciter ? Là, je vais dans mon menu Galeon (1.2.6, et c'est pareil avec sylpheed), j'ai comments_reply,10264,147999,1.html (le nom de la page, donc), dans le buffer, et si je clique sur un répertoire, il va dans ce répertoire conserve bien le nom du fichier dans la zone de texte. Tout ça en Sid, donc Gtk+ 1.2.10. Bien entendu, il va sans dire que le comportement est le même avec Gtk+ 2. Donc, je vois pas.

                en plus, cette boite est graphique a souhait...

                Là, on est d'accord. http://developer.gnome.org/news/summary/2002_October20-October26.ht(...) pour plus d'informations.

                ensuite, que quelqu'un vienne me dire que c'est utile de mettre des kilometres de bordures autour des boutons...

                Euuh, là, je te suis pas. C'est peut-être lié à ton thème, remarque. Auquel cas ça n'a pas grand chose à voir avec Gtk+, donc bon..

                toujours dans la meme veine, le séparateur entre deux zones redimensionnables.
                le truc ou il y a une zone minuscule pour faire glisser le separateur ( je sais, ca depends du theme ). ben, c'est nulle. sous qt, tu clique n'importe ou sur la barre et c'est bon ca glisse.


                Bon, là, mon Sylpheed confirme effectivement que c'est vrai. Ceci dit, mon pan et mon gedit utilisant Gtk+2 me montrer que cela a été changé dans Gtk+2. Donc, il ne reste plus qu'à inciter les gens à passer leurs applications en Gtk+1.2. C'est sur la voie avec pas mal d'applis majeures, du genre Galeon.

                on peut cliquer sur les boutons au dessu des listes, masi il ne se apsse rien. pour alors autoriser le click ? c'est ce qu'on appelle un mauvais feedback. On a l'impression que ca fait quelque chose, masi ca fait rien. Et le bouton passe en surbrillance quand on passe dessus, donnait l'impression qu'une action est possible...

                Il s'agit d'une des erreurs de GtkCList. Ce widget est deprecated dans Gtk+2, mais encore utilisé par quelques applications qui en faisaient un usage intensif, et qui ne sont pas encore passées au nouveau widget, qui est incomparablement plus puissant, et considérablement mieux fait - mais peut-être un peu plus difficile d'accès. Bref, fixed.

                voila, tout cela n'existe pas dans qt.

                Si tu compares avec le dernier Qt, compare le dernier Gtk+. Et là, comme tu vois plus haut, ce que tu dis n'est plus valide.

                pour moi, tant que gtk aura ces problémes, qt sera mieux. ( pour moi )

                Parfait! Gtk+ est donc au moins aussi bien, là. (je ne joue qu'à ton propre jeu, en ne considérant pas le reste)
                • [^] # Re: Ca compile c'est déjà ça ...

                  Posté par  . Évalué à 2.

                  Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 est ThinBright2, et Gtk+1.2 une variation de Funklor qui est en fait ThinBright2 pour Gtk+1.2.

                  Hé béh, faut que je dorme. Je cherche encore la logique de la phrase. Donc, je disais: « Bon, je réponds rapidement, et je précise avant que j'utilise comme thème Gtk+2 ThinBright2, et comme thème Gtk+1.2 une variation de Funklor qui correspond à l'équivalent de ThinBright2 pour Gtk+1.2 (qui utilises tous deux le theme engine thinice, qui roxoraïze). » Voilà voilà. Comme quoi, jamais faire de comment avant 3h du matin, et sans la dose d'alcool requise.
                • [^] # Re: Ca compile c'est déjà ça ...

                  Posté par  (site web personnel) . Évalué à 2.

                  Je compare le gtk que j'avais sur ma mandrake 8.2, avec le qt que j'avais sur cette meme mandrake.

                  Effectivement, le probleme de la boite de dialogue n'existe plus sur la nouvelle version de Gtk. ( mandrake 9, que je vient d'installer ).

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

                  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.

                  Parfait! Gtk+ est donc au moins aussi bien, là. (je ne joue qu'à ton propre jeu, en ne considérant pas le reste)

                  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 ?
                  Ben oui, mais par défaut ce n'est pas le cas.

                  Un autre exemple , gaim.
                  la zone de texte est en fait un controle sur une ligne...
                  donc, fleche haut ne remonte pas...
                  C'est parce que le logiciel est mal fait ?
                  Qu'est ce qu'une zone de texte a une ligne si ce n'est un controle multiligne d'une seule ligne ?
                  Ca devrait etre plus cohérent au niveau de la bibli.
                  Peut etre, bien sur que c'est en cours...

                  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...
                  • [^] # Re: Ca compile c'est déjà ça ...

                    Posté par  . É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.
                    • [^] # Re: Ca compile c'est déjà ça ...

                      Posté par  (site web personnel) . Évalué à 2.

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

                      htpp://scherer.michael.free.fr/troll.png



                      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.

                      Mais les retours a la ligne mis par Konqueror n'apparaisse pas dans le post, non ?
                      J'ai bien une longue ligne insipide.

                      Peut etre que Gtk2 le fait.

                      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 ).
                      Comme j'imagine que ca doit etre reglé dans une nouvelle version de Gtk ou que ca n'arrive pas aux autres, est ce que je peut faire quelque chose d'autre que d'upgrader a nouveau ma machine et d'installer Gimp 1.3 pour remedier a ce probléme ....

                      Tu parle des gens qui utilisent des widgets non maintenus, mais, ca veut bien dire que les widgets d'avant étaient 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.


                      <TROLL_for_fun_and_profit>
                      Et tout de même, le C++, c'est quand meme mieux ;)
                      </TROLL>
                      • [^] # Re: Ca compile c'est déjà ça ...

                        Posté par  . É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+.
                        • [^] # Re: Ca compile c'est déjà ça ...

                          Posté par  (site web personnel) . Évalué à 1.

                          rien qui ne soit pas configurable, soit par l'application, soit par le thème, iirc. Donc.
                          Oui, je sais, j ai deja tente de mettre d'autres themes.
                          Aucun ne m'a convaincu, mais j ai pas fait une recherche tres pousse.
                          Le probleme, c est que c est le theme par defaut....

                          Je ne connait pas assez Gtk et le reste pour m'aventurer dans les sources :(
                          Mais bon, je vais essayer ca sur gaim.

                          Pour le fait que c etait pourri, j ai pe etait fort.

                          Si je suis pas clair, c est parce que je suis pas tres reveille.
                          J ai aussi besoin de sommeil ( a 16 h :( )

                          Donc, pour la molette, imagine ce que ca donnerai si elle tournai a l envers.
                          Et tu voit l'effet que j ai chez moi.

                          J imagine que c est un pb de config, mais je voit pas d ou ca vient...

                          Pour finir
                          Je n'ai pas sous la main les éléments de comparaison, mais, pour l'instant, tu ne fais qu'avancer sans prouver.
                          Ben, j helas autre chose a faire que de trouver une comparaison point par point de gtk et qt..

                          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+.
                          He bien, c est vrai que depuis longtemps, c'est vague.
                          Mais il y a encore deux jours, j avais des pb avec les applis gtk.
                          Pb que j avais pas avec les applis kde.
                          Ou du moins, pas depuis kde2.
                          Meme kde1 , dans mon lointain souvenir, n avait pas lerreur que j'avais encore avant hier sur gtk
                          Ok, c est pas la meme chose...

                          Pour l'exemple de la boite de dialogue, quelqu un a fait remarquer que ca fait quelques annees que ca dure...

                          Je ne vais pas reinstaller une vielle distribs juste pour dire :
                          voila du qt, voila du gtk, et ca, ca, ca et ca, ca va pas.

                          Mais merci tout de meme de me tenir au courant des progres de gtk.
                          Je m'en souviendrai dans 6 mois quand je me remettrais en question sur mes applis.
              • [^] # Re: Ca compile c'est déjà ça ...

                Posté par  . Évalué à 1.

                Pour info, moi, je suis toujours en Gtk1/Gnome1 parce que j'ai pas vraiment eu le temps d'upgrader, et que j'ai des craintes paranoiaques, du genre "mais est-ce que Gnome2 oblige à utiliser des fontes pourries, ou sont-ce juste 100% des screenshots de Gnome2 que j'ai vu qui sont pourris" (Je hais les fontes TrueType, ces horreurs illisibles qui ne devraient être autorisés que dans les programmes de dessins)

                Le coup de la boite: je suis completement d'accord, c'est un probleme *majeur* de Gtk. (Perso, ca fait plus de 4 ans que j'ai remplacé la boite par défaut par un package supposé le remplacer dont j'ai oublié la provenance, et j'ai plus ce probleme) Mais Gtk2 a corrigé ca.

                Quand à l'esthétique, Bordures et tout ca, je dis oui et non:
                Non car je n'ai pas du tout ce probleme. Oui car quand je vois les screenshots des autres, ils ont tous des boutons ENOOORMES, je sais pas pourquoi ils font ca. Note aussi qu'en plus du thème, la taille de la fonte qui est utilisée influence. Je ne saurais que trop recommander de banir les fontes 100dpi au profit des 75dpi dans toute l'interface.

                Le séparateur ? Avant que tu ne m'en parles, ca ne m'avait jamais interpelé. Maintenant que tu me le fais remarquer, je suis d'accord que cette "poignée" ne sert à rien.

                Le bouton sur les listes, je suis pas sur, mais je crois qu'il sert par exemple à choisir selon quel critère tu veux classer. C'est peut etre la faute du programmeur de l'appli qui aurait oublié de le desactiver ? (je me répete, je suis pas sur)

                Je suis d'accord que gtk est pas parfait, mais il a aussi pleins d'avantages sur Qt (menus détachables, raccourcis à la volée..)

                Par contre, Qt me gonfle bien plus niveau ergonomie:
                Dockables Windows: (ou peut-etre "mdi" - je pense à ce qu'on a dans QtDesigner) Ceci est une erreur de la nature. Sous MSWin, ca peut se comprendre vu qu'il n'y a quasiment pas de wm. Maintenant, sous des vraies environnements fenetrés, c'est hyper ennervant. Tu peux plus déplacer tes fenetres avec Alt, tu peux plus les shader. Et quand parfois le machin me laisse sortir certaines fenetres, je suis obligé de faire des gros hack sawfish pour pouvoir les utiliser (genre mettre des raccourcis "Force Normal Border" et "toggle ignored").
                Le focus est contre intutif (j'entends par là qu'il fait ce à quoi je m'attends pas). Parfois, quand je demande à une fenetre de se raiser, et bien il arrive que sa mère se raise. Parfois, quand je focus une fenetre, sa mère se raise (Comme dans Office quand il n'est pas en "look&feel = Xwindows" (btw, non, la faute à X Window n'est pas de moi - c'est dire à quel point eux aussi avaient windows en tête)). Je suis d'accord que le wm devrait théoriquement pouvoir empecher ce comportement, mais là, ca devient vraiment trop complexe. Bientot, il faudra mettre des "rules" (genre FireWall) dans son WM !

                Je veux pas spécialement troller, mais on sent que Qt a été pensé pour MSWin (normal, ca a été crée en 92 dans ce but) et simplement "porté" sous Linux, alors que Gtk a plus été pensé pour X

                (et oui, je suis un grand fan de TheGimp et de Sawfish ;)
                • [^] # Re: Ca compile c'est déjà ça ...

                  Posté par  . Évalué à 1.

                  "mais est-ce que Gnome2 oblige à utiliser des fontes pourries, ou sont-ce juste 100% des screenshots de Gnome2 que j'ai vu qui sont pourris

                  Je ne sais pas mais chez moi j'ai installé fontconfig (www.fontconfig.org) et le rendu est largement plus joli depuis. Ceci dit ça reste du truetype, donc si tu n'aimes pas...
                  • [^] # Re: Ca compile c'est déjà ça ...

                    Posté par  . Évalué à 1.

                    Oui, mais est-ce obligatoire ?
                    J'ai peur, parce que j'ai entrevue une RH8, et dans le selecteur de fontes (ces malades avaient mis une fonte TT avec AA dans les xterm - c'est illisible), il n'y avait ni le Times, ni l'Helvetica, ni le Courier. Alors était-ce une mauvaise config par défaut de RH8 qui a viré ces belles pcf 75dpi du fichier de config de xfs pour faire comme sous Windows (où les fontes sont horribles), ou un des nombreux délires de la nouvelle politique de Gnome2 (qui dit en gros que tout ce qui n'est pas comme sous windows c'est mal ressenti des utilisateurs)

                    C'est pas que "j'aime pas" le TrueType - je m'en sers avec TheGimp, mplayer, etc. - c'est juste que c'est pas prévu pour afficher des grandes quantité de textes sur un écran, et que, de part leur caractère vectoriel, ca requiert de l'AA (et l'AA, à longueur de journée, ca fatigue les yeux à cause du manque de netteté que ca crée). C'est un peu comme xdvi apres un latex: c'est beau, mais c'est juste un "preview" prévu en fait pour être imprimé(1).
                    D'ailleurs, je n'ai jamais trouvé de screenshot où les fontes étaient aussi belles que sur mon mozilla avec Times (75dpi/timR14.pcf.gz sur slashdot et helvR14.pcf.gz sur linuxfr, pour etre exact ;), meme sur les screenshots de freetype.org, gnome.org ou microsoft.com. Et le pire, c'est quand je lis un article sensé expliquer comment améliorer ses fontes en installant celles de MS, et qui illustre ca par d'horribles screenshots...

                    Bon, je m'emporte un peu, mais c'est parce que les choix des fontes que je vois autour de moi, ca me dépasse completement... L'autre jour, là où je bosse, y'a une meuf qui m'a sorti "le verdanna, c'est plus lisible que le Times" !! Ca m'a fait sauter au plafond... En fait, elle voulait dire ".. que le Times New Roman", une pale copie fournie avec MSWin, qui, effectivement, était illisible quand je suis allé voir...
                    Pour illustrer mes propos, j'ai cherché sur google image un exemple de Times et un exemple de Times New Roman. (J'ai eu du mal, et encore, c'est pas très flagrant là - sur un écran slashdot plein de texte, ca l'est bien plus)
                    Comparez donc la zone de texte sur
                    http://ilrt.org/discovery/2000/08/bized-meta/rdfwebcat.gif(...)
                    http://tarp.worldserve.net/linux/graphics/windowmaker.gif(...)

                    (1) C'est pour ca que je supporte que les fontes soient peu lisibles dans les Office.. mais certainement pas dans les webbrowsers !
                    • [^] # Re: Ca compile c'est déjà ça ...

                      Posté par  . Évalué à 1.

                      comme sous Windows (où les fontes sont horribles)

                      Je conçois que ce soit affaire de goûts, mais une majorité des gens trouvent les fontes au contraire très lisibles sous Win, donc on comprend que Gnome s'adapte au jugement dominant.

                      Note, je suis sous Mandrake, et l'anti-aliasing de Galeon et Mozilla par défaut sont ignobles. Par contre Phoenix avec fontconfig et les fontes MS installées rend extrêmement bien.

                      Et, heu, ben pour moi le Verdana est à peu près ce qu'on fait de plus lisible sur un écran en fontes proportionnelles.

                      Rien à voir, mais apparemment les votes sont revenus.
                    • [^] # Re: Ca compile c'est déjà ça ...

                      Posté par  . Évalué à 1.

                      Comparez donc la zone de texte sur
                      http://ilrt.org/discovery/2000/08/bized-meta/rd(...)
                      http://tarp.worldserve.net/linux/graphics/windo(...)


                      Pour moi, la première est la plus agréable. J'imagine que j'ai faux ;)
                      • [^] # Re: Ca compile c'est déjà ça ...

                        Posté par  . Évalué à 1.

                        Nan, tu n'as pas "faux". C'est juste affaire de gout, et la majorité des gens pensent comme toi en fait.. (et mes screenshots n'aident pas)
                        Moi, je préfere de très loin le deuxieme, surtout quand y'a des pages et des pages à lire..
                    • [^] # Re: Ca compile c'est déjà ça ...

                      Posté par  . Évalué à 1.

                      et l'AA, à longueur de journée, ca fatigue les yeux à cause du manque de netteté que ca crée).

                      Je suis dépuis quelques mois sous KDE 3 avec AA et je trouve que c'est assez agréable, je me disais au début que la côté légèrement flou allait me lasser, mais finalement ça va (en ce moment je suis avec Konqueror). Il faut dire que j'ai une très bonne carte graphique (G400 dont la pureté du signal est réputé) ainsi qu'un bon écran (Iiyama).

                      Comparez donc la zone de texte sur
                      http://ilrt.org/discovery/2000/08/bized-meta/rd(...)
                      http://tarp.worldserve.net/linux/graphics/windo(...)


                      Je vois ce que tu veux dire, je ne suis pas loin de penser comme toi, mais la taille des polices est légèrement différente (plus grande pour le 1er lien, côté Windows), et la capture écran côté Linux est mal faite (dithering) ce qui abaisse un peu la netteté.
                    • [^] # Re: Ca compile c'est déjà ça ...

                      Posté par  (site web personnel) . Évalué à 1.

                      > ces malades avaient mis une fonte TT avec AA dans les xterm - c'est illisible

                      c'est ce que j'utilise depuis quelques temps:
                      xterm -fg black -bg white -fa courier:size=18

                      c'est écrit super gros mais je trouve le rendu excellent :) je ne me lasse pas d'admirer mes xterm: http://hules.free.fr/xterm.png(...)
                      • [^] # Re: Ca compile c'est déjà ça ...

                        Posté par  . Évalué à 1.

                        xterm -fg black -bg white -fa courier:size=18

                        Super, je ne connaissais pas cette option "-fa", je me demandais justement si c'était possible d'avoir l'AA dans un xterm. Je viens d'essayer et je trouve bcp mieux la police "monospace", avec la courier même en grand j'ai des caractères pas très lisibles.

                        Par exemple ceci : xterm -fa monospace:size=11 donne pas mal chez moi, même si c'est petit.
                • [^] # Re: Ca compile c'est déjà ça ...

                  Posté par  (site web personnel) . Évalué à 1.

                  Bonne remarque concernant le MDI.
                  Mais, en fait des applis pur QT, y en a pas tant que ca sous linux.
                  ( enfin j'en utilise pas tant que ca )
                  Peut etre que si le MDI etait standardisé, genre dans http://www.freedesktop.org(...) ( je pense que c'est ca ), peut etre que les WM pourraient gerer ca correctement.

                  C'est vrai qu'un bon WM, c'est tout de suite plus propre que de faire gerer les applis par la fenetre.
                  Ca centralise le comportement...
              • [^] # Re: Ca compile c'est déjà ça ...

                Posté par  . Évalué à 1.

                on peut cliquer sur les boutons au dessu des listes, masi il ne se apsse rien. pour alors autoriser le click ?

                Parce que l'application peut définir des callbacks quand on clique sur ces boutons, par exemple pour trier la liste selon le contenu de la colonne. Pas mal d'applis le font. Pour les autres, il y a une fonction gtk qui permet de rendre les titres des colonnes passifs. Donc, la faute est l'appli, pas à gtk.
                • [^] # Re: Ca compile c'est déjà ça ...

                  Posté par  . Évalué à 1.

                  Et avec un GtkListView, ou GtkTreeView, c'est par défaut, et à ma connaissance peu d'applis se gourrent. Y'a juste le Tree store dans gtk-demo où ça devrait pas être comme ça, mais ça n'est heureusement pas le cas partout, rien que dans MrProject ça ne l'est pas. Ces widgets sont décidément un vrai bonheur.
                • [^] # Re: Ca compile c'est déjà ça ...

                  Posté par  (site web personnel) . Évalué à 2.

                  Oui, ok, on peut definir des callbacks.
                  Ce que j'aurais voulu, c'est qu'il n'y est rien si il n'y a pas de callbacks.
                  On croit qu'il y a quelque chose, alors qu'il n'y a rien.
                  Est ce si difficile de voir qu'il n'y a pas de callbacks, et d'agir en consequence ?
                  C'est a dire, de ne pas illuminer, pour qu on puisse distinguer la ou il y a un callback, et la ou il n'est pas. Comme dit plus haut, ca a ete reglé, mais, pendant au moins un an c'etait pas le cas.


                  Si la reponse, c'est que c'est au programmeur de tout gerer, on peut revenir a la prog XLib...

                  La ca peut que etre la faute du programmeur, vu que la bibli fait rien...

                  Mais bon, je ne peut pas vraiment raler, ca fait longtemps que je me plaint de ca , sans faire de bugreport....
          • [^] # Re: Ca compile c'est déjà ça ...

            Posté par  (site web personnel) . Évalué à 1.

            non non, pour pas de jaloux, ils n'ont qu'à utiliser gnustep : le port sous osx sera facile, et ça tournera sous nunux..
            En plus, ni KDE ni Gnome n'est privilégié... moins de prises aux trolls ! :)
            oui bon ok ... ==> [je sors] :)
            • [^] # Re: Ca compile c'est déjà ça ...

              Posté par  . Évalué à 1.

              Ils pourraient faire une architecture modulaire qui accepterais en plugin le widget à utilisé. Cela conviendrait à tout le monde. Licq fonctionne de cette manière, et c'est franchement sympathique de ne pas être obligé d'avoir à subir l'interface gnome sous kde et vice et versa :)
              • [^] # Re: Ca compile c'est déjà ça ...

                Posté par  (site web personnel) . Évalué à 1.

                le problème c'est que ça nécessite un boulot assez énorme, d'autant que les différents toolkits n'ont pas forcèment les mêmes principes de programmation ... c'est faisable sur un "petit" logiciel graphique comme licq, mais sur un mastodonte tel que OO, c'est perdu d'avance à mon avis.
              • [^] # Re: Ca compile c'est déjà ça ...

                Posté par  (site web personnel) . Évalué à 2.

                Je l'ai souvent repete, ce qu'il faut, c'est porté Qt par dessus gtk, comme on a porté qt sur windows..
                et pareil pour gtk.
                gtk porté par dessus qt.
                ca serait lourds, pe, mais, au moins, on aurait the gimp en qt ;)
                et konqueror en gtk....

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

                  Posté par  . Évalué à 0.

                  Pour moi le reve, ce serait d'avoir un truc fonctionnel (et libre, bien sur), en gtk ou qt, peu importe.

                  J'ai parlé de gtk+ puisqu'openoffice.org avait dit qu'il ferait cela. Maintenant, s'ils préférent se disperser avec d'autres toolkit graphiques pour des systèmes partiellement non-libre, j'avoue trouver ça moins sympathique.
                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 1.

                    Ce commentaire a été supprimé par l’équipe de modération.

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

                      Posté par  (site web personnel) . Évalué à 1.

                      Sauf erreur de ma part, il y a des biblis C++ pour gtk,donc, c'est pas une si grande aberration.

                      Le probleme, c'est pas l'interface et les menus, c'est le widget principal, c'est la grille de oocalc, le texte de owrite. C'est tout le concentré de l'interface, a mon avis.
                      Et ca, ca doit pas se porter facilement.
  • # Re: Ca compile c'est déjà ça ...

    Posté par  . Évalué à 3.

    Il y a aussi la partie francaise du projet qui cherche des volontaires: http://fr.openoffice.org/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.