Folco (./26) :
"Nan mais les gars, faut utiliser les fonctions de windows.h pour vos menus de jeux en gris, c'est built-in et ça respecte le look&feel natif de la plateforme voyons" ~(c).

C'est menus.h.

C'est pas pareil sur PC/Mac ?

Qt respecte le look&feel de la plateforme, GTK+ fait de son mieux pour ça aussi (mais pour OS X, il faut utiliser le portage Cocoa, qui du coup va mal aller avec le KDE 3 utilisant X11 nécessaire pour le support de DCOP dans TiEmu qui est nécessaire pour KTIGCC 1 - bref, il vaut mieux utiliser du X11 partout en attendant au moins KTIGCC 2).

Et l'argument de la place n'est pas aussi important sur un ordinateur, ce n'est pas une calculatrice, les ordinateurs ont d'énormes disques durs.

kim (./28) :
je n'ai pas internet.

Il est là le problème, pas la peine de chercher plus loin.

Qui n'est d'ailleurs pas hébergé sur le même serveur que le tien, si ? Et qu'est-ce qu'il se passe si, ho, juste comme ça, le serveur de l'appli manquante, tombe en rade, ou simplement, n'existe plus ?

On me le signale et je pointe l'installeur sur un autre miroir.

Mais c'est clair que c'est mieux sous Fedora, où les dépendances sont dans le dépôt central et si le miroir tombe en panne, yum utilisera automatiquement le prochain. Pourquoi OS X n'est-il pas capable de marcher de cette manière? OS X est clairement technologiquement inférieur.

Il te manque quoi concrètement ? C'est marrant comme toute discussion avec toi semble toujours tourner à une confrontation là où on ne te demande pas de chercher à comprendre, mais de simplifier les choses quand c'est possible... Il te manque quoi sous osx, que tu as sous windows par exemple ?

Il me manque, sous OS X autant que sous W32, des libs multiplateforme préinstallées et/ou disponibles dans un dépôt central et installées automatiquement (en présupposant Internet, évidemment - ça fait partie de la configuration minimum de nos jours!) quand on installe un logiciel les utilisant, genre GTK+, Qt, kdelibs, libusb etc. Et W32 sux sur ce point autant que OS X. C'est GNU/Linux la plateforme idéale!

Si tu voulais du vrai multiplateforme, tu aurais utilisé java

Et ce n'était pas libre à l'époque où KTIGCC a été écrit (et il me semble que IcedTea ne compile toujours pas sous OS X, d'ailleurs), donc pas un choix possible.
Et puis Swing est pénible et lent, et si j'utilise Qt Jambi, ça ne va pas arranger les choses.

ou le moteur derrière firefox (dont le nom m'échappe, faut pas m'en vouloir, il est tard).

XUL. Mais il n'est pas du tout fait pour ça.

Ou .net, tiens...

Et les WinForms ne sont que mal gérés sous Mono, et si j'utilise du Mono avec du GTK# ou du Kimono/Qyoto (les bindings KDE et Qt pour le C#), ça ne va rien changer par rapport à la situation actuelle.

Il se trouve que pour pas mal d'éléments d'osx, il existe des alternatives.... Qui tourne même sous linux, par exemple

Mais aucunes ne répondent aux demandes.

C'est le rôle du packageur de fournir la solution.

Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux.

Si je te dis qu'une solution est possible avec un simple pkg, c'est qu'il y en a. X11 par exemple, va t'installer, ô surprise, des .so dans /usr/lib (de mémoire, pour le répertoire), de la conf dans /etc/X11..., fou non ? Et il se trouve même que OpenOffice.org en version 2 était même capable de la même "prouesse" à une époque. Il savait quand X11 était là ou pas, donc il bloquait l'installation.

Résolution des dépendances automatique = installer automatiquement X11. Si ce n'est pas possible à cause de la licence de l'implémentation de X11, c'est encore un point sur lequel OS X sux.

Au premier lancement, il allait chercher sagement les fonts systèmes dont il avait besoin, etc. Rien n'est impossible, c'est le boulot du dev & du packageur de fournir une solution.

Non, c'est le rôle de l'OS. L'OS ne le fait pas, donc il sux. GNU/Linux le fait très bien.

Il existe même des systèmes de packages qui gèrent les dépendances etc.

Fink? Ça a déjà été cité, je sais bien que ça existe, relis mon post en entier.

Tiens, un truc qui peut t'intéresser (ou pas), vu que tu ne connais pas *du tout* le monde mac : cherche i-installer par exemple...

->

i-Installer is unsupported software as of Jan 1, 2007.
[snip]
Bug reports can still be sent to me, but you will not get a reaction and it is uncertain if and when I will be paying attention to them. If it is something that does work for me (and thus something with your particular setup, I will most likely not pay any attention to them).
[snip]
i-Installer code is not particularly good. This is the result of the fact that it has been written as a pilot-project-gone-awry in combination with the fact that certain aspects of the environment (Mac OS X) played foul with my original architecture ideas (it just did not work at that time). Mac OS X has improved since, but i-Installer would have to be rewritten to benefit. That is only going to happen if I win the lottery and do not have to work for al living anymore...

Pas très prometteur, ce truc.

que dire. Un logiciel ne pourra jamais être aussi bon qu'avec des libs natives.

Alors vas-y, code-nous un EDI équivalent à KTIGCC, avec la même interface et tout, utilisant Cocoa.
Je n'ai jamais dit que ce n'était pas bienvenu (même si ça ne sera certainement pas l'EDI officiel étant donné que je ne peux pas le maintenir et que mon but est d'avoir le même code partout, ce qui se rapproche enfin de la réalité grâce à KDE 4).

Ca vaut pour macos, tout autant que pour linux (firefox sur kde, c'est un peu un contre sens d'une certaine manière, par exemple), et sous windows (gtk/kde sous windows). Et si l'application est pensée pour le multiplateforme dès le départ, changer de toolkit (de gtk à kde à autre) devrait être un jeu d'enfant.

C'est un mythe, ça. Romain a essayé le multi-frontend pour TiLP, il a laissé tomber parce que ce n'était pas maintenable, donc c'est repassé à GTK+ partout.

Note qu'il me semble qu'on n'a *jamais* parlé des makefiles des projets individuels... On n'a jamais causé d'utilisateurs qui vont aller jouer avec as dans leur makefile.Juste que tu déconseilles une personne voulant faire un IDE par dessus tigcc, d'utiliser les mêmes méthodes que ktigcc par exemple, c'est à dire, passer par gcc, as, ld-tigcc etc. Et je trouve que cet avis est pour moi une erreur. Il n'y a aucune raison pour qu'un tel IDE n'ait pas à le faire, si les specs/docs sont là, et sont claires, maintenues..., alors à chaque changement, il suffit de reporter les modifs qui vont bien. Encore une fois, c'est le rôle du mainteneur...

Une fois de plus, si l'EDI utilise ces trucs, ça passe encore tant que l'EDI est mis à jour si TIGCC change (mais c'est le rôle du mainteneur de l'EDI de se rendre compte de ces changements, pas le mien). C'est dans les makefiles perso que ça me dérange. Mais utiliser tigcc est plus sûr même pour les EDIs.

Tu sais, Gimp, sous mac, n'a jamais percé, pour plusieurs raisons :
* il lui faut X11. (ca a été longtemps un frein pour OpenOffice.org), meme si ça s'installe avec le dvd fourni avec l'os...
* il lui faut gtk, qui n'est pas natif, et qui ne s'integre pas à mac os.
* il est long à charger, parce qu'il n'utilise pas du natif (pareil pour OOo)* les packageurs de gimp n'ont je crois jamais compris que créer un framework, ou simplement, faire un pkg qui installe un bout en sys, et le reste sur l'app, leur permettait de proposer des package standalone en meme temps que des packages d'upgrade...

Ben, si vous ne voulez pas d'une application portable, c'est votre problème, mais alors ne venez pas râler qu'il n'y a soi-disant pas de version Mac, il y en a une, mais vous ne la voulez pas.