tene a écrit 407 commentaires

Qu'est ce qui est inutilisable? Donne des détails s'il te plait (vu que j'ai pas de version de longhorn et qu'en dehors d'une version PDC peu avancée y'a pas encore eu grand chose officiellement).

D'un autre côté, soit tu l'as sur le serveur (et c'est en général plus ton prob...) soit tu devras bien à un moment donné charger qqch du mail pour déterminer si c'est un spam... et là tu dois choisir entre:

- un logiciel externe qui charge une fois tous les messages et vire le spam suivi d'un client mail qui charge les messages restants (et donc t'as chargé certains messages 2 fois)
- un filtre intégré: tu charges une fois chaque mail, le spam est trié.

Il est vrai cependant que parfois il est possible de détecter du spam sans charger tout le mail, mais bon POP3 ça pue bien niveau protocole pour ce genre de chose...

Malheureusement, c'est maintenant ... mais sous windows www.sourceforge.net/projects/myoe

J'attends que mono soit utilisable pour envisager une version nux (mais bon je pense qu'il existe déjà de très nombreux excellent client mail sous nunux...).

C'est exactement pour cela que l'on voit des "v1agra" et autre "vi/\gr/\"... mais en fait, cela dépend plus de l'algo qui parse le message, on pourrait imaginer un algo qui teste non pas l'équivalence mais la similitude des mots, ainsi que les "ascii art" représentant des lettres, ce que je fais pour le moment (et ça marche pas mal), c'est ... rien du tout. Je ne vire pas les tag HTML, ce qui fait que des mot du genre #FF0000 se retrouve avec une probabilité de spam assez élevé, et en fait c'est bien, de nombreux spam contiennent du texte en rouge, alors que les mails "normaux" en contiennent pratiquement jamais... De plus grâce à l'apprentissage, il apprend, soit tout seul, soit avec un peu d'aide les autres séries de lettres utilisées pour viagra. En fait c'est assez marrant de voir les probabilités associés au mot, c'est parfois très innatendu...

En fait mon filtre est modulaire (autant faire ma pub, c'est du GPL), un mail passe par chaque filtre antispam qui a la possibilité de répondre c'est surement du spam, c'est surement pas du spam, aucune idée ou une probabilité d'être du spam. Pour le moment, y'a un filtre qui renvoie une proba élevé de spam si on trouve une grande série de mot contenant plus de n consonnes consécutives (une autre technique pour passer outre un bayesian: rajouter plein de "mot" à la fin du spam, idéalement des mots inconnus qui auront donc une probabilité par défaut de ne pas être du spam), un filtre qui tente de parser l'header de spam assassin (pourquoi est-ce qu'ils font pas UN standard, un seul header, facile à parser mais qu'ils permettent de le configurer????) et un filtre bayesian, cela permet donc d'avoir un apprentissage un peu plus rapide: quand le bayesian est pas encore entrainé, il profite des deux autres, ensuite, il devient capable de répondre de façon pertinente... La suite de cette idée est d'arriver à pondérer l'importance de chaque filtre genre avec un petit réseau neuronal (parce que c'est marrant)... voilà assez de pub ;)

Qu'est-ce qu'un filtre bayesien exactement ?

En gros: chaque mot a une probabilité d'être un mot appartenant à un spam, cette probabilité est calculé grâce à ce que tu lui apprends (quand tu marques un messages comme spam). Quand un nouveau mail arrive, il calcule la somme pondéré des proba de chaque mot et si cette proba est supérieure à K, alors c'est un spam... il met alors à jour ses probabilités pour les mots du mails.

Intéret:
- Il apprend "tout seul", à partir d'un certains moment... imagine qu'il sache que viagra c'est du spam, les mails avec viagra sont du spam, ensuite tu reçois du spam pour trucmuche, le spam précise que ce n'est pas du viagra, comme le mot viagra est présent, le mail est un spam... il en profite alors pour apprendre le mot trucmuche comme étant probablement partie d'un spam... et si tu reçois du spam pour trucmuche (ne contenant plus le mot viagra), ça continue à fonctionner.
- Ca dépend du contenu du mail, pas d'une black list/white list.
- Les false positive sont assez rare
- Ca s'adapte à ton type de courrier indésirable (si tu es un fan de viagra, et que tu ne marques donc pas les mails sur le viagra comme spam, ce ne sera pas du spam, la plupart des autres méthodes vont te marquer le mail comme spam... mais bon faut être fan de ça aussi ;)

Défaut:
- Il faut qu'il apprenne, et ça peut être très long (c'est seulement à partir de qq centaines de mails que ça devient "correct").
- Comme toutes méthodes, ce n'est pas parfait, y'a parfois des erreurs. Ces erreurs auront tendance à se répéter (c'est pour ça que bcp ajoute une white list qui force un message comme non spam).
- Vu que ça dépend de l'utilisateur, difficile de l'appliquer à tous un serveur mail de façon réellement efficace.
- C'est assez lourd comme méthode, il faut parser le mail, splitter les mots, les mettre en forme, calculer leur proba, etc... c'est donc pas aussi rapide que "chercher le mot "sex" dans le sujet.

C'est effectivement pratique quand tu veux faire un outil vite fait ou pour montrer la "puissance" de ce genre d'outils et dire "Msdev c'est bien on developpe plus vite qu'avec emacs" mais de le cadre d'un vrai projet, generalement un simple editeur de texte + un outil de vesionning + une bonne doc remplissent les trois quarts des besoins.

Je ne suis pas d'accord sur ce point, dans tous les projets que j'ai vu et tout les projet auquel j'ai pris part (que ce soit professionnel ou loisir), un bon IDE est un outil très bénéfique...

Mais, je suis d'accord avec toi: dire msdev rulez je drop un activex en 4 click n'est pas l'argument convainquant (mais je parlais d'intégrer mozilla à une app, pas d'IDE, d'ailleurs sous windows, pratiquement tout les IDE permettent d'intégrer l'activex d'IE à une application... il ne s'agit donc pas de msdev uniquement). Cependant, quand on parle d'IDE, on parle de completion syntaxique (réelle selon les classes des projets en cours, etc...) de compilation réellement incrémentale, de debugging réellement intégré, de gestion des dépendances, de browsing de code, etc...

Les outils "classiques" (make, CVS, ...) montre d'ailleurs souvent leur limites : ils ont étés conçus pour être général (c'est leur force!), alors qu'en fait un outil dédié à un langage (ou une techno) est souvent beaucoup efficace (mais limité à ce langage/cette techno): regarde eclipse par exemple, c'est l'un des meilleurs IDE java existant... pourquoi? parce qu'il comprends le java, qu'il est réellement intégré, depuis l'aide à la saisie jusqu'au refactoring en passant par le debugging, etc... (quoi que perso, je trouve le debugging trop lent, mais bon...)

De plus si tu regardes la tendance, on se dirige petit à petit vers des outils avec certains aspect des outils case, encore une fois le fait que ce soit intégré fait la différence (je modifie ma classe, le diagramme est changé immédiatement, pas besoin de recompiler/recréer/modifier à la main, etc... je fais du vrai refactoring, pas de search/replace basé sur une regexp plus ou moins bien torchée). Et ce sont des domaines peu couvert pas les outils "classique"

Enfin, j'ajouterais quand même une note: je suis d'accord avec toi sur le fait que l'IDE ne soit pas tout (disons le quart des besoins restant ;), que trop de programmeur sachant faire click-click s'imagine être des gourous... un bon IDE a parfois le défaut de faire passer certaines choses pour trop simple et finalement génère plus de problèmes que de solutions (c'est le cas par exemple des form designer: pour une about box ou une boite d'option, c'est sympa, mais ça montre souvent ses limites sur des IHM complexes). Et si je dois choisir entre doc ou IDE, je préfère avoir de la doc, qu'un IDE permettant de jouer avec un framework non documenté... mais microsoft offre (tente d'offrir) les deux... je crois qu'il pourrait être intéressant d'y penser... (parce qu'en plus ça a en général bcp d'influence sur le framework...).

Il y a un controle COM gecko qui utilise la même interface (au sens programmation) que IE. Je crois même qu'il est installé avec Mozilla.

C'est mon prob: le controle COM que j'ai trouvé essaie de se substitué à IE, ce qu'un particulier peut faire ("je veux pas IE, tout moz!") mais qui n'est pas envisageable dans l'installation d'un logiciel (parce que c'est global).

De plus, l'un des avantages de se passer d'IE est de pouvoir éviter l'activex (qui n'est d'ailleurs absoluement pas portable), mais bon, visiblement mozilla n'a pas pour but de permettre ce genre d'utilisation... et je trouve cela dommage, mais surtout dangereux: microsoft fait du closed source (pas bien), mais offre une série de SDK qui vont bien pour utiliser leur techno (mieux, même si trop souvent, ils cachent certains détails)... j'aimerais voir plus cela dans le logiciel libre!

Enfin bref, si qq a une expérience quelconque dans un "embedded gecko", ça m'intéresse...

Y'a un détail qui me chipote: il me semble que le chtit détail qu'est l'IDE est oublié... amha c'est une des raisons qui explique la relativement faible utilisation de XUL... Microsoft nous promet un longhorn "de la mort qui tue" (et visiblement ils sont en train de se rendre compte qu'ils n'auront pas le temps de tout faire), mais un autre gros projet dont on parle beaucoup chez microsoft pour le moment, c'est Whidbey (alias Visual Studio .NET 2005)... Qu'est ce qu'on a (aura) côté logiciel libre?

Microsoft a toujours sorti sa série: techno/outil de dev/documentation de façon relativement cohérente... du côté de mozilla c'est moins évident: on a une techno très valable, supérieur à ce que ms offre sur de nombreux points (ouverture, respect des standards, etc...), côté outil de dev, c'est déjà moins évident et niveau documentation, ça dépend énormément des sujets... (comment par exemple, dans une application Windows intégré un contrôle d'affichage HTML utilisant gecko? avec IE c'est 4 clicks dans l'IDE qui va bien, avec mozilla, je cherche toujours un moyen déployable...).

Amha l'IDE (et les outils de dev en général) est un facteur déterminant, ce n'est pas tout d'avoir la possibilité technique de réaliser telle ou telle chose, il faut aussi avoir l'outil qui va bien...

Il faut aussi tenir compte du fait que longhorn est un OS complet pas seulement XAML, et visiblement d'après le blabla (relativement marketing) de microsoft, y'aura beaucoup d'autres choses: certaines sont nécessaire pour que XAML tourne bien (DCE par exemple), d'autre permettre de faire de XAML un technologie interdépendante avec le reste (WinFS, Indigo, ...).

En bref, je rêve du jour ou y'aura un bon IDE pour toutes ces technologies...

D'un autre côté, si tu tentes d'afficher la page avec IE, y'a des merdes avec les "tableaux" enfin ce qui apparait comme des tableaux. Heureusement qu'il y'a la version PDF pour les fans d'IE, surtout que le doc est intéressant.

Tiens question bête au passage: le user-agent de konqueror c'est quoi? (le test de browser est: UA contient "gecko" ou "safari", sinon on jette).

Seconde question bête: le XML c'est bien, mais si je veux avoir le source de la page HTML généré par mozilla (et non pas le XML source), y'a un moyen simple?

"http://www.eu.microsoft.com/france/exchange/evaluez/temoignages/inf(...)"

puisqu'il est possible de le lier avec une base de données externe et libre, comme mysql par ex... C'est ptet ça qui le gene, le meusieur.

En combien d'étape? De quel outil graphique je dispose pour éditer ma base de donnée? comment cet outil est-il intégrer à OO.org? Comment je fais pour t'envoyer la base de donnée?

Et alors? on peut même faire du PDF directement à l'aide d'un bloc-note quelconque... Quand je parle de QuarkXPress c'est parce que le PDF contient cette information, on trouve:

QuarkXPress(tm) 4.11
Acrobat Distiller 4.05 for Macintosh

Alors à moins que le PDF soit forgé pour faire croire que ça a été fait sous mac sans outil microsoft... (je vois pas l'intéret) c'est bien du QuarkXPress et sous mac (en plus).

Ensuite, Word (ou OO.org Writer) n'est pas vraiment l'outil permettant de faire le genre de mise-en-page que l'on trouve dans le "document" (qui ressemble plus à une pub qu'un article). Je sais pas vous, mais moi quand j'ai à faire ce genre de truc, je prend ni Word, ni OO.org Writer...

Pourquoi jouer à celui qui pisse le plus loin?

De la part d'une boite commerciale trouver un document vantant son produit, c'est si extraordinaire? Faut-il forcément répondre à ce genre de document de la même façon?

Pourquoi la plupart des arguments sont du types "mouhéé OpenOffice le fait aussi" ou du genre "OO.org le fait pas mais de toute façon ça sert à rien"?

Cependant, ce doc est intéressant, ça montre comment microsoft va vendre son produit, quel est la réponse d'OO.org? En terme de fonctionnalité réelle? (notemment niveau base de donnée client et groupware?).

ps: c'est du PDF, et c'est fait avec QuarkXPress, vous faites ce genre de document avec quoi vous?

Au risque de te peiner, oui, je sais situer différents états.

Pourquoi me peiner? Tant mieux pour toi, j'ai du mal à en citer 20 et à en situer correctement 10... mais bon, je fais pas partie de l'"intellentsia";)

Tu sais dans le même d'ordre d'idée, quand je vais en vacances en France, j'ai droit à des propos du genre:

- Vous parlez bien français pour un belge
- Quel est la capitale de la Belgique encore?
- Certains "cultivés" sont au courant de l'existance de la flandre et de la wallonie... il me demande si la guerre civile n'est pas trop difficile... (véridique en plus).
- Et le président de la Belgique...?
- ...

Et je te parle pas des amalgames frites et blague belge ;). Enfin d'un autre côté, je m'étais une fois engueuler avec un serveur dans un café et me suis fait traiter de français moyen, plutôt drôle, ptêt je suis pas assez "belch" ;).

Pourtant je ne pense pas que ça fait de la France un pays dont l'inteligentsia (ça veut dire quoi exactement...) est peu nombreuse, ou les gens sont essentiellement ruraux (avec la notion péjorative que tu y ajoutes).

ps: tu sais situer les différents états des USA toi? ;)

Je comprends pas bien: Application, tu dois sous entendre plusieurs process (sinon corba n'a pas de sens), et donc me dire que c'est rare d'avoir des process programmé à l'aide de langage différent, je suis pas trop... Ton explication semble être: tout faire en corba c'est pas top. D'accord, tout d'abord c'est impossible (ce n'est qu'un orb!), ensuite et surtout ce n'est pas le cas.

Oui, donc c'est bien ce que je disais, MDI a poussé le C par calcul "politique"/marketing plus que par choix technique. Je trouve ça dommage, pour le moins.

Dans l'absolu, oui. En étant réaliste: c'est inévitable, l'histoire de compromis à nouveau...

ps: tu connaissais Miguel De Icaza avant Gnome? moi pas.

Le point important, c'est surtout qu'il n'y a aucun intérêt à se faire suer avec le modèle lourd de Corba dans la quasi-totalité des cas; se forcer à l'utiliser est alors sacrèment contre-productif selon mon point de vue !! c'est bien pour ça que la solution de KDE de passer par une archi légère est efficace; et c'est bien pour ça que OpenStep avant eux le proposait. Franchement, entre me faire suer à définir un IDL et simplement écrire 2 lignes de plus pour indiquer que j'utilise un objet qui en fait tourne sur une machine à 800 km de là, ben, je sais pas pourquoi, mais je préfère écrire deux lignes.

Je comprends ton point de vue, je suis d'accord, tu devrais aimer .NET ;) mais surtout: rapport avec Corba, COM, java remoting, whatever? Je n'ai jamais fait de corba en C (et heureusement), en java et en C++, c'est plutôt simple à mettre en oeuvre (une fois que t'as le naming service, si y'a un truc qui me bourre en corba c'est bien ça)..

En fait j'ai l'impression que ton argument est plus: pq les langage n'offre pas plus de facilité? on est d'accord.

Là ou je suis moins d'accord c'est sur le fait de pouvoir utiliser un composant depuis n'importe quel langage: en local c'est déjà assez courant (regarde le nombre de binding c++, python, perl, php, whatever qu'il existe pour des lib c... alors qu'avec un format "standard" on pourrait s'en passer). Mais une fois en remoting, c'est capital il me semble: tu ne peux pas contraindre tout tes projets à être en objective-C! Ce langage est sous doute adapté à certaines choses, mais le sera moins à d'autre, particulièrement en tenant compte de l'existant.

Accessoirement, l'utopie sur la transparence ou la couche réseau parfaite... heu... de toute façon le problème est identique avec Corba, non?

Oui, mais tu te situes un peu plus pas niveau, on te présente pas corba comme "ça marche juste, y'a rien à faire, c'est magique".

Pour le reste, c'est soit des répétions, soit de la mauvaise fois (tu ne connais ni C# ni .NET mais c'est pas une bonne idée...), juste pour rajouter: "En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ..."

A sa place: objective C, non, trop peu connu, communauté trop "faible". C++: rappelle toi les début de KDE, les difficulté du compilo, le nombre moins important de de développeur et le fait qu'ils se soient basés sur Qt une libre existante comme une base de leur framework (qu'ils ont du changer quelques fois). Le C était à l'époque le langage à la mode, connu de bcp de gens, ... Et tu le dis toi même: tu n'aimes pas le C++, et moi je l'aime bien, parce qu'on peut faire d'affreuse bidouille en C++ (ce qui est exactement ce que je ne voudrais pas dans un projet que je dois maintenir).

Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)

Qu'est-ce que tu entends par "supporter les attributs" ??

Supporter les attributes classique (lecture, écriture, type, ...) mais également d'autre (définissable par le développeur) sur les variables, classes, type, ... en bref, un concept que je n'ai vraiment vu développé que depuis .NET et qui permet de faire pas mal de choses de façon assez élégante.

Tout ça pour en venir au fait que .NET possède cela... en particulier le C#. Ce n'est sans doute pas le seule, mais comme langage normalisé, c'est le seul que je connaisse.

bye bye corba

Et donc byebye le support de plusieurs langage... ?... De plus ton explication est amha trop simpliste: l'utopie de la transparence, l'utopie d'avoir une couche réseau parfaite, etc...

C'est marrant en fait, cette aversion à corba, on la retrouve dans le monde windows sous forme d'aversion à COM: beuarkk... si c'est COM, c'est lent, c'est lourd, etc... et pourtant DirectX est basé sur COM (et est loin d'être lent). La raison de cette peur est simple: COM est souvent assimilé à OLE et ActiveX qui eut sont relativement lourd.

Alors bon, MDI aurait mieux fait de venir aider GNUstep à l'époque que de se lancer dans de la programmation objet... en C (vraiment, je trouve ça inexplicable).

Je ne connais pas assez GNUstep, de loin je sais que certaines idées sont séduisantes (ça fait partie de ces trucs que je me jure de regarder plus à fond quand j'aurai le temps;). Mais perso, je trouve pas cela aussi inexplicable, ou plutôt je trouve pas cela inexplicable quand on voit le nombre de personne qui veulent encore utilisé le C...

En fait, y'a un truc qui me trouble quand je lis l'ensemble des commentaires (ça ne s'adresse donc pas spécialement à toi... mais bon, j'arrive pas à dormir, tout ça, alors faut bien que je radote)... bref, y'a un truc qui me trouble:
En dehors des troll^Wcommentaires sur la mémoire consommée par XP/AmigaOS et le reste du monde (totalement idiot, hors sujet, ...) énormément de commentaires sont du types: ouhhéééoohhéoh, il fait chier MDI, il a choisi de la merde, d'ailleurs X ou Y aurait été bien mieux... ça veut dire quoi: vous êtes meilleurs que MDI? MDI est nul? Ca me trouble, je suis développeur depuis un moment, assez que pour savoir qu'une grande partie des décisions à prendre en terme de dev sont posés sous la forme de compromis... et dans la plupart des décisions de MDI je vois des compromis... Cela ne veut pas dire que j'aurais forcément fait les mêmes choix que lui, mais je peux comprendre qu'il ait fait ces choix là... suis je le seul?

Le choix du C++ pour faire un truc comme QT ou GTK+ est aussi complètement stupide vu que le langage ne support pas les attributs ou les signaux nativement.

D'accord, à ce propos, quel langage normalisé existe-t-il, supportant les attributes et les signaux?...

C'est ISO maintenant, une premère étape pour te faire accepter en tant que norme ISO est souvent de passer par l'ECMA.

Ca existait avant sous linux : xul, qt, glade,... proposent tous des langages XML de description d'interface

Regarde ce qu'est XAML, ce n'est pas que cela... ça n'a rien de révolutionnaire sans doute, mais ça pousse le concept bcp plus loin.

Un format maintenu par une seule société (MS ou pas ce n'est pas le problème si ce format n'est pas ouvert) ce n'est pas bon à mon avis.

Il ne s'agit plus de cela, il s'agit d'une norme ISO. Cela signifie entre autre que si ms veut changer le format du jour au lendemain, il ne peut plus le faire, il doit soumettre cela à l'ISO.

Mais au fait, qu'est ce qu'un format ouvert? Un logiciel libre, j'ai compris, un format documenté, j'ai compris, une norme aussi, mais un "format ouvert", c'est quoi la différence?

Je ne dis pas que XAML ou C# sont nuls (car ça m'étonnerait) mais la dépendance vis à vis de MS c'est dangereux.

Pq serait-il dépendant de MS?

MS a pondu un truc intéressant (au moins pour certaines personnes) et coup de bol, pour une raison X (dont on se tape), ils en font une norme ISO... donc on peut l'implémenter, cool...

Cela ne te rend pas dépendant de ms pour autant...

Toi tu pars du scénario: ouhé mais si méchant ms arrête son truc rien que pour faire chier... et ben oui, et alors? il se passe quoi? mono continue à tourner, s'il est valable, il est utilisé, et jusqu'à preuve du contraire il est toujours libre... il peut toujours évolué. Tu as l'air de considérer que le but est de faire un .NET sous linux pour pouvoir faire tourner des applis windows, je ne crois pas que ce soit le but, le raisonnement est plutôt: .NET c'est sympa, y'a des concepts intéressant, implémentons ces concepts sous linux. Et comme c'est une norme ISO, on va faire du "standard".

Ben non. Ce sera compilé.

Amha, c'est là tout son intéret...

XAML ne sera utilisé que comme équivalent aux fichiers de ressources de VC++

Justement non... Les fichier resource de windows (ça dépend de windows, pas de VC), qui ont étés oublié du monde .NET, était lourdingues, très très limité (en dehors des controles de bases, tout était usercontrol), le positionnement des controles était inexistant (en dehors de la position absolue). Mais ce n'est, amha, pas là le point important: que ce soit resource (.res) ou fichier XML, ou fichier ce que tu veux: tu continues à ne faire que décrire ton IHM.

XAML tente d'aller plus loin que cela: tu décris également son comportement et le databindings.Et c'est pour cela que c'est, amha, intéressant que ce soit compilé: un fichier XAML et un source C# (ou tout autre langage .NET) une fois compilé forme une et une seule classe! Je te laisse imagine la facilité que cela apporte au niveau de l'échange de donnée entre GUI et code. (compare avec XUL par exemple).

Pour l'instant, je ne vois pas cela comme une révolution... mais comme un de ces "petits trucs" qui font gagner du temps... (dans le même ordre d'idée que le foreach, les generics, les events, les delegates, la completion de code, etc...).

Tiens puisque t'en parles, tu penses sérieusement que mono est prêt pour un environnement de prod? Il est clair que si l'on veut développer en .NET sous windows, c'est possible, et ça tient même bien la route... mais tu baserais déjà un développement linux sur .NET toi? Selon quel critère? parce que moi je vois juste un projet qui avance relativement bien, mais qui est loin d'être stable et rapide... (ça avance relativement vite cependant...).

Et perso, la portabilité, ça me fait toujours marrer: dans le meilleurs des cas on arrive à faire un programme avec pas trop de #define. Dans presque tous les cas au moins une des deux plate-forme y perd largement (ex: GTK sous windows vraiment pas top, swing lent aussi bien sous linux que sous windows, etc...). Sans oublier les éternels problèmes qui surviennent alors qu'en "théorie ça fonctionne"©®... bref tout ça pour rappeller que le développement à l'aveugle qui produit du code portable c'est une illusion. (et que ceux qui doute de cela teste un déploiement java sur macos, linux et windows... ;).

Le systeme doit pouvoir fonctionner au moins Mac / Windows / linux, portable veut dire PORTABLE. Je veux dire, etre sur de ne laiser personne, sinon j'aurais fait du VB lol.

Alors oublie tout ce qui est natif (à moins que tu aies bcp bcp de temps à consacrer à cela), reste java, et encore bonne chance sous mac...

Perso, j'ai tendance à écrire un client par OS.