Original post of Goffi.Votez pour ce billet sur Planet Libre.

Dans les formations que je propose d’animer il y a une initiation à la mise en page avec Scribus, logiciel libre de PAO (publication assistée par ordinateur).

Chacune de mes formations fait l’objet d’un support de cours afin de laisser plus que des notes aux stagiaires. Afin de respecter la philosophie du logiciel libre (et la mienne) ces supports sont mis à disposition sous une licence libre (en l’occurrence Creative Commons Attribution – Partage dans les Mêmes Conditions 4.0 International comme le reste de ce site).

Ces supports feront l’objet d’une publication en ligne au fur et à mesure de leur état d’avancement. Voici donc le premier : l’initiation à la mise en page avec Scribus.

N’hésitez pas à commenter (sur la page de contact) et à revenir le consulter ultérieurement, il ne peut que se bonifier avec le temps ! De plus, Scribus évolue (et la prochaine version apportera de substantielles améliorations !), donc le cours évoluera aussi.

Voici la table des matières actuelle :

• Qu’est-ce qu’un logiciel libre ?
• Notions essentielles en infographie
  • Image matricielle ou vectorielle ?
  • Dimensions et définition d’une image
  • Résolution
  • Modèles colorimétriques
  • Formats d’images usuels
• Installation de Scribus
  • Télécharger et installer Scribus
  • GhostScript
  • Localiser le profil personnel
• Imaginer précisément la maquette
  • Réaliser des croquis
  • Caractéristiques techniques
  • Créer un nouveau document
• Premiers cadres avec Scribus
  • Créer des cadres recevant du contenu
  • Créer des polygones
  • Appliquer des couleurs
  • Créer des cadres d’image
  • Créer des cadres de texte
• Mise en page, disposition des cadres
  • Repères et précision
  • Agencement des cadres
  • Espacer et aligner
  • Habillage
• Les couleurs
• Gabarits de page
  • Créer un gabarit
  • Numéros de page
  • Appliquer un gabarit
• L’album
• Textes et styles
  • Propriétés de texte
  • Intérêt des styles
  • Styles de paragraphes
  • Styles de caractères
  • Héritage
  • Appliquer des styles
• Gestion du document
  • Propriétés du document
  • Rassembler tous les éléments
  • Exporter en PDF
• Comment personnaliser votre Scribus
  • Général
  • Document
  • Guides
  • Outils
  • Vérificateur
  • Exporter au format PDF
  • Raccourcis clavier
  • Affichage
  • Outils externes

Pour les coulisses techniques, je rédige mes cours en utilisant la syntaxe Asciidoc. Je peux ensuite générer facilement une version Web en utilisant Bootstrap pour Asciidoc, un environnement permettant une mise en page agréable, moderne et adaptative selon la taille de l’écran (vous pouvez lire ce cours sur votre téléphone).

Cet article Initiation à la mise en page avec Scribus est apparu en premier sur Formation logiciel libre.

Original post of Dimitri Robert.Votez pour ce billet sur Planet Libre.

Face à la NSA, Wikipédia protège un peu plus ses articles - Numerama

Wikipédia chiffrement pistage

antistress : "La fondation Wikimédia a pris des mesures supplémentaires pour contrer les activités de la NSA. La connexion HTTPS est désormais généralisée à l'ensemble du trafic Wikipédia et des projets frères, afin de neutraliser la surveillance de masse."

---

L'ONU demande le droit à une connexion anonyme sur internet - Numerama

droit pistage institution ONU

antistress : "Le Rapporteur spécial de l'ONU sur la promotion et la protection de la liberté d'opinion et d'expression, David Kaye, demande que les gouvernements renoncent aux lois qui imposent aux opérateurs de télécommunications ou aux services en ligne de relever l'identité réelle de leurs clients."

---

Original post of Planet Libre.Votez pour ce billet sur Planet Libre.

Régulièrement, lors des sorties de nouvelles versions de GNOME ou KDE (voir de tout autre environnement de bureau), des utilisateurs des différentes communautés se lancent dans des flamewars pour mettre en avant leurs propres choix et dénigrer ceux de l’adversaire. Pour les personnes ne s’intéressant pas particulièrement à la technique, il est parfois difficile de faire la part du vrai, et j’ai donc trouvé intéressant d’interroger Cédric à ce sujet, qui connaît bien ces deux environnements pour avoir développé sur l’un et l’autre.

Et nous en profiterons bien évidemment pour en savoir plus sur l’avenir de Lollypop, dont la dernière version de cet excellent lecteur de musique vient tout juste de sortir.

Peux-tu te présenter brièvement, ainsi que ton parcours ?

Alors, Cédric Bellegarde, je vis dans l’Anjou, j’ai une formation niveau DUT très orientée développement. Malgré cela, ma seule expérience professionnelle dans ce domaine est mon stage de fin d’études chez Aliacom sur le logiciel OBM (chez Linagora aujourd’hui). Je me suis ensuite orienté dans l’administration système et réseau dans le milieu universitaire.

Dans le domaine du libre, j’ai dès 2003/2004 rencontré la communauté Mandrake française en contribuant à quelques paquets pour la distribution. Par la suite, de 2006 à 2007, je contribue activement au projet Compiz et Compiz-Fusion sur la gestion des fenêtres en particulier. En 2007, première expérience avec Python+GTK avec un client MPD (sources, capture d’écran).

Fin 2008, je migre sous KDE4,  je contribue à différents projets : rekonq, oxygen-gtk, kdepim… En 2013, un projet attire mon attention, se baser sur le travail de Canonical pour déporter la barre de menu de manière native sous KDE. Je me lance donc dans kded-appmenu et contribue directement à Kwin.

Par la suite, je me rends compte que j’ai de plus en plus de mal avec le bureau de KDE et certaines applications qui sont bien trop complexes, mais GNOME 3 ne me donne pas du tout satisfaction.

Il faudra attendre la sortie de GNOME 3.12 pour que je sois conquis et commence à imaginer le lecteur  de musique de mes rêves.

Au vu du grand nombre de lecteurs audio sous Linux, qu’est-ce qui t’a poussé à te lancer dans le développement d’un tout nouveau projet ?

J’ai d’abord utilisé Musique avec plus ou moins de succès, mais il était très lent, trop lent…  Après avoir étudié le code de ce dernier et trouvé le goulot d’étranglement (tracker), j’ai migré temporairement sous Clementine et commencé à développer Lollypop en reprenant les concepts de base de GNOME Musique.

Concevoir une bonne interface, agréable à utiliser et bien pensée, est une tâche difficile. Quelles difficultés as-tu rencontré, et est-ce que les GNOME Human Interface Guidelines t’ont été utiles, durant ce processus ?

C’est en parti ces règles qui m’ont fait passer sous GNOME. J’aime beaucoup le « look & feel » des applications GNOME et j’ai construit Lollypop autour de ces principes, qui sont assez proche de ce que fait Apple sur certains points, mais avec une contrainte en plus : pas de menu global à l’application. Je trouve aussi que les nouveautés de GTK+ sont vraiment les bienvenues après de nombreuses années de stagnation et permettent d’explorer de nouvelles façons de concevoir une application.

Quelle distribution utilises-tu, et quels sont tes outils de développement ?

Je développe principalement sous Fedora et Debian/Ubuntu. Comme outils, simplement Gedit/Devhelp et Glade.

As-tu suivi le développement de Builder, l’IDE pensé pour faciliter le développement d’applications GNOME ? Penses-tu que ça aille dans le bon sens, et envisages-tu de l’utiliser, à terme ?

Oui, cela va dans le bon sens, mais je trouve dommage que cette étape arrive avant la mise à niveau de Glade qui ne gère pas du tout les nouveautés de GTK+.

J’ai lu sur LinuxFR que tu étais auparavant sous KDE. En tant que développeur, le changement de technologies fut-il aisé ?

Oui, les principes sont les mêmes… Python/GTK+ ou C++/Qt, c’est relativement la même chose, même si Python permet vraiment de développer plus rapidement que C++. Par contre, j’ai trouvé plus de réponses à mes questions sur le web lors du développement de Lollypop que pour mon travail sur KDE…

On reproche souvent à GNOME et ses différentes technologies (Gtk+, GStreamer…), d’être moins bien documentés que certains « concurrents ». La situation est-elle réellement si mauvaise ?

La documentation de GTK+ est toujours moins bonne que celle de Qt, mais les moyens ne sont pas les mêmes. De plus, la documentation des bindings est bien meilleure côté GTK+. C’est surtout la documentation de KDE qui n’est pas au niveau ni de Qt ni de GTK+/GNOME.

Un autre reproche qui revient régulièrement, est de devoir faire de l’orienté objet avec du C. GNOME offrant la possibilité d’utiliser le langage de son choix, en tant que développeur Python d’une application utilisateur, en as-tu souffert ? Est-ce que ça t’a contraint à adapter ta façon de développer ?

Effectivement, je n’aime pas du tout le couple C/Gobject mais cela permet à GNOME d’offrir des bindings à jour pour de nombreux langages via Gobject Introspection, ce qui n’est pas le cas sous KDE. De plus, entre Vala et Python, je pense que personne n’a besoin de faire de l’orienté objet avec du C pour faire une application GNOME.

De toutes les possibilités offertes par la plate-forme GNOME, qu’est-ce qui t’a le plus plu ?

GtkHeaderBar (la barre d’en-tête, ndr) sans hésiter. Une grande avancée. Depuis le temps que je voulais voir une nouvelle façon de faire des applications sous GNU/Linux. C’est la suite logique de mon travail sur KDE. Je ne supporte pas les barres de menus. GNOME a réussi à les reléguer au second rang. Côté KDE, ils veulent faire à terme communiquer le gestionnaire de fenêtres avec l’application, mais du point de vu du développeur cela n’offrira jamais la flexibilité de GtkHeaderBar.

Quels conseils donnerais-tu à un développeur GNOME débutant, qui souhaiterait se lancer dans le développement d’une nouvelle application ?

Commencer par contribuer à un outil existant afin de mieux se familiariser avec l’environnement. Je n’ai pas un énorme niveau en programmation et j’ai beaucoup appris des mes contributions à Compiz et KDE. Il ne faut pas croire qu’il faut être ingénieur pour faire ce boulot. On est sur du haut niveau, je n’aurai pas la prétention de savoir coder Lollypop en C sans GStreamer :)

J’ai cru comprendre que tu t’occupais toi-même de la création de paquets pour Arch, Fedora, Ubuntu… N’est-ce pas trop pénible, quand on sort régulièrement de nouvelles versions ? Pourquoi ne pas avoir délégué cette tâche ?

Une fois Lollypop intégré dans les distributions, je ne ferais plus les paquets… Sauf si j’ai toujours le temps de fournir la dernière version.

D’avoir aujourd’hui autant de distributions et d’environnements de bureau (GNOME, Pantheon, Unity…), rend-il les tests qualité plus nombreux et difficiles ?

Oui pour Unity, car Canonical rejette les paradigmes de GNOME (la barre d’en-tête en particulier). Pour le reste, cela ne change rien, ils sont tous compatibles avec GNOME.

GNOME et Red Hat ont commencé à travailler sur le support des applications sandboxées. L’un des avantages étant de pouvoir permettre à des développeurs tiers de fournir un paquet unique qui tournerait partout, sans avoir à se soucier de la distribution ou de la version de GNOME utilisées par l’utilisateur. En tant que développeur et responsable de paquets, qu’en penses-tu ?

Que c’est une très bonne chose, car il est effectivement chiant de faire des paquets pour toutes les distributions. Reste à voir si la mayonnaise prend, mais d’un point de vue technique ça me semble bien pensé.

Trop d’options et de fonctionnalités rendent souvent les interfaces plus chargées et les applications plus difficiles à prendre en main. Penses-tu être proche de cette limite, ou as-tu encore de nombreuses idées à implémenter ?

Avec la 0.9.30 qui sort demain (à l’heure où je réponds à cette question), j’ai fais le tour, c’est la dernière version avec de nouvelles fonctionnalités avant la 1.0. Après, je rajouterai des fonctions si les propositions me semblent pertinentes.

Un grand merci à Cédric d’avoir bien voulu prendre le temps de répondre à mes quelques questions ;)

Original post of Okki.Votez pour ce billet sur Planet Libre.

Le constat n’est pas glorieux pour la fondation Mozilla en ce moment, fustigée de toute part sur ses choix et ses méthodes de financement. Je reconnais que certains choix sont discutables, mais, crier au loup à chaque fois que la fondation fait quelque-chose cela tourne à l’acharnement. Parmi tout ce que j’ai pu lire, j’ai retenu la même constance lorsque l’on aborde le thème de FFOS, FirefoxOS = ZTE OpenC= résidu de capote trouée, ce qui est complètement faux. En revanche je rejoins les utilisateurs d’OpenC sur le fait que ZTE c’est bien moqué d’eux, nous ne sommes pas loin de l’arnaque à mon sens et pour enfoncer le clou cette trouble affaire où ZTE et LECLERC voulait de la main d’oeuvre gratuite. Mais en cherchant un peu on apprend qu’il existe ou existait d’autres terminaux accessibles en France au moment de la sortie de l’openC. Certains me prendront peut-être pour un fan boy aveuglé, absolument pas je souhaite simplement apporter un regard très subjectif sur l’expérience FFOS.

FFOS me suis depuis dix mois maintenant et même après une petite mésaventure il répond entièrement à mes besoins. Très souvent mis à jour sur la branche nightly, parfaitement utilisable sur la branche stable en 2.2, c’est avec plaisir que je découvre de petites nouveautés ou l’amélioration de fonctionnalités déjà implantées. A la même époque que la sortie de l’openC, il y avait le Flame sur une base Alcatel, téléphone développé par Mozilla avec T2Mobile destiné aux développeurs d’applications ou simplement à ceux qui souhaitent aider Mozilla. Et on pouvait aussi trouver le Revolution de Geeksphone qui a la particularité d’être acheté avec Android ou FFOS.

Avec le Flame, Mozilla souhaitait attirer les développeurs d’applications afin de faire vivre son market. Le but était d’offrir la plus grande diversité matérielle sur un même appareil. Afin que chaque développeur puissent être sûr du bon fonctionnement de son application sur divers matériel. La reconnaissance matérielle était garantie à 100% puisque le cahier des charges venait tout droit de Mozilla. Le deuxième gros avantage est d’avoir un téléphone toujours à jour. Quelle que soit la branche utilisée, stable ou nightly, le téléphone suit les dernières mises à jours avec son lot d’améliorations et de nouveautés. C’est l’argument qui m’a décidé de prendre le Flame. FFOS est très jeune comme système, évoluant très rapidement, par conséquent j’étais sûr de bénéficier de toutes les mises à jour à temps et en heure. Même s’il était destiné aux développeurs son utilisation en téléphone classique fonctionne parfaitement, il est utilisable même sans compétences informatiques. Les bidouilleurs comme moi trouveront toujours à s’amuser avec. Le téléphone était disponible sur un seul site marchand situé aux USA et il fallait compter 30 € de frais de douane pour l’importation en France.

Le Revolution quant à lui est fabriqué par une entreprise Espagnole, on reste dans l’UE donc pas de surprise pour la douane. Geeksphone s’est déjà illustré avec FFOS avec le Keon et le Peak lancés en 2013. Plus destiné au grand public il est proposé soit avec android ou FFOS. Au niveau des mises à jour systèmes on reste soumit à la méthode de publication de Geeksphone, il est moins facile de monter en version qu’avec le flame. D’après ce que j’ai compris il faut à chaque fois compiler sa propre image depuis les sources fournit par Geeksphone. Sur le Flame on peut trouver directement des images prêtes à l’emploi fournit par Mozilla. Pour l’avoir eu en main c’est un joli petit téléphone, plus esthétique que le flame et moins encombrant.

Au niveau prix il est vrai que l’on dépasse les 70€ de l’openC, on est sur du 129€ pour le revolution et 150€ (avec frais de douane compris) pour le Flame, mais au niveau rapport qualité/prix cela reste raisonnable comparé a certain téléphone android du même genre et on retrouve plus de considération qu’avec ZTE qui a abandonné ses clients. Voilà toutes les informations que j’ai glanés lors de mes recherches de l’époque. Malgré cela j’ai longtemps hésité entre les deux. J’avais peur que le Flame ne soit trop gros, encombrant, je ne l’avais vu qu’en photo. Alors que le revolution que j’avais essayé lors RMLL à Montpellier était visuellement plus accrocheur. Mais l’argument des mises à jour m’a convaincu de prendre le Flame. J’ai aussi considéré cet achat comme investissement et non comme une dépense, j’ai cherché s’il s’adapterait à mes habitudes d’utilisation et à mon environnement (owncloud, courriel, etc) avant de sauter le pas. Et au vu des retours que j’ai pu lire sur l’openC je ne regrette pas mon choix. Je ne juge absolument pas les utilisateurs d’openC, certain continu de l’utiliser avec succès mais non sans effort.

Le but de cet article n’est pas de démolir l’openC en démontrant qu’il y a mieux ailleurs, malgré que ce soit le cas, mais de dénoncer cet amalgame entre FFOS et openC qui a beaucoup desservit Mozilla et la crédibilité de FFOS. Alors qu’au final c’est un excellent système lorsqu’il est utilisé sur un téléphone dimensionné pour et avec une réelle volonté de faire un travail de qualité. Qualité qui souvent a un coût, plutôt raisonnable dans cette situation. Malheureusement aujourd’hui le Flame n’est plus disponible à la vente et vu l’actualité autour de FFOS je ne pense pas que Mozilla réitère l’opération avec un Flame 2. Le revolution est toujours disponible chez Geeksphone je compte d’ailleurs en prendre un pour mon épouse. Je suis convaincu que Mozilla a confondu vitesse et précipitation en s’associant avec ZTE, qui pour certainement tenir les délais et le prix annoncé a sorti un téléphone très bas de gamme et non à petit prix. Mozilla à fait de mauvais choix de promotion et partenaire pour FFOS, mais cela n’enlève en rien à la qualité du système. Je curieux de voir ce que va donner l’association avec Orange.

Il y a aussi les détracteurs de FFOS qui disent qu’il a dix de retard, je réponds non il a plutôt dix ans d’avance. L’utilisation du HTML5 les applications en responsive design ainsi aucune applications n’est installée en dur sur le téléphone, ce qui dans un premier temps évite d’avoir des tonnes de processus fonctionnant sur le téléphone. Économie de mémoire, de batterie, appareil plus fluide à l’utilisation. Cela offre aussi une protection de la vie privée, n’ayant pas de processus actifs c’est la garantie qu’aucun processus malveillants ne captent ce qui se passe sur téléphone. Dans un second temps les systèmes IOS et Android nécessitent des applications installées sur téléphone, cela augmente la charge de travail des développeurs, qui doivent assurer la compatibilité pour IOS et pour Android tout en veillant à ce que le site internet reste responsive design. Avec le système proposé par FFOS plus besoin de se soucier de la compatibilité système puisque tout s’exécute depuis le site internet consulté. Les développeurs n’ont plus qu’à se concentrer sur le développement du site tout en . Autre gros avantage FFOS est un système développé par une fondation à but non lucratif avec une communauté très active, ce n’est pas rien, car les objectifs sont complètement à l’opposer d’une multinationale cotée en bourse. L’utilisateur n’est plus le produit.

Pour terminer je comprends que les utilisateurs de l’openC ont gardés un goût amer de cette aventure avec FFOS et ZTE, est-ce une raison pour voir le verre à moitié vide ? Je ne pense pas, car Mozilla nous a toujours apporté des logiciels et qualités, libre, respectant ses utilisateurs.

Original post of Olivier Delort.Votez pour ce billet sur Planet Libre.