J'ai développé une application Windows tirant parti du .NET Framework qui
fournit une interface utilisateur rassemblant au sein de la meme application
tout un ensemble de différents composants tels que des pages Web, des
fichiers Flash, des fichiers vidéos des stream vidéos... Pour faire tout
cela j´ai utilisé les différents controles ActiveX fournis par Microsoft,
Macromédia et consorts qui permettent d´intégrer tous ces composants au sein
d´une appli Windows en quelques clicks de souris.
Une des directions que prends le projet maintenant que la première version
est terminée est le portage de cette appli sous Linux / Unix / Mac OS X (oui
je sais, cela aurai du être planifié plus tot mais je n´y peux rien en
l´occurence...).
N´ayant aucune expérience de la programmation d´applis pour ces systèmes, je
me demandait s´il y existait une technologie équivalente pour intégrer des
pages web, fichiers flash... au sein d´une appli. J´ai comme l´impression
que si nous devons porter notre appli sous ces systèmes, il va falloir tout
faire "à la main". Y aura t il quelqu´un pour me rassurer?
Quand à la portabilité de Java, qu´en pense-tu ? Sur les forum .NET, certain avancent que dans certains cas, c´est plus du pipeau qu´autre chose... Je n´ai jamais fais de grosse appli Java, je me suis arreté à quelques bibliothèques utilisant JMF qui fonctionnaient bien partout mais je serais intérressé par d´autres avis.
Là je ne peux donner que mon expérience en tant qu'utilisateur. J'ai téléchargé il y a longtemps le logiciel jPicEdt. Sur la page du logiciel, MacOS X n'était mentionné nulle part.
J'ai téléchargé quand même. J'ai double-cliqué et ça s'est ouvert. Tout marchait.
Personnellement, je trouve cela très impressionnant question portabilité.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Elp <rockfamily@hotmail.com> wrote:
Quand à la portabilité de Java, qu´en pense-tu ? Sur les forum .NET, certain
avancent que dans certains cas, c´est plus du pipeau qu´autre chose... Je
n´ai jamais fais de grosse appli Java, je me suis arreté à quelques
bibliothèques utilisant JMF qui fonctionnaient bien partout mais je serais
intérressé par d´autres avis.
Là je ne peux donner que mon expérience en tant qu'utilisateur.
J'ai téléchargé il y a longtemps le logiciel jPicEdt. Sur la page du
logiciel, MacOS X n'était mentionné nulle part.
J'ai téléchargé quand même. J'ai double-cliqué et ça s'est ouvert. Tout
marchait.
Personnellement, je trouve cela très impressionnant question
portabilité.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Quand à la portabilité de Java, qu´en pense-tu ? Sur les forum .NET, certain avancent que dans certains cas, c´est plus du pipeau qu´autre chose... Je n´ai jamais fais de grosse appli Java, je me suis arreté à quelques bibliothèques utilisant JMF qui fonctionnaient bien partout mais je serais intérressé par d´autres avis.
Là je ne peux donner que mon expérience en tant qu'utilisateur. J'ai téléchargé il y a longtemps le logiciel jPicEdt. Sur la page du logiciel, MacOS X n'était mentionné nulle part.
J'ai téléchargé quand même. J'ai double-cliqué et ça s'est ouvert. Tout marchait.
Personnellement, je trouve cela très impressionnant question portabilité.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Schmurtz
Elp wrote:
"Schmurtz" wrote in message
page web : le WebKit (on peut créer un objet WebKit de façon similaire aux ActiveX)
J´ai regardé ça et effectivement, ça à l´air pas mal. Mais Mac OS only malheureusment.
Comme les ActiveX sont Windows only
Macromedia Director ??? Je pensais que c´était pour faire du multimédia ça? Y a moyen de faire une vrai appli avec?
C'est surtout utilisé pour créer des applications à fort contenu multimédia (ce qui semble être ton cas : vidéo, flash) sur pas mal de CD plus ou moins éducatifs. Je ne confirmerai pas entièrement, ne connaissant pas vraiment les capacités de cet environnement, mais une chose est sûre : ça créer des vraies applications.
Tu peux toujours faire un tour sur le site web de Macromédia, il y a une démo téléchargeable de Director.
-- Schmurtz
Elp wrote:
"Schmurtz" <moi@ici.com> wrote in message
page web : le WebKit (on peut créer un objet WebKit de façon similaire
aux ActiveX)
J´ai regardé ça et effectivement, ça à l´air pas mal. Mais Mac OS only
malheureusment.
Comme les ActiveX sont Windows only
Macromedia Director ??? Je pensais que c´était pour faire du multimédia ça?
Y a moyen de faire une vrai appli avec?
C'est surtout utilisé pour créer des applications à fort contenu
multimédia (ce qui semble être ton cas : vidéo, flash) sur pas mal de
CD plus ou moins éducatifs. Je ne confirmerai pas entièrement, ne
connaissant pas vraiment les capacités de cet environnement, mais une
chose est sûre : ça créer des vraies applications.
Tu peux toujours faire un tour sur le site web de Macromédia, il y a une
démo téléchargeable de Director.
page web : le WebKit (on peut créer un objet WebKit de façon similaire aux ActiveX)
J´ai regardé ça et effectivement, ça à l´air pas mal. Mais Mac OS only malheureusment.
Comme les ActiveX sont Windows only
Macromedia Director ??? Je pensais que c´était pour faire du multimédia ça? Y a moyen de faire une vrai appli avec?
C'est surtout utilisé pour créer des applications à fort contenu multimédia (ce qui semble être ton cas : vidéo, flash) sur pas mal de CD plus ou moins éducatifs. Je ne confirmerai pas entièrement, ne connaissant pas vraiment les capacités de cet environnement, mais une chose est sûre : ça créer des vraies applications.
Tu peux toujours faire un tour sur le site web de Macromédia, il y a une démo téléchargeable de Director.
-- Schmurtz
pmanet
Elp wrote:
Y aura t il quelqu´un pour me rassurer?
il me semble établi que .NET a été developpé par MS pour privatiser le web et couper l'herbe sous le pied des technologies multiplateformes. Si on s'en sert, il faut donc s'attendre à devoir tout refaire ensuite... -- Philippe Manet
Elp <rockfamily@hotmail.com> wrote:
Y aura t il quelqu´un pour me rassurer?
il me semble établi que .NET a été developpé par MS pour privatiser le
web et couper l'herbe sous le pied des technologies multiplateformes.
Si on s'en sert, il faut donc s'attendre à devoir tout refaire
ensuite...
--
Philippe Manet
pmanet@invivo.edu
il me semble établi que .NET a été developpé par MS pour privatiser le web et couper l'herbe sous le pied des technologies multiplateformes. Si on s'en sert, il faut donc s'attendre à devoir tout refaire ensuite... -- Philippe Manet
Elp
"manet" wrote in message news:200406050031511250180@[10.0.0.1]...
Elp wrote:
Y aura t il quelqu´un pour me rassurer?
il me semble établi que .NET a été developpé par MS pour privatiser le web et couper l'herbe sous le pied des technologies multiplateformes.
"Privatiser le Web" ? "couper l'herbe sous le pied des technologies multiplateformes". Pourquoi ça ?
.NET permet de développer des application, pour l´instant uniquement Windows, tout comme le permettent VB, C++ et ses MFC sous Windows, Delphi....NET a ses avantages et ses inconvénients comme tous les autres framework. Certaines applis sont plus simples/rapides à développer avec .NET qu´elles ne le seraient avec un autre framework, tandis que d´autres gagnent à etre développées avec d´autres outils. Rien n´a vraiment changé. Dans le futur, .NET sera plus intimement lié à Windows ce qui permettra d´élargir le champ d´applications pouvant tirer parti de cet environement, et alors ? Ceux voulant développer une appli multi-plateforme ne s´intéressent pas à .NET pour l´instant et utilisent d´autres outils tels que Java. .NET n´a rien changé ici.
Certains tentent de porter .NET sur d´autres plateformes (cf le projet mono) ce qui n´est pas un mal et je ne vois pas trop en quoi cela va couper l´herbe sous le pied de qui ou quoique ce soit. Au "pire" cela va fournir à terme une alternative à Java et chacun sera à même d´évaluer quel environement corresponds le mieux à ses besoins.
L´histoire de la privatisation du Web est le projet palladium de Microsoft, qui, il faut bien le reconnaitre, fout les boules et est bizarement sous-médiatisé. Cela dit, ce projet va largement au dela de .NET.
Si on s'en sert, il faut donc s'attendre à devoir tout refaire ensuite...
Pas si l´appli est destinée à fonctionner sous Windows uniquement. Ce qui était l´objectif initial de mon projet. Si je me retrouve dans le merdier actuel, ce n´est pas la faute à .NET mais à la gestion, disons hasardeuse, de ce projet. J´aurai développé avec ce bon vieux C++ et des MFC de partout que le problème eu été le même. Si j´avais eu à développé cette appli originalement sous Mac OS X et utilisé Cocoa, le Webkit, quicktime etc... je me serai retrouvé dans le même situation si j´avais du, après coup, porter l´appli sous Windows/Linux. Cela voudrait-il dire que Cocoa soit mal ?
"manet" <pmanet@invivo.edu> wrote in message
news:200406050031511250180@[10.0.0.1]...
Elp <rockfamily@hotmail.com> wrote:
Y aura t il quelqu´un pour me rassurer?
il me semble établi que .NET a été developpé par MS pour privatiser le
web et couper l'herbe sous le pied des technologies multiplateformes.
"Privatiser le Web" ? "couper l'herbe sous le pied des technologies
multiplateformes". Pourquoi ça ?
.NET permet de développer des application, pour l´instant uniquement
Windows, tout comme le permettent VB, C++ et ses MFC sous Windows,
Delphi....NET a ses avantages et ses inconvénients comme tous les autres
framework. Certaines applis sont plus simples/rapides à développer avec .NET
qu´elles ne le seraient avec un autre framework, tandis que d´autres gagnent
à etre développées avec d´autres outils. Rien n´a vraiment changé. Dans le
futur, .NET sera plus intimement lié à Windows ce qui permettra d´élargir le
champ d´applications pouvant tirer parti de cet environement, et alors ?
Ceux voulant développer une appli multi-plateforme ne s´intéressent pas à
.NET pour l´instant et utilisent d´autres outils tels que Java. .NET n´a
rien changé ici.
Certains tentent de porter .NET sur d´autres plateformes (cf le projet mono)
ce qui n´est pas un mal et je ne vois pas trop en quoi cela va couper
l´herbe sous le pied de qui ou quoique ce soit. Au "pire" cela va fournir à
terme une alternative à Java et chacun sera à même d´évaluer quel
environement corresponds le mieux à ses besoins.
L´histoire de la privatisation du Web est le projet palladium de Microsoft,
qui, il faut bien le reconnaitre, fout les boules et est bizarement
sous-médiatisé. Cela dit, ce projet va largement au dela de .NET.
Si on s'en sert, il faut donc s'attendre à devoir tout refaire
ensuite...
Pas si l´appli est destinée à fonctionner sous Windows uniquement. Ce qui
était l´objectif initial de mon projet. Si je me retrouve dans le merdier
actuel, ce n´est pas la faute à .NET mais à la gestion, disons hasardeuse,
de ce projet. J´aurai développé avec ce bon vieux C++ et des MFC de partout
que le problème eu été le même. Si j´avais eu à développé cette appli
originalement sous Mac OS X et utilisé Cocoa, le Webkit, quicktime etc... je
me serai retrouvé dans le même situation si j´avais du, après coup, porter
l´appli sous Windows/Linux. Cela voudrait-il dire que Cocoa soit mal ?
"manet" wrote in message news:200406050031511250180@[10.0.0.1]...
Elp wrote:
Y aura t il quelqu´un pour me rassurer?
il me semble établi que .NET a été developpé par MS pour privatiser le web et couper l'herbe sous le pied des technologies multiplateformes.
"Privatiser le Web" ? "couper l'herbe sous le pied des technologies multiplateformes". Pourquoi ça ?
.NET permet de développer des application, pour l´instant uniquement Windows, tout comme le permettent VB, C++ et ses MFC sous Windows, Delphi....NET a ses avantages et ses inconvénients comme tous les autres framework. Certaines applis sont plus simples/rapides à développer avec .NET qu´elles ne le seraient avec un autre framework, tandis que d´autres gagnent à etre développées avec d´autres outils. Rien n´a vraiment changé. Dans le futur, .NET sera plus intimement lié à Windows ce qui permettra d´élargir le champ d´applications pouvant tirer parti de cet environement, et alors ? Ceux voulant développer une appli multi-plateforme ne s´intéressent pas à .NET pour l´instant et utilisent d´autres outils tels que Java. .NET n´a rien changé ici.
Certains tentent de porter .NET sur d´autres plateformes (cf le projet mono) ce qui n´est pas un mal et je ne vois pas trop en quoi cela va couper l´herbe sous le pied de qui ou quoique ce soit. Au "pire" cela va fournir à terme une alternative à Java et chacun sera à même d´évaluer quel environement corresponds le mieux à ses besoins.
L´histoire de la privatisation du Web est le projet palladium de Microsoft, qui, il faut bien le reconnaitre, fout les boules et est bizarement sous-médiatisé. Cela dit, ce projet va largement au dela de .NET.
Si on s'en sert, il faut donc s'attendre à devoir tout refaire ensuite...
Pas si l´appli est destinée à fonctionner sous Windows uniquement. Ce qui était l´objectif initial de mon projet. Si je me retrouve dans le merdier actuel, ce n´est pas la faute à .NET mais à la gestion, disons hasardeuse, de ce projet. J´aurai développé avec ce bon vieux C++ et des MFC de partout que le problème eu été le même. Si j´avais eu à développé cette appli originalement sous Mac OS X et utilisé Cocoa, le Webkit, quicktime etc... je me serai retrouvé dans le même situation si j´avais du, après coup, porter l´appli sous Windows/Linux. Cela voudrait-il dire que Cocoa soit mal ?
pmanet
Elp wrote:
"Privatiser le Web" ? "couper l'herbe sous le pied des technologies multiplateformes". Pourquoi ça ?
.NET permet de développer des application, pour l´instant uniquement Windows,
ben voilà, tu viens de te répondre.
J'ai un système de communication avec le ministère qui est censé s'appliquer à tout le monde, et qui est en .Net ; résultat, il faut absolument une machine sous Windows pour s'y connecter. Et on est donc marié à vie avec Windows, puisque je doute qu'ils refassent le develloppement.
-- Philippe Manet
Elp <rockfamily@hotmail.com> wrote:
"Privatiser le Web" ? "couper l'herbe sous le pied des technologies
multiplateformes". Pourquoi ça ?
.NET permet de développer des application, pour l´instant uniquement
Windows,
ben voilà, tu viens de te répondre.
J'ai un système de communication avec le ministère qui est censé
s'appliquer à tout le monde, et qui est en .Net ; résultat, il faut
absolument une machine sous Windows pour s'y connecter. Et on est donc
marié à vie avec Windows, puisque je doute qu'ils refassent le
develloppement.
"Privatiser le Web" ? "couper l'herbe sous le pied des technologies multiplateformes". Pourquoi ça ?
.NET permet de développer des application, pour l´instant uniquement Windows,
ben voilà, tu viens de te répondre.
J'ai un système de communication avec le ministère qui est censé s'appliquer à tout le monde, et qui est en .Net ; résultat, il faut absolument une machine sous Windows pour s'y connecter. Et on est donc marié à vie avec Windows, puisque je doute qu'ils refassent le develloppement.
-- Philippe Manet
Anonyme
Elp wrote:
Si j´avais eu à développé cette appli originalement sous Mac OS X et utilisé Cocoa, le Webkit, quicktime etc... je me serai retrouvé dans le même situation si j´avais du, après coup, porter l´appli sous Windows/Linux.
Tu aurais été moins emmerdé pour deux raisons... La philosophie Cocoa t'incite à bien découper ton code, et les trucs à changer sont donc bien ciblés et ne sont en général pas les trucs compliqués.
Pour avoir porté sur Mac du code Windows utilisant les MFC (je ne connais pas .NET), j'ai bien vu qu'il était presque impossible de découper correctement son code en utilisant les MFC, et que donc, le portage sur d'autres plateformes en est d'autant plus compliqué.
De plus, tu as le projet GNUStep qui essaie de se maintenir à niveau avec Cocoa, et GNUStep est dispo sous Unix/Linux et il me semble qu'une version Windows est également disponible... Et même si GNUStep n'est pas entièrement compatible Cocoa, les modifications sont du coup beaucoup moins importantes...
Si j´avais eu à développé cette appli
originalement sous Mac OS X et utilisé Cocoa, le Webkit, quicktime etc... je
me serai retrouvé dans le même situation si j´avais du, après coup, porter
l´appli sous Windows/Linux.
Tu aurais été moins emmerdé pour deux raisons... La philosophie Cocoa
t'incite à bien découper ton code, et les trucs à changer sont donc bien
ciblés et ne sont en général pas les trucs compliqués.
Pour avoir porté sur Mac du code Windows utilisant les MFC (je ne
connais pas .NET), j'ai bien vu qu'il était presque impossible de
découper correctement son code en utilisant les MFC, et que donc, le
portage sur d'autres plateformes en est d'autant plus compliqué.
De plus, tu as le projet GNUStep qui essaie de se maintenir à niveau
avec Cocoa, et GNUStep est dispo sous Unix/Linux et il me semble qu'une
version Windows est également disponible...
Et même si GNUStep n'est pas entièrement compatible Cocoa, les
modifications sont du coup beaucoup moins importantes...
Si j´avais eu à développé cette appli originalement sous Mac OS X et utilisé Cocoa, le Webkit, quicktime etc... je me serai retrouvé dans le même situation si j´avais du, après coup, porter l´appli sous Windows/Linux.
Tu aurais été moins emmerdé pour deux raisons... La philosophie Cocoa t'incite à bien découper ton code, et les trucs à changer sont donc bien ciblés et ne sont en général pas les trucs compliqués.
Pour avoir porté sur Mac du code Windows utilisant les MFC (je ne connais pas .NET), j'ai bien vu qu'il était presque impossible de découper correctement son code en utilisant les MFC, et que donc, le portage sur d'autres plateformes en est d'autant plus compliqué.
De plus, tu as le projet GNUStep qui essaie de se maintenir à niveau avec Cocoa, et GNUStep est dispo sous Unix/Linux et il me semble qu'une version Windows est également disponible... Et même si GNUStep n'est pas entièrement compatible Cocoa, les modifications sont du coup beaucoup moins importantes...
"manet" wrote in message news:2004060510061391086@[10.0.0.1]...
J'ai un système de communication avec le ministère qui est censé s'appliquer à tout le monde, et qui est en .Net ; résultat, il faut absolument une machine sous Windows pour s'y connecter. Et on est donc marié à vie avec Windows, puisque je doute qu'ils refassent le develloppement.
Pour communiquer, .NET offre, comme la plupart des autres outils, plusieurs solutions y compris les sockets de base (à toi de faire ton protocole de communication), les services Web (tout ce qu´il y a de plus standard) et .NET Remoting (.NEt only). Je suppose que dans ce cas, ils ont choisis .NET remoting. .NET leur offrait la possiblilité de faire le travail avec une solution respectant les standards et pouvant communiquer sans problème avec, par exemple, une appli Java. Et microsoft communique d´ailleurs à fond (un peu trop à mon gout) là dessus et ne parle jamais de .NET Remoting. Le chef de projet au ministère a choisis la solution non standard. Qui faut-il blamer ?
Je ne cherche pas à dire que .NET est parfait (ce qu´il n´est pas et tout le monde s´accorde à le dire) ni même que .NET est meilleur qu´autre chose. Mais c´est parfois fatiguant de retrouver constamment les même idées reçues. Que je parle de .NET à un non-.NET ou des Macs à un PCiste, c´est toujours les mêmes rengaines...
"manet" <pmanet@invivo.edu> wrote in message
news:2004060510061391086@[10.0.0.1]...
J'ai un système de communication avec le ministère qui est censé
s'appliquer à tout le monde, et qui est en .Net ; résultat, il faut
absolument une machine sous Windows pour s'y connecter. Et on est donc
marié à vie avec Windows, puisque je doute qu'ils refassent le
develloppement.
Pour communiquer, .NET offre, comme la plupart des autres outils, plusieurs
solutions y compris les sockets de base (à toi de faire ton protocole de
communication), les services Web (tout ce qu´il y a de plus standard) et
.NET Remoting (.NEt only). Je suppose que dans ce cas, ils ont choisis .NET
remoting. .NET leur offrait la possiblilité de faire le travail avec une
solution respectant les standards et pouvant communiquer sans problème avec,
par exemple, une appli Java. Et microsoft communique d´ailleurs à fond (un
peu trop à mon gout) là dessus et ne parle jamais de .NET Remoting. Le chef
de projet au ministère a choisis la solution non standard. Qui faut-il
blamer ?
Je ne cherche pas à dire que .NET est parfait (ce qu´il n´est pas et tout le
monde s´accorde à le dire) ni même que .NET est meilleur qu´autre chose.
Mais c´est parfois fatiguant de retrouver constamment les même idées reçues.
Que je parle de .NET à un non-.NET ou des Macs à un PCiste, c´est toujours
les mêmes rengaines...
"manet" wrote in message news:2004060510061391086@[10.0.0.1]...
J'ai un système de communication avec le ministère qui est censé s'appliquer à tout le monde, et qui est en .Net ; résultat, il faut absolument une machine sous Windows pour s'y connecter. Et on est donc marié à vie avec Windows, puisque je doute qu'ils refassent le develloppement.
Pour communiquer, .NET offre, comme la plupart des autres outils, plusieurs solutions y compris les sockets de base (à toi de faire ton protocole de communication), les services Web (tout ce qu´il y a de plus standard) et .NET Remoting (.NEt only). Je suppose que dans ce cas, ils ont choisis .NET remoting. .NET leur offrait la possiblilité de faire le travail avec une solution respectant les standards et pouvant communiquer sans problème avec, par exemple, une appli Java. Et microsoft communique d´ailleurs à fond (un peu trop à mon gout) là dessus et ne parle jamais de .NET Remoting. Le chef de projet au ministère a choisis la solution non standard. Qui faut-il blamer ?
Je ne cherche pas à dire que .NET est parfait (ce qu´il n´est pas et tout le monde s´accorde à le dire) ni même que .NET est meilleur qu´autre chose. Mais c´est parfois fatiguant de retrouver constamment les même idées reçues. Que je parle de .NET à un non-.NET ou des Macs à un PCiste, c´est toujours les mêmes rengaines...
Hubert Figuiere
Elp wrote:
Y aura t il quelqu´un pour me rassurer?
il me semble établi que .NET a été developpé par MS pour privatiser le web et couper l'herbe sous le pied des technologies multiplateformes.
Non. .Net a été développé pour tuer Java. .Net repose sur 2 parties qui sont normalisée ECMA, à savoir C#, et CLI (la "machine virtuelle" pour C#), alors que Java resté propriétaire Sun.
Il y a du reste 2 projets *libres* de réimplémentation de .Net, dont Mono, le plus avancé, supporté par Novell, et qui tourne sur Win, Linux x86 et PPC, et MacOS X (et aussi Solaris et divers UNIX, plus ou moins bien). http://www.go-mono.com/
Maintenant, je passe sur les histoires de brevets qui pourraient entâcher .Net, car l'histoire est loin d'être résolue et claire.
il me semble établi que .NET a été developpé par MS pour privatiser le
web et couper l'herbe sous le pied des technologies multiplateformes.
Non. .Net a été développé pour tuer Java. .Net repose sur 2 parties
qui sont normalisée ECMA, à savoir C#, et CLI (la "machine virtuelle"
pour C#), alors que Java resté propriétaire Sun.
Il y a du reste 2 projets *libres* de réimplémentation de .Net, dont
Mono, le plus avancé, supporté par Novell, et qui tourne sur Win,
Linux x86 et PPC, et MacOS X (et aussi Solaris et divers UNIX, plus ou
moins bien).
http://www.go-mono.com/
Maintenant, je passe sur les histoires de brevets qui pourraient
entâcher .Net, car l'histoire est loin d'être résolue et claire.
il me semble établi que .NET a été developpé par MS pour privatiser le web et couper l'herbe sous le pied des technologies multiplateformes.
Non. .Net a été développé pour tuer Java. .Net repose sur 2 parties qui sont normalisée ECMA, à savoir C#, et CLI (la "machine virtuelle" pour C#), alors que Java resté propriétaire Sun.
Il y a du reste 2 projets *libres* de réimplémentation de .Net, dont Mono, le plus avancé, supporté par Novell, et qui tourne sur Win, Linux x86 et PPC, et MacOS X (et aussi Solaris et divers UNIX, plus ou moins bien). http://www.go-mono.com/
Maintenant, je passe sur les histoires de brevets qui pourraient entâcher .Net, car l'histoire est loin d'être résolue et claire.
Merci pour les réponses. J´ai reguardé rapidement le WebKit et effectivement, cela pourrai résoudre quelque uns de nos problèmes. Par contre, ça ne marchera pas pour Flash car nous ne nous contentons pas d´afficher un fichier Flash mais l´appli doit passer des valeurs au fichier Flash et le fichier Flash envoie des évenements à l´appli pour qu´elle soit au courant de ce qu´il se passe. ça va etre difficile a faire avec le Webkit.
C'est clair. Mais s'il y a pas de SDK Flash pour Mac (j'ai pas la réponse, je suis même pas allé voir), vous bloqués. Et je parle même pas d'UNIX. Flash reste propriétaire [1].
Hub
[1] même si la doc est là, la compatibilité Flash des animations repose énormément sur le comportement des algorithme, comportement qui lui n'est pas du tout documenté. -- GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3
Merci pour les réponses. J´ai reguardé rapidement le WebKit et
effectivement, cela pourrai résoudre quelque uns de nos problèmes. Par
contre, ça ne marchera pas pour Flash car nous ne nous contentons pas
d´afficher un fichier Flash mais l´appli doit passer des valeurs au fichier
Flash et le fichier Flash envoie des évenements à l´appli pour qu´elle soit
au courant de ce qu´il se passe. ça va etre difficile a faire avec le
Webkit.
C'est clair. Mais s'il y a pas de SDK Flash pour Mac (j'ai pas la
réponse, je suis même pas allé voir), vous bloqués. Et je parle même
pas d'UNIX. Flash reste propriétaire [1].
Hub
[1] même si la doc est là, la compatibilité Flash des animations
repose énormément sur le comportement des algorithme, comportement qui
lui n'est pas du tout documenté.
--
GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3
Merci pour les réponses. J´ai reguardé rapidement le WebKit et effectivement, cela pourrai résoudre quelque uns de nos problèmes. Par contre, ça ne marchera pas pour Flash car nous ne nous contentons pas d´afficher un fichier Flash mais l´appli doit passer des valeurs au fichier Flash et le fichier Flash envoie des évenements à l´appli pour qu´elle soit au courant de ce qu´il se passe. ça va etre difficile a faire avec le Webkit.
C'est clair. Mais s'il y a pas de SDK Flash pour Mac (j'ai pas la réponse, je suis même pas allé voir), vous bloqués. Et je parle même pas d'UNIX. Flash reste propriétaire [1].
Hub
[1] même si la doc est là, la compatibilité Flash des animations repose énormément sur le comportement des algorithme, comportement qui lui n'est pas du tout documenté. -- GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3
lucsky
Elp wrote:
ça va etre difficile a faire avec le Webkit.
Foutaises. Passer des paramètres à un movie Flash depuis une page HTML et envoyer des paramètres à une page HTML/Javascript depuis un movie Flash est, dans une certaine mesure, tout à fait trivial et 100% portable, et cela bien sur sans passer par des grosses merdes Microsofteuse type ActiveX et compagnie.
-- Luc Heinrich -
Elp <rockfamily@hotmail.com> wrote:
ça va etre difficile a faire avec le Webkit.
Foutaises. Passer des paramètres à un movie Flash depuis une page HTML
et envoyer des paramètres à une page HTML/Javascript depuis un movie
Flash est, dans une certaine mesure, tout à fait trivial et 100%
portable, et cela bien sur sans passer par des grosses merdes
Microsofteuse type ActiveX et compagnie.
Foutaises. Passer des paramètres à un movie Flash depuis une page HTML et envoyer des paramètres à une page HTML/Javascript depuis un movie Flash est, dans une certaine mesure, tout à fait trivial et 100% portable, et cela bien sur sans passer par des grosses merdes Microsofteuse type ActiveX et compagnie.
