Je reformule : sporadique en % de terme de marché.
J'ai jamais vu de Linux Desktop exploité en entreprise, je ne dis pas qu'il n'y en a pas, mais j'ai vu pas mal de PME en roulant ma bosse.
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
Discussion :
Je reformule : sporadique en % de terme de marché.
J'ai jamais vu de Linux Desktop exploité en entreprise, je ne dis pas qu'il n'y en a pas, mais j'ai vu pas mal de PME en roulant ma bosse.
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
Je n'ai jamais dit que Win32 ou Windows était mieux. Je dis juste que y a un besoin non ou mal remplit sous Linux. Point. Je ne vois pas en quoi Win32 est obsolète c'est un non sens, l'API a évoluée et reste la base de Windows. Ou alors c'est juste un problème de nom et j'aurai du parler de Windows API (mais c'est juste un synonyme récent). Et xlib ne donne accès qu'au fonctions graphiques de base et pas à des fonctions de haut niveau comme des dialogue d'ouverture de fichiers.Envoyé par SimonDecoline
heu ... une api présente depuis des dizaines d'années et qui permet encore aujourd'hui d'exécuter des programmes écrit dans les années 90, vous en connaissez beaucoup vous? je sais pas ce qu'il faut pour pas dire que c'est un sacré avantage justement.
un célèbre linuxien parlait justement d'un problème de compatibilité binaire sous linux, on pourra dire ce qu'on veut mais win32 a plutôt bien fait le taf jusqu'ici.
L'API POSIX peut-être...
posix ne fait rien comparé à win32 ><
Lol. Rien d'aussi obsolète, c'est sûr.
Et si win32 est si génial et que windows domine le marché, pourquoi il y a de plus en plus d'applis desktop basées sur électron ? Pourquoi ne pas juste les faire en win32 ?
rien d'aussi obsolète, il faut vraiment pas en avoir fait pour sortir ça.
"ton électron", dont tu sembles si fier, il utilise quoi à ton avis pour parler au système d'exploitation, avoir son contexte de fenêtre, ses handles de fichier, ses accès aux différents périphériques?
ce n'est pas parce que toi tu ne le vois pas, que tu ne t'en sers pas.
soyons sérieux 2s, si tu viens pour raconter des trucs pareils, franchement abstiens-toi.
Regarde la définition de "contre-exemple" dans un dictionnaire.
Pourquoi parler au passé puisque Gnome est encore utilisé? Alors, est-ce qu'il marche sur des machines légères ou pas?
Sur PC, quand un OS n'est plus maintenu on te pousse à passer au suivant, mais sauf à vouloir passer directement de windows 95 à Windows 10, le matériel peut encore survivre quelques années; sur téléphone il faut changer le matériel. Alors, qu'une nouvelle application qui nécessite trois fois plus de RAM refuse de tourner je veux bien, mais là si tu n'as rien contre l'obsolescence programmée du matériel, ben tant pis pour toi...
Relis ta question, je cite:
Ben si en l'occurence il y a eu une tentative qui s'appelait Firefox OS, sauf que les constructeurs ne s'y sont non seulement pas intéressé, mais ils ont tout fait pour brider leur matériel et le rendre incompatible. Alors oui ça intéressait du monde, et non, le monde de l'open source n'est pas responsable si le monde du matériel fait tout pour l'empêcher de percer.et qu'on ne me dise pas que le monde de l'open source en a pas les moyens d'avoir un truc qui fonctionne, il y a suffisamment de gros acteurs pour ça, il semblerait juste que ça n'intéresse personne.
Vu que tu n'as visiblement rien compris de ce que j'ai écrit avant: sans commentaire...
linux desktop et toi tu me sors autre chose, c'est pas un contre exemple.
à toi de me donner la réponse, si la seule chose qui t'inquiète c'est le temps d'un verbe...
as tu déjà écrit une application? parce que vu ce que tu racontes, il semblerait que non.
une application utilisant une api plus récente que celle présente sur ton os cible ne marchera (en général) pas, que ça soit sur windows, linux, android ou une cafetière.
il arrive même qu'une application utilisant une api moins récente que celle présente sur ton os cible ne fonctionne pas, mais ça en général on évite, mais bon, les bugs ou la nécessité de retirer des fonctionnalités problématiques d'une version à une plus récente, ça arrive.
en tout cas ça me fait une belle jambe que tu ne puisses rien pour moi, j'ai pas envie d'être associé à ce que tu écris.
je demande encore, en quoi ça a un rapport avec le sujet?
est ce qu'on parle du non intérêt de linux sur desktop, ou bien sur sa domination sur mobile?
bref j'en reviens pas du hors sujet complet.
l’hôpital qui se fou de la charité, je dirai pareil que ton compatriote, abstiens-toi la prochaine fois.
28 ans déjà
Merci pour ce petit rappel historique, et très content d'avoir vu une des premières versions de Linux fonctionner !
Et bon anniversaire ! C'est vrai que le desktop n'a fait que du sur place, mais Microsoft a vraiment fait tout ce qu'il a pu pour savonner la planche à Linux :
- le lissage des polices truetype est breveté, et les brevets viennent de tomber dans le domaine public 'd'un seul coup, on va pouvoir faire plein de choses sous Linux)
- Certains codecs vidéos aussi viennent de tomber dans le domaine public.
Ah, j'oubliais : j'utilise OpenGL, et Microsoft n'installe pas les pilotes par défaut sous Windows : c'est un vrai cauchemar pour expliquer à mes utilisateurs comment installer les pilotes (qui devraient être) fournis par le constructeur.
Oh, et une dernière aussi : la dernière campagne Microsoft qui consiste à faire croire que Linux est "dans" Windows ... avec son WSL ...
Et on pourrait aussi parler de l'outil de pourrissement des distributions qui est en train d'être mis à la mode dont je tairai le nom.
@benjani : pour le file open / save, / folder select etc, tu as Native File Dialog : Native File Dialog (https://github.com/mlabbe/nativefiledialog), ouverture d'un fichier, sauvegarde, écrit par Michael Labbe.
=> regarde comment j'ai fait avec miniDart (sur framagit) : le logiciel est écrit sous Linux et je le cross compile pour Windows, et j'ai eu TOUS les problèmes mentionnés plus haut.
- choix de l'API : j'utilise Dear ImGui, avec la SDL2 (portabilité, fenêtrage) + OpenGL (3.x+)
- ffmpeg pour tout ce qui est audio vidéo
- OpenCV (3.4, au dela, quelqu'un à tout cassé pour la partie qui m'intéresse)
- etc
--
qɔᴉɹə
Auteur d'OOoLight et OOo4Kids
L'association EducOOo : http://www.educoo.org (dérivé d'OpenOffice)
https://framagit.org/ericb/miniDart (logiciel Handball)
https://github.com/ebachard (logiciels variés)
Perso je trouve qu'il y a plus simple et plus pratique pour développer des applis de bureau (et plus efficace aussi) que du Javascript et du HTML
A part l'aspect "multi-plateforme" je n'y trouve aucun avantage pour le moment
Après chacun fait comme il veut
Merci pour le conseil, cependant j'ai déjà regardé Native File Dialog, et une énième fois, on retombe dans le problème que je décrivais. Native File Dialog fait exactement la même chose, elle va piocher pour Windows dans l'API Windows (création d'un objet COM), et pour Linux soit le binaire est compilé avec GTK et elle appelle la fonction qui va bien de GTK, soit elle appelle le binaire Zenity (qui est basé sur GTK). Native File Dialog ne supporte pas les bureaux KDE, seulement ceux basés sur GTK (Gnome).
Actuellement j'utilise la lib Portable File Dialog qui gère à la fois les bureaux Gnome (GTK/Zenity) et KDE (QT/Kdialog) : https://github.com/samhocevar/portable-file-dialogs
Et même si cette lib démontre qu'on peut tout de même s'en sortir, cela ne marche pas totalement car par exemple une distribution assez récente comme Debian 9 embarque une très vieille version obsolète du binaire KDialog quand on installe le bureau KDE. Debian 10 de même embarque une version de 2017.
Je ne veut pas que vous y voyiez une attaque contre Linux, ou un troll pro Windows comme le pense SimonDecoline. C'est juste un cas concret que j'ai rencontré pour tenter de faire avancer le débat sur pourquoi Linux a du mal à percer sur Desktop quand Linux monopolise quasiment le marché sur d'autres domaines.
Ici je déplore la situation regrettable où le fait de changer de bureau (de KDE à Gnome ou l'inverse) n'est pas, comme il a été dit avant, juste une configuration, mais la création de deux systèmes hétérogènes au sein d'une même distribution. Il manque juste une API de dialogues graphiques haut niveau commune, implémentable librement par chaque bureau. D'autant plus que chacun propose bien une solution (Zenity pour Gnome, KDialog pour KDE), il suffirait simplement que la syntaxe de ces commandes soit la même.
Il existe bien whiptail sur presque toutes les distributions qui permet de créer des dialogues en mode console (utilisé par exemple par debconf quand vous installez un paquet et qu'il vous demander de choisir une option). Pourquoi ne pas garder cette compatibilité dans le monde graphique?
@benjani13
Entièrement d'accord avec toi. Personnellement, je ne vois pas de troll là-dedans, et il n'y a pas de problème pour discuter de tout cela : j'ai mis 3 ans à en arriver où j'en suis, parce que c'était super difficile (même le path d'un fichier, ça peut poser des problèmes pénibles de portabilité !). Au hasard, un autre exemple qui m'a demandé une bonne semaine avant de comprendre ce qui se passait : avec Freetype, sous Windows, pas moyen d'utiliser une police de caractère qui n'est pas dans certains répertoires SAUF à utiliser une véritable usine à gaz ! En fait, utiliser une police truetype (ou opentype) sous Windows, c'est très très encadré. Sous Linux, on fait presque ce qu'on veut, et la vie est différente. Mais je ne saurais dire qui a raison (il y a autant d'arguments pour et contre pour les 2). Je pourrais aussi parler de l'accès à certains périphériques (USB par exemple). Je connais bien Mac OS aussi, et c'est encore un autre monde ...
Personnellement, devoir résoudre tous ces problèmes, m'a pris énormément de temps, mais m'a quand même bien ouvert les yeux : bien comprendre ce qui est important et ce qui ne l'est pas, quel que soit l'OS,. En particulier, qui aurait pensé que le simple fait d'ouvrir un fichier était si tordu quand on veut le faire sous Linux et sous Windows ?
Pour revenir à l'API à utiliser, sauf si c'est déjà proposé, je pense qu'il y a 2 autres pistes :
- Qt LGPL ou GPL : Mode retenu (à opposer au mode immédiat) avantage portabilité, localisation facile, inconvénients : API qui change tout le temps, on n'a jamais la bonne version et surtout, si tu veux faire des produits fermés, le prix de la licence.
- wxWidgets : je ne suis pas convaincu, mais ça à l'air tout à fait honorable / portable
Autres API (amha, pas encore mûres) : Nana, Nuklear aussi (intéressant car c'est du mode immédiat avec le SVG intégré)
mes 2 cts
[J'ai oublié] : merci pour le lien, je vais jeter un oeil au code
--
qɔᴉɹə
Auteur d'OOoLight et OOo4Kids
L'association EducOOo : http://www.educoo.org (dérivé d'OpenOffice)
https://framagit.org/ericb/miniDart (logiciel Handball)
https://github.com/ebachard (logiciels variés)
je ne pense pas que ça ai un gros impact... apple a mis des milliards en marketing sur mac os... et pourtant apple a moins de 10% de marché...
Si ça continue ça va devenir ici comme sur http://www.linuxfr.org ou finalement tu ne réponds plus aux gens car tu te fais moinser chaque fois. Rester cool les gars
mais je suis parfaitement d'accord avec ça, c'est juste qu'au bout d'un moment, je sais plus comment répondre, les gens ne te lisent pas, et te répondent avec assurance des trucs "bizarres" (pour ne pas utiliser un autre terme plus adéquate).Si ça continue ça va devenir ici comme sur http://www.linuxfr.org ou finalement tu ne réponds plus aux gens car tu te fais moinser chaque fois. Rester cool les gars
en tout cas, je suis preneur de toute suggestion, ça me casse littéralement les pieds de répondre comme ça.
Il n'y a pas plus de soucis en fermé entre wxWidgets et Qt. La licence LGPL permet du code fermé à condition que l'utilisation puisse changer la bibliothèque. Donc à part de l'embarqué ou tu ne veux pas que l'utilisateur puisse modifier le code pour raison de sécurité (style programme dans un véhicule) les 2 se valent à ce niveau.
- Avoir une API stable qui permette à tous les anciens programmes de fonctionne est quand même un avantage certain.
- Ensuite proposer une API plus "moderne" en même temps que l'ancienne est un élément qu'Apple avait utilisé il fût un temps, si ma mémoire est bonne.
- Electron permet surtout d'utiliser du javascript sur tous les sytèmes avec (sauf erreur) un système qui se base sur du WebView c'est à dire une page web dans une fenêtre d'un client "lourd". On a donc forcément un truc très lourd car au final c'est un navigateur notre application
Jamais essayé mais sciter permet de faire du code cross-plateforme en C++ avec une API Web (DOM) tout en étant très léger sur le Desktop
Ah bon je pense ça ? Elle est vraiment intéressante cette discussion. J'y ai même appris que j'étais fier d'électron, alors que je ne l'utilise jamais...
Tu ne penses pas que si c'était vraiment un cas concret, d'autres personnes auraient eu le problème et trouvé une solution ces 20 dernières années ? A priori, pour faire des applis graphiques multi-plateformes, on utilise une bibliothèque graphique multi-plateforme, et de qt à fltk, il y a quand une bonne variété de compromis fonctionnalités / légèreté. Mais si ton truc c'est d'utiliser des vieilles api, peut-être que ceci conviendra : https://github.com/x42/sofd
Ben aucun des deux en fait. L'article initial parle de l'historique de linux : les débuts du projet, les micro-noyaux, l'open-source, etc. C'est toi qui a dévié le sujet sur la fragmentation des distributions qui empêcherait linux de conquérir le monde du desktop, alors que l'article contient à peine une phrase sur le desktop. Et après, tu viens pleurer que les gens ne lisent pas correctement tes messages...
Dernière modification par LittleWhite ; 28/08/2019 à 11h31.
voilà un extrait du premier message de ce fil :
tu confirmes que tu ne lis pas. merci et à bon entendeur ...Et vous ?
En plus de 25 ans d’histoire quels sont les aspects qui, selon vous, font de Linux un succès qui est parti d’un hobby ?
De l’autre côté, quelles sont les tares que Linux continue à traîner et qui l’empêchent de s’imposer dans des filières comme le desktop ?
Peut-on établir des liens entre l’échec sur le desktop et les orientations de départ ?
Autrement dit, Linux a-t-il été conçu pour avoir du succès sur le desktop ?
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