non mais il suffit d'aller demander sur #ubuntu-fr par exemple pour s'en rendre compte... Swing est lent et mal intégréEnvoyé par robert_trudel
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
non mais il suffit d'aller demander sur #ubuntu-fr par exemple pour s'en rendre compte... Swing est lent et mal intégré
Pour ma part, je trouve paradoxale cette attitude qui consiste à faire du C# sous linux. Pas vous ?
pourquoi?
Je pense plutôt que c'est la migration d'un programme C++/GTK vers C#/GTK# qui est plus "simple" que la migration vers du Java/Swing, car on reste sur la même librairie graphique.
Car au niveau de l'intégration avec le LnF système de Swing on utile justement les widget GTK pour le rendu...
a++
http://fr.wikipedia.org/wiki/C_sharp :
Dans mon esprit, le C# est étroitement associé à Microsoft. De même que bon nombre d'utilisateurs Linux ne sont pas des pro-Microsoft. D'où le paradoxe que j'y vois. Et à titre perso, si je choissisai Linux comme OS, je ne choisirai pas le C# comme langage de dev.Le C# est, d’une certaine manière, le langage de programmation qui reflète le mieux l’architecture Microsoft .NET qui fait fonctionner toutes les applications .NET, et en est par conséquent extrêmement dépendant.
Comprenez moi bien pour éviter les trolls. D'une part, c'est un point de vue purement subjectif. D'autre part, je sais bien que tous les utilisateurs de Linux ne sont pas des anti Microsoft. Qu'on peut aimer leur produit de dev (A quand un visual studio sous linux ?) sans aimer leur OS. Que Mono est une solution pour faire tourner des programmes C# sous linux. Et enfin, que parfois, on a pas le choix (professionnellement) et qu'il faut bien des solutions pour faire de l'interopérabilité.
bon, en plus dire que mono est adopté sous linux, c'est quand meme exagéré. il y a quelques programmes (souvent poussés par novel) qui ont été codés en mono, et en général, tres mal recu par la communauté qui les a reportés/réécrits en autre chose.
au final, a l'heure actuelle, un linux desktop sans mono fonctionne sans soucis
Non,
Swing charge les ressources de GTK, mais ce sont pas de "vrais" widgets GTK, c'est pour ça qu'on peut parfois avoir un résultat assez inattendu quand on utilise certains thèmes
Il me semble avoir lu que les différences de performance de swing suivant les plate-formes viendraient justement en partie de son incapacité à utiliser les composants natifs suivant le type de widget concerné, composants qu'il dessine alors lui même sans avoir recours à l'OS (si on peut dire ça comme ça).
Dans le mien c'est la même chose que java est à sun. Je sais pas si cela à changé, mais dans mes souvenirs, les appli java sous linux c'est assez souvent bancale.Dans mon esprit, le C# est étroitement associé à Microsoft.
Pourtant, ils ont énormément changé de stratégie et ne sont plus vraiment fermé. C# est normalisé et les spec du CLR sont disponible librement.De même que bon nombre d'utilisateurs Linux ne sont pas des pro-Microsoft.
Je veut juste dire que c'est dommage de penser (je parle en générale, je ne vise personne) que ".net et C# c'est le mal parce crosoft".
En fait pas du tout. Swing dessine tout. C'est le fondement même de ce toolkit. Ensuite pour obtenir le L&F natif il s'appuie sur les API proposées par les OS/DE hôtes avec plus ou moins de réussite. Typiquement sous windows Swing passe par l'UXTheme.dll pour générer des images offscreen de composants Windows et ensuite les découper et les utiliser pour dessiner les composants Swing. Pour GTK Swing va tapper dans les ressources dédier aux thèmes (du XML couplé à des images si je me souviens bien), pour Mac j'en sais fichtre rien vu que c'est de la tambouille interne à Apple en Cocoa. C'est le fondement même de l'archi de Swing qui permet en particulier d'offrir un set de composant pouvant être utilisés sous n'importe quel OS sans forcément que le composant existe de lui même au niveau natif (par exemple on trouve des implémentations de taskpanes en Swing qui sont plutôt des bestioles Windows dans l'âme tournant sous tous types d'OS, de même il existe un Ribbon pour Swing qui marche partout alors que logiquement ...).
De fait les L&F natifs pourront s'avérer plus lents par conception qu'un look & feel léger auy niveau opérations de dessin et mémoire comme métal (bon d'accord métal c'est moche) ou les L&F JGoodies.
Maintenant à l'heure actuelle Swing tourne plus ou moins correctement, satisfait à certains besoin mais pas à tous. Bref, Swing fait partie des solutions multi plateformes viables. Bon bien sur si on cherche de l'intégration parfaite mieux vaut chercher ailleurs.
Soit dit en passant l'intégration des appli en GTK# sous KDE est tout aussi mauvaise celle de Swing. Donc mono ne couvre absolument pas tout l'écosystème Linux au niveau des DE.
Sauf tout ce qui est fenêtres et frames tout de même, non?
L'os ne fournit que la surface de dessin, surface de dessin pouvant être au choix une JFrame, un JDialog ou une JWindow.
Sachant toutefois que les barres de titre sont fournies par l'OS (enfin tant que le développeur ne les désactive pas pour faire les siennes à sa sauce).
Perso, je n'ai rien contre microsoft (enfin, pas plus que les autres).
Et si je devais faire du C#, je le ferai certainement dans un environnement window.
.NET est étroitement lié à Microsoft.
C#, c'est juste un langage parmi d'autres. C'est juste une syntaxe particulière pour représenter diverses choses. Mais c'est pas spécifiquement lié à Windows, aux services de Windows (active directory, etc...), ni à Microsoft, du coup... En dehors du fait, évidemment, que c'est microsoft qui développe ce langage.
Microsoft se fout royalement que ce soit C# ou un autre langage à condition que ce soit sur du .NET.
Les langages n'ont plus de valeur Business, ils sont devenus gratuits, tout porte sur la vente des outils et surtout demain .NET et la JVM vont devenir de véritables OS.
Le vrai enjeu pour dans 10 ans c'est le cloud computing qui va consister à vendre la consommation mensuelle d'infrastructure comme de l'électricité ce qu'ils appellent la "commoditisation" de l'IT (terme qui vient des marchés boursiers). Cela va avoir des conséquences sur le métier de programmeurs, les gens ne le voient pas encore, quand ils le verront, cela risque d'être douleureux.
Dans quelle mesure cela va impacter notre métier ?
dans quel application?
il suffit de demander a des utilisateurs de firefox ou openoffice pour dire que le C++ c'est lent
ou bien à bush qu'il y a des armes a destruction massive en irak...
ça date du 03/09/2002, et ça discute toujours
Il faudra penser à sortir le champagne pour les 10 ans de ce thread un de ces jours (03/09/2012, un peu avant la fin du monde)
Sinon, sérieusement, si j'utilise un langage de haut niveau, c'est parce que je n'ai pas envie de me casser la tête à résoudre des problèmes de bas niveau ^^
Je pense que je gagne plus de temps à optimiser l'architecture générale de mon projet, plutôt que d'optimiser les "petits" détails.
Et si j'ai choisi Java, par rapport à .Net, c'est parce qu'il est potentiellement portable, même si je reste sous windows.
Je l'ai déjà dit quelque part ici mais je ne sais plus où depuis. Donc je reformule: en 1997/1998 le PDG de SUN Mac Nelly a déclaré dans un magazine français pour fabricant de matériel que son objectif (avec Java et tous les logiciels gratuits qu'ils donnent) est de transformer le secteur IT en secteur Télécom où les gens paieraient un abonnement mensuel comme le téléphone donc. Il a dit que la conséquence c'est qu'il n'y aura plus de prestations de services logiciels car il n'y en pas dans le modèle télécom. Il a dit qu'il allait créer la déflation dans le secteur logiciel qui entraînerait la fin des sociétés de service (il a cité en exemple SEMA GROUP l'équivalent de notre cap gemini aux US) pour que le logiciel vaille 0 pour que les investissements aillent sur le secteur matériel et non plus logiciel.Dans quelle mesure cela va impacter notre métier ?
20 ans après, voilà donc son rêve amorcé: le cloud computing. Ce concept commence seulement à être implémenté par les gros à commencer par Amazon puis Google et le grand dernier Microsoft. Il y a une étude qui est sorti aux US qui prédit que dans 10 ans le cloud va devenir un choix crédible et que les emplois seront essentiellement des emplois de Helpdesk puisqu'il n'y aura plus besoin de développer. C'est ça la conséquence. Remarquez qu'il se sera écoulé 30 ans entre la stratégie de Mac Nelly et la réalisation.
Bien sûr dire qu'il y aura zéro développement sera certainement exagéré mais ce sera la grosse tendance, seuls les très bons continueront sans doute à être développeurs chez quelques éditeurs plus ou moins gros.
Bof. Le cloud computing c'est un nouveau mot pour désigner quelque chose qui existe déjà depuis longtemps : L'infogérance.
En un mot, au lieu de vendre un logiciel à un client qui devra ensuite maintenir une infrastructure technique pour l'utiliser, tu lui vends un accès à une plateforme préinstallée avec tes logiciels prêts à l'emploi.
Le client n'achète plus une licence logicielle mais un service en location : le droit de se connecter à un outil pour réaliser sa production. Il n'a alors plus besoin de gérer lui-même une infrastructure de production conséquente.
Ca fait des années que mon employeur offre ce service (on a notre propre plateforme de cloud privé). Ca simplifie considérablement la maintenance (ça plait pas mal au client aussi, il faut bien le dire).
Mais il n'y a pas de miracle : Il faut bien que quelqu'un développe les applications que tu mets dans les nuages...
Si on considère que l'immense majorité des développements informatiques sont des développements spécifiques et pas du progiciel. Le cloud a un bel avenir, mais il ne faut pas croire que le reste va disparaitre.
Par contre, pour en revenir qu'en même au sujet de la discussion. Là où le cloud risque d'impacter les développements (et surtout le langage de dev), c'est que les plateformes de cloud facturent l'hébergement à la consommation de ressource et pas de façon forfaitaire.
Sur Windows Azure, tu paies à l'heure de fonctionnement de chaque machine virtuelle (on en n'est pas encore à la facture CPU mais ça pourrait venir), tu paies au nombre de requêtes qui entrent et sortent du nuage, tu paies à la consommation de bande passante...
Donc les développements devront s'orienter vers l'optimisation des ressources. Il ne sera plus question de dire : "avec la puissance des machines actuelles, les perfs ce n'est plus un problème" puisque cette fois, on paiera directement la puissance consommée.
Donc a mon avis, les langages et les architectures sur-consommateurs de ressources vont prendre une claque.
Ajoutez à celà que la portabilité aura beaucoup moins d'intérêt puisque l'infrastructure des clients n'aura plus d'importance... Il suffira que les applis tournent sur la plateforme de cloud...
JAVA et PHP risquent d'avoir la vie dure.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager