Dropbox vient d'annoncer un nouveau client commun Windows/Linux se basant sur Qt5.
Encore un logiciel, qui pue certes, qui migre de GTK à Qt et surtout enfin un éditeur qui réfléchie à ne pas perdre du temps à développer une interface pour chaque OS. Enfin, il manque MacOSX par contre, je ne sais pas pourquoi.
# infinitif
Posté par Philip Marlowe . Évalué à 10.
Ton opposition aux logiciels qui puent se reflète dans cette merveilleuse création du verbe réfléchier.
# Support OS X
Posté par claudex . Évalué à 3.
J'imagine que le fait que le client ne soit pas développé pour OSX vient du fait que Qt ne gère pas trop bien ce système.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Support OS X
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 21 juillet 2014 à 10:55.
De toute façon OS X c'est pas libre et très tendance donc ils n'ont pas besoin de Dropbox :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Support OS X
Posté par gnumdk (site web personnel) . Évalué à 5.
Dans la tendance, c'était pour dire qu'il faisait suite à la migration en masse de GTK+ vers Qt ;)
[^] # Re: Support OS X
Posté par reynum (site web personnel) . Évalué à 2.
Oui j'avais bien compris ;)
C'était pour dire que les produits Apple bénéficient d'un effet de mode relatif à la communauté et au "mojo" des produits, ce n'est pas un reproche juste une constatation. De plus le but de ma réaction était purement humoristique en relation avec le titre du journal mais sans fondement technique.
kentoc'h mervel eget bezan saotred
[^] # Re: Support OS X
Posté par Renaud Guezennec (site web personnel) . Évalué à 8.
Le support de Mac OS X est plutôt bien fait par Qt. Le travail avec clang et Xcode ça passe. C'est moins naturel que sous linux mais cela marche bien.
Je ne sais pas d'où vient cette idée ?
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 21 juillet 2014 à 11:12.
OK, tu as l'air de bien savoir, donc dit-moi comment je fais avec Qt les icone "à la Mac" dans la toolbar:
- Deja, avant Qt 5.2, Qt disait merde à l'intégration du style de toolbar à la Mac (setUnifiedTitleAndToolBarOnMac() jeté au passage à Qt 5.0, maintenant revenu certes mais il a fallu insister de chez insister pour que Digia daigne s'en occuper, on sentait qu'ils comprenais le soucis mais que ce n'était pas la priorité)
- coins arrondis, groupement d'icones, même style pour le menu en popup… On fait comment?
- quand on clique et laisse le clic sur la toolbar, on peut déplacer déplacer la fenêtre entière. Enfin, sur une appli native, c'est peut-être moi mais je n'arrive pas à reproduire ce comportement sous Mac. Ca devrait être le truc hyper facile à coder vu que c'est l'UI MAc de base.
- J'ai bien quelques autres bricoles en stock dont mes utilisateurs Mac se plaignent dans mes applis codées avec Qt.
Qt fait quelques efforts, oui, pour le multi-plateforme. Mais perso, il y a des fois je me dis que j'ai les moyens bien comme il faut, j'embauche un spécialist UI Mac et vire Qt de Mac, car c'est mieux que tous les autres Toolkit, mais pas assez intégré pour Mac, on sent que Mac n'est pas leur plateforme prioritaire : ils veulent bien mettre un peu de moyens dessus, mais pas trop.
Pas de bol, les utilisatuers Mac sont exigeants (et je les comprend, l'intégration est le point fort d'Apple)
Suffit de coder en Qt à destination d'utilisateurs Mac pour avoir cette idée.
PS : oui, j'en chie justement en ce moment avec un projet ayant beaucoup d'utilisateur Mac puristes.
[^] # Re: Support OS X
Posté par binbin . Évalué à 2.
Tout à fait d'accord, c'est comme les applications Java, je les évite comme la peste sous Mac car l'intégration est très mauvaise (par exemple les raccourcis claviers sont ceux de windows et mode fullscreen bug affreusement…). C'est vrai que dans un système où tout est bien intégré une appli qui ne l'est pas jure beaucoup avec le reste…
Dommage car sous les autres plateformes Qt m'a l'air correctement intégré.
[^] # Re: Support OS X
Posté par flan (site web personnel) . Évalué à 1.
j'aurais tendance à dire qu'il y a moins de choses à intégrer sous les autres plates-formes, tout simplement. Quelques exemples :
Sans compter que certains paradigmes de l'interface graphique sont assez différents sur OS X.
[^] # Re: Support OS X
Posté par Gof (site web personnel) . Évalué à 5.
Il est vrai qu'il faut parfois faire appel à un peu de code spécifique pour chaque platforme. Mais Qt aide beaucoup à avoir la plus grande partie du code multi-platforme.
C'est le but de Sonnet (une bibliothèque de KDE Frameworks).
Je ne sais pas comment c'est supporté sous OS X, mais le but est d'utiliser le correcteur du système.
Qt gère ça.
Pour les mots de passes: https://github.com/frankosterfeld/qtkeychain
Pour ce qui est des certificats TLS et de la configuration des proxy, Qt utilise la configuration de la platforme.
[^] # Re: Support OS X
Posté par flan (site web personnel) . Évalué à 1.
Mais tu n'as pas ça de base, surtout quand tu utilises autre chose que C++ (Python dans mon cas).
L'aspect graphique est également parfois différent (sur les dockwidget, par exemple). Bref, on sent que ce n'est pas natif.
Après, Qt reste à mes yeux la seule solution valable quand tu veux faire du multi-plate-forme. Mais je ne la trouve malheureusement pas parfaite, notamment sur OS X.
[^] # Re: Support OS X
Posté par binbin . Évalué à 1.
Wow, que de réponses…
J'aimerais utiliser Linux mais mon entreprise est full-Apple (situation marginale, je sais, marché de niche…)
En vérité, j'étais hostile à Mac OS X avant de l'avoir vraiment utilisé - spa libre, spa bien !
L'intégration est un vrai plus, sans déconner ! J'ai les avantages d'un système Unix dans jamais mettre les mains dans le cambouis ^
Je reste persuadé que si quelqu'un avait quelques millions à investir pour un Linux user-friendly ça marcherait, et ça pourrait même être "mieux" que les OS existants et pour moins cher… Pour moi il faut appliquer la recette de PopcornTime à un environnement desktop Linux, et le tour et joué. Android n'était qu'un prototype ;)
(merde on est déjà plus vendredi)
[^] # Re: Support OS X
Posté par Funigtor (site web personnel) . Évalué à 0.
Mark Shuttleworth ?
(Oui, on est toujours pas vendredi.)
[^] # Re: Support OS X
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Et c'est normal, se taper un boulot monstre d'intégration (voire une réécriture complète) pour un marché de niche, ça ne donne pas envie.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 22 juillet 2014 à 08:41.
Mac un marché de niche?
En nombre d'utilisateurs c'est 10x plus que Linux sur le desktop
En monnaie, c'est 2x moins que Windows pour moi, d'autres disent que c'est plus rentable que Windows quand tu les prends pas pour de la merde (que tu programmes "natif").
Pas si niche que ça.
Ou j'ai mal compris ce que tu disais.
Note : pour les jeux plein écran sans intégration dans le bureau de l'utilisateur, pas d'intégration à faire vraiment, par contre uand on n'est pas plein décran et que c'est un "utiliataire" ça pardonne moins.
[^] # Re: Support OS X
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Pour le dev libriste:
Ces derniers manquent d'utilisateurs et demandent beaucoup plus d'investissement. Faire des portages pour ces OS, c'est limite de la charité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à -5.
D'une rien à voir avec le libre (il y a une tonne de libristes sous Mac, commençant par des développeurs Firefox. Mozilla c'est des faux libristes? sans doute du point de vue de quelques personnes… Qui ne font pas le libre à eux seuls).
De plus, justement, je t'explique que Mac n'est pas "marché de niche". Côté libre, c'est pareil que Windows, et côté potentiel, ça peut l'être voire plus.
Après, si tu veux te couper de revenus/dons en insultant les gens "c'est limite de la charité", c'est ton choix.
La charité, c'est distribuer pour Linux (quitte à troller sur des OS…)
[^] # Re: Support OS X
Posté par rewind (Mastodon) . Évalué à 2.
Oui. Quel est l'intérêt d'avoir un Mac pour faire du développement ? Qu'est-ce qu'il y a sous Mac qui n'existe pas sous Linux pour le développement ? Franchement rien. Linux est une très bonne plateforme pour développer. Juste le fait d'avoir des paquets -dev(el) et ne pas avoir à installer tous les entêtes à la main, c'est du bonheur. Utiliser Mac pour faire du développement quand on prétend faire partie de la grande communauté du libre, c'est juste pour la frime, ce n'est pas un choix technique raisonné. Quand on a un OS qui offre un excellent environnement de développement libre et qu'on va voir ailleurs pour des considérations non-techniques, oui, on est un faux libriste.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 22 juillet 2014 à 11:32.
On en est encore la, à opposer ceux qui ne font pas "comme il faut" décidé par on ne sait qui… :(
J'avais oublié les intégristes du libre, désolé.
[^] # Re: Support OS X
Posté par thamieu . Évalué à 4.
Un article en anglais par Matthew Garret, développeur GNOME, s'est posé cette question aussi. C'est court et intéressant, je trouve.
http://mjg59.dreamwidth.org/31714.html
[^] # Re: Support OS X
Posté par xcomcmdr . Évalué à 2.
Ou pas. Certains préfèrent XCode ou Visual Studio à n'importe quel IDE sous Linux, et je les comprends.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Support OS X
Posté par keyser.dyson . Évalué à -2.
J'ai renoncé a utiliser un IDE il y a des années.
Ca se passe en ligne de commande pour moi le développement sous linux. J'édite le code avec geany.
Pour debuguer, si je ne trouve pas tout de suite avec un ou deux printf() je lance Code::Block. Ca marche très bien.
On n'a pas le choix pour les application sous iOS. C'est XCode ou rien. Je déteste Apple.
Je lisais un post de développeur qui fait du Visual Studio. Il a un 8 coeur, 8 Go de mémoire et ça rame toujours.
[^] # Re: Support OS X
Posté par Frank-N-Furter . Évalué à 1.
http://ap4y.github.io/2013/11/10/vim-for-ios-developers.html
https://github.com/eraserhd/objective-vim/
etc
Depending on the time of day, the French go either way.
[^] # Re: Support OS X
Posté par Gof (site web personnel) . Évalué à 2.
Il y a QtCreator aussi qui permet de développer pour iOS (puisqu'on parle de Qt)
[^] # Re: Support OS X
Posté par keyser.dyson . Évalué à 2.
Pour l'éditeur, oui.
Il faut quand même payer les 99 $ si tu veux publier ton application.
[^] # Re: Support OS X
Posté par groumly . Évalué à 2.
Si tu veux publier ton appli sur le store.
Sinon, ya aussi jetbrains qui fait un ide.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Support OS X
Posté par keyser.dyson . Évalué à 0.
En plus, ils censurent les applis qui ne leur plaisent pas dans la forme ou dans le fond.
J'ai décidé de ne pas en faire. Je ne veux pas être enfermé dans leurs histoires.
[^] # Re: Support OS X
Posté par groumly . Évalué à 3.
L'interet?
Avoir un systeme de developement efficace(les memes outils sont dispos), mais avec en bonus un os qui fait a la fois tourner les dernieres versions des softs sans se ramasser a chaque mise a jour (aka symptome testing vs stable), avec des outils bien gaules (xcode et instruments), une interface esthetique (t'as le droit d'avoir un gout de chiottes, mais c'est pas le cas de tout le monde), ne pas etre force a foutre les mains dans le cambouis en permanence (je le fait suffisament toute la journee pour mes applis), une duree de vie de batterie decente, et d'autres trucs, genre support du retina, et la myriade de petits details qui viennent sur macosx.
Rajoute par dessus la qualite de construction de macbook.
Moi je trouve que ca fait un paquet de raisons.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Support OS X
Posté par woprandi . Évalué à 0.
Et les miroirs en guise d'écran sur les macbook t'en penses quoi ?
[^] # Re: Support OS X
Posté par groumly . Évalué à 2.
Qu'avec une bonne backlight, c'est pas un pb. Je bosse souvent dans mon jardin (la ou je peux fumer une clope), dans des aeroport/avion, ca m'a jamais gene.
Idem pour l'ipad/iphone (et la bizarrement, ya personne pour gueuler que les smartphones ne sont pas dispo en mat).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Support OS X
Posté par keyser.dyson . Évalué à -1.
En plus tu as tous les outils libres qui vont marcher sous MacOS.
Tu as le beurre et l'argent du beurre. Mais faut être riche ou faire des économies.
[^] # Re: Support OS X
Posté par Maclag . Évalué à 1.
J'en conclus qu'il y a un comité de certification de véritable "Libriste", et c'est une communauté élitiste.
Au fait, il y a d'excellents BIOS libres, avec des gens qui ne jurent que par le BIOS libre.
Vu de leur fenêtre, peut-être que tu n'es "Libriste" que pour la frime?
[^] # Re: Support OS X
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Wow un maceux qui critique l'élitisme ;-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Support OS X
Posté par Maclag . Évalué à 1.
Pas de bol: je n'ai pas et n'ai jamais eu le moindre appareil Apple.
[^] # Re: Support OS X
Posté par Renault (site web personnel) . Évalué à 2.
Ouais enfin un libriste qui finance une entreprise qui aime utiliser les brevets contre ses ennemis, bof bof la cohérence.
Un libriste implique que l'on soit sensible à l'idéologie et la philosophie et qu'on fasse de nombreuses actions pour l'utiliser, l'améliorer et le promouvoir. Ce qui est incompatible avec l'usage d'un produit Apple ou Microsoft à la maison par plaisir étant donné la politique de ces entreprises.
Car on parle bien de libriste, pas juste de quelqu'un qui aime le libre comme ça, certains de ses produits ou juste pour développer des produits cool. Les développeurs de Mozilla (ou de tout autre programme libre d'ailleurs) ne sont pas obligés d'être libriste, le projet est suffisamment intéressant techniquement pour le faire par plaisir ou défi.
Je vois du coup le libriste comme un militant pour sa cause, et être militant implique une cohérence (car bon, être militant écolo mais utiliser un 4x4 pour aller en ville, tu trouves ça cohérent aussi ?), et s'il n'y a pas ce respect de cohérence, tu n'es pas un militant. Et je ne juge pas ceux qui ne le sont pas, chacun fait ce qu'il veut mais utiliser cet adjectif pour décrire cette catégorie de personne me semble non approprié.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 22 juillet 2014 à 12:14.
On va revenir à la question du BIOS.
Il n'y a quasiment aucun "vrai libriste" car il accepte du non libre chez lui quand ça l'arrange.
Exactement pareil pour Mac OS car il n'y a pas de remplaçant libre (non, Linux sur le desktop n'est pas un remplaçant sérieux pour beaucoup de monde).
Cet argument est faux cul, car refuse à une personne de ne pas se faire chier tout en ne se refusant pas de ne pas se faire chier (et c'est bizarrement la personne qui parle qui décide de la limite).
Tout à fait. Celui qui accuse l'utilisateur Mac de ne pas être libriste et se considère libriste alors qu'il a un BIOS non libre par pur confort n'est pas militant, car pas cohérent. Il faut savoir assumer ses arguments.
Ici, on a juste des gens qui décident arbitrairement de ce qu'est un libriste, en fixant étonnament les limites à ce qu'ils aiment eux. La cohérence? Juste dans l'affichage quand on accuse l'autre de ne pas faire partie de.
[^] # Re: Support OS X
Posté par Renault (site web personnel) . Évalué à 5.
Enfin, tu compares l'achat d'un produit Apple avec un BIOS, sérieusement ?
Le BIOS est un composant mineur de ton ordinateur dans son ensemble et son importance vis à vis du matériel (et la difficulté d'en changer) rendent son utilisation selon moi acceptable car cette contrainte est lourde.
MacOS X est un composant majeur du système (toute l'interface graphique et même la plupart des couches bas niveau). Puis le matériel Apple est bardé en lui même de brevets qu'il utilise contre les autres quand la présence de BIOS n'implique pas de soutenir financièrement une boîte qui lutte contre les autres par voie judiciaire pour tout et rien.
Bref, oui il y a une différence assez nette selon moi.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 22 juillet 2014 à 14:27.
Oui, sérieusement : tu mets une limite arbitraire, et n'acceptes pas la limite arbitraire d'une autre personne.
C'est la seule différence.
Le BIOS aussi, tu ne démarre pas de machine sans BIOS.
Le résultat est le même quelque soit l'importance que tu met arbitrairement : tu as du non libre dans ta machine pour une question de confort (et on peut aussi parler matos : qui a un CPU libre?).
Tu refuses à une autre personne qui n'a pas la même limite le droit d'être libriste, arbitrairement.
Et tu parles sérieusement de cohérence? Poutre, paille… On a juste des gens qui veulent cloissonner, rejeter, autant dans la notion de libriste que la notion d'utilisateur ("on parle de charité", quel respect de la différence…), sans être meilleur (le choix de l'OS de la personne qui fait du libre, mais alors qu'est-ce qu'on s'en fout…)
Ca serait rigolo le jour où Linus Torvald achète un Mac.
Ah oui, c'est vrai, Linus a fait beaucoup pour le libre, mais c'est un merdeu non libriste, cet emmerdeur osait même avoir un SCM non libre à un moment… Autant aller vers les vrais libriste qui font Hurd! Il y a les libristes puristes qui font hurd inutilisé, et les libristes pratiques qui font Linux et utilisent du proprio qund ça arrange. Lesquels font avancer le libre?
[^] # Re: Support OS X
Posté par Renault (site web personnel) . Évalué à 8.
D'un autre côté, toutes les limites sont arbitraires quelque part. On fait des choix pour cataloguer et ces choix sont déterminés par l'Homme. De même la notion de Logiciel Libre est en elle même arbitraire, et alors ?
Oui mais des BIOS libres qui fonctionnent bien sur la plupart du matériel c'est rare. Et quand bien même le matériel est supporté, le fait de flashé ce matériel peut te le casser de manière irréversible et sans garantie auprès du constructeur. C'est un risque énorme.
Tu pousses la limite au CPU, ce qui est bien car en soit le matériel c'est du code mais sous forme de silicium. Pourtant le fondateur même du mouvement ne va pas aussi loin et pense que le matériel libre est une catégorie à part (changer le matériel que tu as amélioré ou vérifier sa conformité étant bien plus difficile). Dans cette version, qui est libriste ? Plus personne.
Microsoft et Apple ont des licences "libres" et "opensource" non approuvés par l'OSI et la FSF. Donc comme ils ont une limite différente on doit accepter leur vision des choses ? Non, il y a des limites arbitraires, on le sait, mais détnaturer des termes comme ça ça n'a pas un grand intérêt…
Je ne rejette personne, je dis juste que le terme libriste ne leur convient pas. C'est tout, ce n'est pas mal, tout comme être libriste n'est pas forcément bien.
Je n'ai pas tenu ces propos, ne les assimile pas à mon discours. Personnellement je ne suis pas d'accord avec ça.
Quand tu es militant pour le LL, tu ne finances pas à côté une entreprise qui use et abuse de brevets logiciels, emprisonne son utilisateur dans ses solutions et autres. Ça ce n'est pas cohérent du tout et se prétendre militant pour le LL (car c'est ça être libriste) et finançant sciemment cette entité légale c'est aberrant. Et c'est selon moi très différent d'une solution de confort qu'est d'avoir un BIOS sur sa machine qui est une contrainte bien plus lourde (il est plus facile d'acheter du non-Apple que d'utiliser un BIOS libre) et dont son utilisation n'implique pas un enfermement auprès de l'entreprise qui l'a conçu, ni un financement pour payer des avocats pour lutter contre d'autres éditeurs de logiciels ou de matériels.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 22 juillet 2014 à 14:45.
C'est une des principales raisons pour laquelle les gens utilise Mac plutôt que Linux.
Merci de l'argument.
Soit il convient aux utilisateur de Mac et utilisatuers de BIOS non libre, soit il convient a aucun des deux.
Sauf que la notion de libre est communément acceptée (pas de NC, pas de ND etc…).
Dans le sujet ici, ben… il y a quelques personne pour hurler, mais sinon pas mal de monde accpete les utilisateurs Mac comme libristes et pas qu'un peu libriste, n'en déplaise à ceux qui veulent voir Apple comme le mal absolu.
La, c'est essayer de tirer la couverture sur sa notion en refusant que d'autres ne sont pas vraiment en phase. Mais bon, rien de nouveau, à une époque c'était les gens contre le commerical qui disaient qu'à partir diu moment où on fait du commerical, on n'est plus libriste car le cmmercial trahit le libre. Ici, tu as le même cgenre de comportement que ces personnes.
Tu a oublié de répondre à la partie qui dit que les gens que tu ne considères pas comme libristes ont fait 1000x plus pour le libre que les gens que tu estimes libristes.
Moi, perso, je me fout complet de ces libristes qui ne font pas grand chosse, je prend plutôt les "non libristes" comme désignés, pour faire avancer le libre. Chacun sa façon de faire avancer (ou ne pas faire avancer) le libre.
[^] # Re: Support OS X
Posté par Renault (site web personnel) . Évalué à 6.
Ouais enfin tu compares sans doute 99% de disponibilité à 1%… Toi qui n'arrête pas de dire que Linux a peu d'utilisateurs tu pourrais être de bonne foi en acceptant que le BIOS libre concerne peu de matériel et demande des manipulations plus compliquées que d'installer une Ubuntu (en plus d'être potentiellement irréversible).
Car Apple finance une armée d'avocats très actifs pour des histoires de brevets logiciels ridicules, que leurs solutions ne sont pas ouvertes (bah oui, iTunes obligatoire, interdiction d'utiliser son système ailleurs que sur son matériel, AppStore qui sélectionne les applications selon des critères discutables avec impossibilité d'installer des applications en dehors, etc.).
Oui, Apple est sûrement libriste car les contributions à CUPS, Webkit et LLVM font d'eux des militants de cette cause (alors qu'en fait ils font ça peut être pour l'aspect technique mais clairement pas par idéologie).
Tu vois, à t'écouter Apple serait libriste car en effet ils développent des LL de qualités, mais vu ce qu'ils font à côté…
Ces personnes sont (ou étaient) débiles car le LL accepte le commercial par définition.
Là tu es en train de nous dire que de financer une entreprise qui fait beaucoup de choses contraires au principe du LL n'empêche pas d'être un militant de cette idéologie. Elle est où la cohérence ?
Un libriste c'est quelqu'un qui va consentir des efforts pour soutenir l'idéologie du LL, comme tout supporter d'une cause qu'il souhaite défendre. Ça ne signifie pas que ça permettra des avancées significatives, ça peut dire juste qu'il est un grand sympathisant du mouvement et n'utiliser que ça à la maison par principe. En tout cas coder avec du matériel et un système Apple et dire "je fais du LL une cause que je défends" ça fait ridicule. Ça fait avancer oui, mais le gars entre lui même en très grande contradiction.
Financer des procès de brevets logiciels, c'est sûr que ça fait avancer le libre dans le bon chemin.
C'est là l'incohérence.
[^] # Re: Support OS X
Posté par Maclag . Évalué à 3.
Et voilà.
Plus haut, on dit que la limite entre un bon Libriste et un mauvais Libriste est arbitraire.
Développer des logiciels libres sous Mac OS X fait de toi un mauvais libriste. Tu en es absolument convaincu et ça ne fait aucun doute dans ton esprit.
À une époque, faire du commercial faisait de toi un mauvais libriste. Les détracteurs du commercial en étaient absolument convaincus et ça ne faisait aucun doute dans leur esprit.
Je suis prêt à parier que je vais te trouver des gens qui te disent qu'un mec qui fait un compromis sur le BIOS est un mauvais Libriste. Ils en sont convaincus et ça ne fait aucun doute dans leur esprit.
Rappelons qu'on parle de licences de logiciels, et que ce n'est pas censé être une religion avec des fidèles et des infidèles.
[^] # Re: Support OS X
Posté par Antoine . Évalué à 3.
Dans ce cas, pourquoi parler de "libristes" ? Visiblement, cette histoire de licences est sacrément identitaire pour certains…
[^] # Re: Support OS X
Posté par Tit . Évalué à 4.
commerical, commerical, cmmercial… on dirait que tu as du mal avec le mot commercial, contrairement à ce qu'on pourrait croire à te lire… tu devrais en parler à ton psy ;-)
[^] # Re: Support OS X
Posté par Maclag . Évalué à 5.
Un composant qui permet de laisser des backdoors dans ton système en toute transparence, qui peut aussi verrouiller le système pour s'assurer que l'OS est bien celui fourni par le constructeur, je ne dirais pas qu'il est mineur.
Je pense que pour toi il est mineur parce que ça t'arrange bien et que rares sont ceux qui agissent à son sujet.
"Bon, les gars, on va se mettre d'accord: on est Libristes jusqu'au bout, sauf quand c'est trop chiant et/ou compliqué. Alors on va se mettre d'accord sur ce qui est trop chiant et compliqué, et comme ça on pourra continuer à faire la morale aux autres tout en restant solidaires et cohérents entre nous."
Tu sais que Intel et AMD mettent beaucoup de micro-codes dans leurs puces qui pourrait très bien être fournie avec le pilote? Ça ne te dérange pas de soutenir des boites qui ont des pratiques aussi fermées?
Le problème c'est qu'Apple utilise la voie judiciaire ou qu'ils font du proprio et enferment leurs utilisateurs? Parce que j'ai comme l'impression que ça n'a plus grand chose à voir avec Libre vs proprio.
Une boite certifiée "Libre" (s'il y en a) qui aurait beaucoup d'avocats et ferait des procès ne mériterait plus son certificat de Librisme?
[^] # Re: Support OS X
Posté par groumly . Évalué à 1.
Je crois que tu surestimes tres largement la popularite reelle d'android (i.e. Utilisation, pas juste nombre de telephone vendus), et sous estimes tres largement a la fois la taille de la communaute libre cocoa, et la base d'utilisateur ios actifs.
Pour info, sur mes projets, toutes les librairies sont libres (renseignes toi sur cocoapods), et les fournisseurs de libs proprio sont supers rares (sorti des analytics, et encore, les principaux distribuent sous bsd).
Niveau utilisation, depuis 3+ ans que je fais ce taff, j'ai toujours vu un rapport 7 a 10 en faveur d'ios, a tous les niveaux. Niveau business, android vient systematiquement apres "on va lancer sur ios, on verra comment ca marche, affiner le produit, et apres si ca le fait, on verra pour le portage android".
Pour l'investissement, ca se discute, quand je vois le temps perdu par l'equipe android ici a faire de la qa sur 40 devices, le temps gache a code contre un os sorti ya plus de deux ans, et les acrobaties pour tenter de supporter les dernieres features 4.x, je me dit que t'as une conception bizarre de l'idee, ou alors que t'as jamais vu une equipe ios a l'oeuvre.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Support OS X
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Tu fais du libre?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Support OS X
Posté par groumly . Évalué à -1.
Entre autres. J'ai qq commits sous license bsd, oui.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Support OS X
Posté par flan (site web personnel) . Évalué à -1.
qui a parlé de dev libriste ?
Puis je trouve toujours curieux ce genre d'affirmations péremptoires pour un groupe de personne finalement assez mal défini…
[^] # Re: Support OS X
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ben moi! J'ai même commencé mon post par Pour le dev libriste pour ne prendre personne en traître.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Support OS X
Posté par Renaud Guezennec (site web personnel) . Évalué à 1.
J'avais plus en tête le support de MAC OS X (compilation, installation, packaging); pas le support d'Aqua ( l'interface utilisateur de MAC OS X ).
Je pense que peu de développeurs Qt travaillent sous MAC. C'est là la source des problèmes.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 1.
1% des gens voient ça.
Les developpeurs.
99% des gens voient ça.
Les utilisateurs.
Sans doute.
Mais c'est toi qui demandait "Je ne sais pas d'où vient cette idée ?". Ben… de 99% des gens qui n'ont pas à faire à la partie développement et à qui tu ne pensaient pas…
Le problème, c'est que les 1% de gens qui font le développement se tapent les retour des 99% d'utilisateurs, donc au final on a malgré tout 100% des gens qui touchent à Qt sous Mac embétés par le support Mac.
Bref, à la limite un développeur peut survivre en bidouillat pour la partie packaging, mais il est quand même dans la merde pour la partie Aqua. C'est dommage, car ça limite de mon point de vue l'interêt de Qt (les Mac étant plus nombreux que les Linux sur le desktop, et surtout valant plus car ils dépensent plus).
PS : bon, OK, il doit y avoir quelques personnes à qui ça suffit de compiler pour dire que c'est crossplatform, mais ceux-la développent plutôt avec GTK quiite à n'avoir rien à faire des utilisateurs ;-).
[^] # Re: Support OS X
Posté par jypaigue . Évalué à 1.
Il semble que certains font de bonnes appli MAC en GTK, par exemple on m'a dit du bien de l'intégration de Xamarin Studio sous cet OS… Jamais testé, juste entendu dire. Certains connaissent ?
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 1.
A la vue rapide de la première capture d'écran, c'est assez "Mac friendly".
Reste que je ne sais pas comment faire ça avec GTK de base (=sans faire de code ultra-specifique en mélangeant GTK et obj-C) et que l'outil a l'air de ne pas vouloir montrer son code source…
Donc est-ce "de base" avec GTK? comment faire? Est-ce vraiment du GTK?
Mystère… Je parierai bein sur l'utilisation de l'API native.
[^] # Re: Support OS X
Posté par jypaigue . Évalué à 1.
La personne qui m'a parlé de ça a écrit cet article, si tu veux plus de détails :
http://www.lanedo.com/embedding-osx-ui-elements-in-the-gtk-toolkit/
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à 2.
On a bien la réponse : développement natif. Pas le tookit "fait moi un bouton et adapte le à l'OS", tu dois te démerder avec l'API native "si Mac, alors on développe nous même sinon fait moi un bouton et adapte le à l'OS".
Mieux que devoir tout faire, c'est hybride, mais c'est un portage bien à faire soit-même.
[^] # Re: Support OS X
Posté par Littleboy . Évalué à 4.
Ils ont:
- un moteur de theme GTK specifique
- pas mal de code pour l'integration
Bref, il y a pas de secret. Pour avoir une 'vraie' integration, c'est a dire pas seulement quelque chose qui ressemble vaguement mais qui s'integre vraiment au systeme, il faut ecrire du code specifique a l'application.
QT aide probablement plus que GTK mais ils peuvent pas raisonnablement tout couvrir et certaines choses specifiques seront a la charge de l'appli.
[^] # Re: Support OS X
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 21 juillet 2014 à 22:16.
déja, Qt ;-)
Ensuite, je comprend que les choses spécifiques soient à la charge de l'appli, mais la je parlais pas mal de toolbar classique quand même. C'est une toolbar! juste qu'avec Qt, elle est pas déssinée correctement par rapport aux guidelines. C'est un creproche classique fait à Qt sur Mac, car c'est un truc très utilisé une toolbar.
Bref, on a bien la réponse : le toolkit ne fait que passer une surface à dessiner et à toi de té démerder, dans ce cas. Passage obligé pour juste faire une toolbar intégrée à l'OS :(.
# Trollodi
Posté par Xinfe (site web personnel) . Évalué à 4.
J'ai pas vu la semaine passer, c'est cool que ça soit déjà vendredi !
Bon week-end :)
Du côté technique, c'est peut être que l’environnement de développement associé à Qt est agréable à utiliser (Qt creator), que propose GTK+ de son côté ?
[^] # Re: Trollodi
Posté par gnumdk (site web personnel) . Évalué à 2.
Si il n'y avait que l'environnement de développement, j'ai déjà codé en GTK+ et franchement, c'est le jour et la nuit…
# GTK is dead
Posté par ckiller . Évalué à 8.
Je crois qu'il faut se faire une raison, GTK is dying.
Ils n'ont pas su suivre l'innovation, et surtout, ils ont une documentation qui a été écrite avec les pieds. (Normal pour du GNOME :-) )
Je ne vois aucune raison pertinente qui ferait qu'un nouveau projet partirait sur une solution GTK.
[^] # Re: GTK is dead
Posté par reynum (site web personnel) . Évalué à 0.
Pour moi si on veut du fast and furious on prend les EFL si on veut du clean and beauty on prend QT et si on veut easy and tiny on prend du tcl/tk.
Et Mate réécrit en QT c'est pour quand ? :-D
kentoc'h mervel eget bezan saotred
[^] # Re: GTK is dead
Posté par bobble bubble . Évalué à 6.
tu veux dire, si on veut du cute ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Concurrence
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 21 juillet 2014 à 11:32.
Sérieusement tu ne vois pas? Comme d'autres entreprises, Dropbox est sur territoire américain et a ton mot de passe pour déchiffrer (le chiffrement est pour contrer les gens qui ne sont ni toi ni Dropbox), donc la NSA a accès à tout ce que tu mets dessus. Et vu que Snowden a une dent contre la NSA…
Comme Dropbox. La n'est pas la "faille". La faille est de savoir qui a la clé de chiffrement/déchiffrement. Dans le cas de Dropbox, Dropbox Inc l'a aussi (comme beaucoup d'autres entreprises qui permettent un accès web aux fichiers)
Spideroak ne permet pas, il me semble, l'accè web, car ne stocke pas la clé. La clé est important, chiffrer avant de toucher le serveur n'est pas suffisant.
Edit : Argh, je lis que si en fait "On our website, we actually recommend against using the web interface at all due to this issue, but we provide it anyway, due to overwhelming customer demand." donc hop une petit modif Javascript et on récupère le pass…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Concurrence
Posté par flagos . Évalué à 3.
Dropbox utilise la plateforme de cloud d'Amazon, ca m'étonnerait que la NSA n'aient pas les clés du local:
http://fr.wikipedia.org/wiki/Dropbox
[^] # Re: Concurrence
Posté par Zenitram (site web personnel) . Évalué à 1.
Amazon ou pas, bof : le chiffrage AES 256 bit est quand même la, avant l'upload sur Amazon. Amazon ne ovit rien à part des octets "aléatoires". Mauvais sujet.
[^] # Re: Concurrence
Posté par flagos . Évalué à 5.
Ça on ne le sait pas. Tu le dis toi même : Dropbox a les clés car ils fournissent un accès web aux fichiers. A moins que Dropbox ait fait un montage un peu complexe, on peut supposer que les clés sont également chez amazon, voire pire, que ce ne soit chiffré que pour le transit et en clair sur les serveurs.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Concurrence
Posté par rakoo (site web personnel) . Évalué à 4.
Et encore, il faut être sur que la clé n'est pas envoyée au serveur. Et comme le client de SpiderOak n'est pas open source, aucun moyen d’être sur.
# wxwidget
Posté par François (site web personnel) . Évalué à 1.
Il me semble que Dropbox utilise WxWidget et non Gtk (directement j'entends)…
[^] # Re: wxwidget
Posté par gnumdk (site web personnel) . Évalué à 2.
Non:
https://aur.archlinux.org/packages/dropbox/
[^] # Re: wxwidget
Posté par david.g . Évalué à 2. Dernière modification le 21 juillet 2014 à 20:56.
Si! :)
Dropbox utilise wxWidgets, wxWidgets est inclus dans le bundle voilà tout.
PS: Levez la main ceux qui s'en tape des changements de toolkit ?
# Pendent ce temps chez ownCloud
Posté par Gof (site web personnel) . Évalué à 6.
ownCloud utilise aussi Qt, depuis le début
[^] # Re: Pendent ce temps chez ownCloud
Posté par gnumdk (site web personnel) . Évalué à 3.
Idem pour seafile même si ils ont eu l'idée pourrie de lui mettre un skin :(
# qui pue
Posté par Antoine . Évalué à -9.
Bizarre, chez moi Dropbox n'avait pas d'odeur. Peut-être quelque chose d'autre chez toi ?
[^] # Re: qui pue
Posté par Dr BG . Évalué à 6.
Ouvre la boîte, pour voir.
[^] # Re: qui pue
Posté par Kekun (site web personnel, Mastodon) . Évalué à 1.
Pas possible, elle est fermée, seul son éditeur peut l'ouvrir.
[^] # Re: qui pue
Posté par Dr BG . Évalué à 2.
Ça faisait partie de la blague :-)
# GUI SDL
Posté par keyser.dyson . Évalué à -4.
Je n'aime pas QT car ça ressemble beaucoup aux MFC que j'ai trop pratiqué. C'est un avis personnel.
Le rendu de QT est très bon. Il ont leur propre moteur. Ils n'utilisent pas les widgets natifs d'après ce que j'ai lu.
Je voudrais faire une application avec IHM et j'ai pensé a GTK.
Ce que j'ai constaté c'est que ça n'a pas l'air facile au niveau du portage vers Windows. Ca s'améliore mais ce n'est pas encore ça.
J'aime bien SDL. SDL passe partout, sur quasiment toutes les plateformes. Ca ne fait que l'affiche bas niveau, la gestion de la fenêtre (souris et clavier).
Je cherche un GUI pour faire des applications avec des boutons et des listes. Je pense que c'est faisable.
[^] # Re: GUI SDL
Posté par Gof (site web personnel) . Évalué à 4.
Déjà, on écrit « Qt » avec un t minuscule. (Et accessoirement: « GTK+ », avec un +)
Qt ressemble assez peu aux MFC. On utilise plus des signaux et des slot et pas tellement des événements. Il y a un éditeur visuel (qtdesigner). Et c'est bien plus moderne.
Sinon, il y a aussi QML qui est bien pratique.
[^] # Re: GUI SDL
Posté par keyser.dyson . Évalué à -1.
Ton "Code Browser" est très intéressant.
J'étais déjà tombé dessus en faisant des recherches sur la réflection.
Ta solution avec Squashfs est très astucieuse aussi.
Au fait, on "Qt4 Designer" et pas qtdesigner :-)
[^] # Re: GUI SDL
Posté par barmic . Évalué à 3.
C'est quoi la différence fondamentale ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: GUI SDL
Posté par keyser.dyson . Évalué à -1.
Ca doit être des sortes de "delegate" :-)
[^] # Re: GUI SDL
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
A partir du moment où tu dis que Qt ressemble beaucoup aux MFC, on sort justement de l'avis personnel, il ne s'agit pas d'une question de goût, tu devrais pouvoir nous faire une liste de ce qui rend Qt proche des MFC, et en quoi tu sembles trouver ça pénible.
Pour de l'appli native multiplateforme non web, Qt est indétrônable.
[^] # Re: GUI SDL
Posté par keyser.dyson . Évalué à -2.
C'est un framework. On est "dedans".
J'ai vu deux stratégies chez les développeurs qui utilisent des frameworks. La première est de coller au framework et de faire comme le framework dit. Les fameuses "bonnes pratiques".
La seconde est de faire sa couche. Un "second système" mais c'est un anti-pattern.
J'ai vu ça dans les librairies de "widget" et dans les ORM.
Ca ne m'intéresse plus du tout et pour moi c'est un repoussoir.
Ce qui me convient sont les outils qui se composent ou qui sont légers.
Par exemple au niveau de la base de donnée, LINQ me plait beaucoup (chainage de méthodes).
JQuery et Node.js marchent comme ça aussi. Tu sélection des noeuds et tu fais tes branchement avec des lambdas.
Au niveau interface, dans un jeu par exemple, le programme contrôle la boucle principale. Tu regardes si le bouton est cliqué. Tu n'attends pas un message qui te dis quel bouton est cliqué.
On est au-dessus. C'est mieux.
Oui c'est vrai. Si tu compares les frameworks de widgets entre eux, c'est le meilleur de loin.
[^] # Re: GUI SDL
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Ne le prends pas mal, je t'ai relu plusieurs fois, promis juré, mais je ne comprends toujours quasiment rien à ce que tu reproches à un framework comme Qt.
Tu sembles entre autre reprocher l'aspect événementiel de Qt, mais attendre d'être "averti" qu'un bouton soit cliqué n'est-il pas en total accord avec la programmation par callback qu'on voit partout maintenant ? Tu veux réellement regarder régulièrement l'état d'un bouton pour savoir s'il faut exécuter le code associé au clic ?
[^] # Re: GUI SDL
Posté par keyser.dyson . Évalué à -2.
C'est le paradigme que je n'aime pas. Dans le paradigme des "widgets", Qt est très bien.
Pense au HTML, par exemple, c'est un autre paradigme. En JQuery, tu fais une requête pour sélectionner des noeuds sur lesquels tu mets des attributs ou des handlers. C'est une approche différente.
Il y a aussi Genera, un sytème d'exploitation en Lisp. Quand tu affiches un "integer" sur l'écran, ça rester un entier. Tu peux le coller dans un input qui prends des "integers" en clicquant dessus.
http://en.wikipedia.org/wiki/Genera_%28operating_system%29
http://www.youtube.com/watch?v=o4-YnLpLgtk
Il y plusieurs façons de faire des interfaces graphiques.
Dans un jeu, on régule le FPS dans la boucle principale. Le but est calculer au moins 30 frames par seconde.
On récupère les coordonnées de la souris soit par polling soit dans l'événement. Après on regarde quelle sont les zones activées par le clic. Des boutons par exemple ou des sprites.
C'est ce que l'OS fait aussi. Ce n'est pas un problème dans un jeu. Ca consomme très peu de CPU.
Les gestionnaires de fenêtres proposent une façon de faire dans leur API mais on n'est pas obligé de la suivre.
D'ailleurs Qt n'utilise pas le rendu natif, ils ont refait le leur. C'est que ça ne leur convient pas non plus.
C'est toujours mieux d'être au-dessus. Tu connais mieux les événements et les objets qui t'intéressent que l'approche du bas vers le haut (du bouton vers son conteneur).
[^] # Re: GUI SDL
Posté par groumly . Évalué à 5.
D'un autre cote, ca tombe bien, qt est pas un framework de jeu.
D'autre part, un bouton, ne s'active pas quand tu cliques dessus mais quand tu cliques dessus et relaches dessus (valable en tactile ou souris, le gamepad je sais pas trop). Ca devient un tantinet plus complique a gerer avec autre chose que de l'evenementiel, vu comment les inputs sont delivres dans 100% des systemes graphiques.
Associer une fonction a "touch up inside" c'est quand meme vachement plus simple que de se taper sa propre machine a etat pour un pauvre bouton.
Meme iOS qui fait absolument tout en delegation (ou target/action, qui est au final le delegate du pauvre) marche sous le capot avec des evenements qui sont envoyes par le systeme d'input.
Gerer une interface (pas un jeu, une interface) comme tu le dit, c'est de la connerie pure et dure.
En quoi c'est different? Onclick, c'est encore de l'evenementiel, et c'est assez central a la gestion d'une interface en js.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: GUI SDL
Posté par keyser.dyson . Évalué à -3.
Tu as un marteau en main et tu vois tous les problèmes comme des clous.
Il y a plusieurs façons de IHM. Ca dépend de ce que tu fais.
Si tu veux faire un terminal ou client IRC, tu peux utiliser une liste et un "edit box".
Tu peux aussi gérer un tableau de caractères à deux dimensions. Chaque cellule a sont caractère, sa couleur, sa sélection …
Dans un framework, tu as toujours un moyen de debrayer a un niveau plus bas. Quand tu es à ce niveau, tu n'as plus besoin du framework.
Dans la FRP, ils ne gèrent pas de handler. C'est des transformation avec des "monades". Il n'y a pas de "on_machin".
Faire des handler n'est pas "mauvais". C'est juste une façon parmis plusieurs.
[^] # Re: GUI SDL
Posté par xcomcmdr . Évalué à 3.
Je vois pas du tout en quoi.
A la limite on pourrait rapprocher Qt de WPF (QML permet de décrire une UI avec un langage déclaratif, tout comme XAML, et on peut rapprocher les bindings QML vers C++ des bindings XAML vers XAML/C#). Dans les deux on peut aussi utiliser les événements, mais ce n'est pas obligé.
MFC ça se rapprochait plus de "faire une GUI avec la Xlib", du peu de ce que je sais des deux (les deux utilisent principalement les événements, les deux reçoivent un événement de type WM_PAINT de la part du serveur d'affichage pour mettre à jour leurs graphismes). Bref, assez bas niveau, et les deux datent d'avant l'accélération graphique, ce qui fait que typiquement les fenêtres étaient dessinées par le CPU.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: GUI SDL
Posté par keyser.dyson . Évalué à -1.
Effectivement. Qt est hyper-sophistiqué au niveau du rendu.
Je voyais ça comme tu dis plus haut au niveau utilisateur.
J'ai vu du code Qt récemment et j'ai reconnu le même genre de structures que font les MFC.
Les mêmes macros pour router les messages. Les mêmes genres de classes. Les mêmes solutions pour gérer les strings.
L'approche globale est la même. Il n'y a pas de changement de paradigme. C'est la même chose en mieux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.