PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Okki : En bref : Agenda, GNOME MPV, Machines, Debian, Linphone…

samedi 17 juin 2017 à 19:04

Le lecteur vidéo GNOME MPV vient de sortir une nouvelle version (0.12), qui a droit à un gros travail de réusinage de code ainsi qu’à un portage vers le moteur de production Meson. Mais à côté de ça, les nouveautés concernant les utilisateurs finaux sont plutôt minces. Tout juste pouvons nous noter l’ajout de raccourcis clavier pour pouvoir ajouter fichiers et emplacements à la liste de lecture, l’ajout de filtres (fichiers audio, vidéo, image, sous-titre) dans le sélecteur de fichiers, ainsi que la prise en charge de la spécification MPRIS pour les listes de pistes.

Visarion Alexandru a publié un billet de blog sur l’état d’avancement de la prise en charge des dossiers partagés dans Machines. Fonctionnalité qui devrait donc arriver pour GNOME 3.26.

Debian 9.0 (Stretch) sort aujourd’hui et intègre désormais GNOME 3.22. La précédente version utilisant GNOME 3.14, les utilisateurs de la distribution font un sacré bon en avant et vont découvrir un nouveau centre de notifications, d’innombrables améliorations dans Fichiers (une recherche améliorée, une animation indiquant la progression des opérations, le renommage de fichiers multiples, l’intégration de Google Drive, la nouvelle vue Autres emplacements…), de nouvelles applications (Agenda, Caractères, Livres…), une meilleure gestion du matériel (ajustement automatique de la luminosité de l’écran, utilisation du pavé tactile multipoint…), des paramètres réorganisés, la prise en charge de Wayland, l’intégration de Flatpak et bien plus encore.

Les utilisateurs qui souhaitent en savoir plus peuvent parcourir les notes de version pour les versions 3.16, 3.18, 3.20 et 3.22.

Toujours au sujet de la nouvelle Debian, nous noterons qu’à quelques jours de sa sortie et malgré la période de gel, Debian Stretch a finalement eu droit à l’intégration de dernière minute de la dernière version de WebKitGTK+, le moteur de rendu HTML utilisé par un certain nombre de projets GNOME. Néanmoins, l’équipe de sécurité de Debian ne sait toujours pas si oui ou non ce projet aura droit à des mises à jour de sécurité durant le cycle de vie de la distribution.

Pour sa version 4, le logiciel de téléphonie Linphone a malheureusement décidé d’abandonner la bibliothèque GTK+ utilisée par GNOME, au profit du couple Qt et QML. Le projet sera donc sans doute moins bien intégré à notre plateforme.

On en parlait il y a peu, mais l’intégration des événements récurrents dans l’Agenda se passe plutôt bien (et vite), et c’est désormais au tour des différentes boîtes de dialogue d’être finalement implémentées.

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

Bridouz : Solus, Ikey et Patreon

samedi 17 juin 2017 à 13:00

Parlons bien, parlons Linux, parlons de Solus plus précisément. La nouvelle de la semaine pour la distribution c’est que son fondateur/dictateur Ikey Doherty a annoncé qu’il quittait son boulot chez Intel pour se consacrer à 100% dans le Solus Project.

Beaucoup de questions peuvent émerger :

Solus tourne chez moi depuis plus d’un an maintenant et la distribution a atteint une stabilité exemplaire. Tout fonctionne simplement et la logithèque s’est grandement étoffée en douze mois. Ce qui me laisse penser que la distribution est réellement devenue intéressante à installer pour un utilisateur qui ne souhaite pas se prendre la tête.

La distribution fait partie du Solus-Project initié par Ikey Doherty, développeur précédemment connu pour être un des mainteneurs de LMDE et depuis plus de cinq ans derrière EvolveOS/Solus.

Le monsieur a donc annoncé qu’il allait désormais travailler à plein temps sur Solus, que son projet allait devenir son job dans quelques semaines. Cette annonce implique donc que le projet va avancer beaucoup plus rapidement et la réécriture du DE maison Budgie de GTK vers QT va également pouvoir commencer à avancer.

Il va pourtant bien falloir qu’Ikey gagne sa vie et c’est ici que la communauté vient jouer un rôle dans la vie du projet. Solus, avec sa page Patreon , récolte de l’argent donné par ses utilisateurs et arrive donc à cumuler un équivalent de salaire mensuel.

Le projet a auparavant déjà utilisé cet argent pour la distribution avec l’achat de serveurs, un agrandissement de l’infrastructure nécessaire lorsqu’une distribution grandit. L’équipe avait déjà offert une prime pour un concours de développeur qui arriverait à coder une fonction Alt+TAB en accord avec l’ergonomie globale de la distribution.

J’avais déjà trouvé cette dernière utilisation ingénieuse, car elle impliquait la reconnaissance d’un dev externe au projet pour sa contribution. Et maintenant le projet va pouvoir employer Ikey à plein-temps en lui versant un salaire raisonnable. On pourrait croire que le monsieur utilise l’argent des utilisateurs pour lui-même, qu’il va peut-être pouvoir se payer des vacances aux Bahamas, mais il n’en est point.

Ikey a déjà expliqué dans plusieurs podcasts et dans le billet du blog Solus qu’il profitait de cette opportunité pour réaliser un rêve, porter son projet pleinement en s’y dévouant à 100% sans avoir de contraintes avec un boulot à côté.

J’y vois également une alternative intéressante pour le développement d’un distribution, la communauté a la possibilité de soutenir les devs d’une manière viable. Car on le sait tous mais l’argent est un pilier de notre monde actuel et bien qu’il ne fasse pas tout il permet de vivre décemment.

On a vu que le financement participatif fonctionnait pour des projets divers et varié, Solus est un projet, utile pour certains utilisateurs et son développement ne se résume pas qu’a son propre nombril. On a vu que le DE Budgie s’était vu offrir une saveur officielle chez Ubuntu, que Solus proposait également Mate et GNOME et qu’ils contribuaient avec d’autres devs comme Wimpy, mainteneur d’Ubuntu Mate, pour divers outils comme un menu tel Brisk menu. Linux-drivers-manager fait aussi partie des projets développé par Ikey et qui peuvent servir les utilisateurs d’autres distributions.

J’y vois donc ici un avancement singulier dans l’évolution du monde Linuxien actuel. Soutenir les développeurs est essentiel car bien qu’étant nombreux ils ne faut pas oublier sue principalement ils contribuent sur leur temps libre et que parfois il est compliqué de se libérer du temps pour faire évoluer une distribution.
Patreon est en cela intéressant car il donne un pouvoir d’action et de soutiens de la part des utilisateurs aux équipes maintenant une distribution ou tout autre projet.

Pas d’implication commerciale là-dedans ni de part de marché à conquérir, maîtriser et tirer profit. Ici il s’agit de soutenir une vision de l’informatique, une initiative servant des utilisateurs inconnus. Je suis très excité de voir ce sue ça va donner et je suis content qu’un mec développant quelque-chose le dépassant puisse être soutenu de la sorte pour élaborer un projet servant l’informatique.

Gravatar de Bridouz
Original post of Bridouz.Votez pour ce billet sur Planet Libre.

Thuban : Mise à jour d'owi : OpenBSD Wifi manager

samedi 17 juin 2017 à 09:09

Je met à jour le gestionnaire de connexion wiFi pour OpenBSD après y avoir ajouté quelques éléments et simplifié le code :

aperçu de owi

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Articles similaires

Benoît Boudaud : Python : classes et méthodes (partie 1), avec un peu de menuiserie en prime.

samedi 17 juin 2017 à 07:00

En programmation orientée objet (POO) et notamment dans le langage Python, tout est objet ! En fait, c’est un peu comme dans le monde réel… Nous sommes entourés d’objets de toutes sortes.

Ces objets virtuels sont instanciés par des classes. Une classe, c’est d’abord un type d’objet. Par exemple le nombre entier 23 est un objet de type ‘int’, c’est-à-dire instancié par la classe ‘int’ :

print(type(23))

Résultat : class ‘int’

Et ce qui est trop méga kisscool, c’est que Python autorise n’importe qui à définir ses propres classes et à les lancer en production.

Une classe se déclare en utilisant le mot-clé class suivi du nom que le programmeur lui a donné. Par convention, le nom d’une classe commence toujours par une majuscule :

class Truc(object):

Elle hérite des caractéristiques de la mère de toutes les classes fondamentales, à savoir object (entre les parenthèses). Notez bien qu’en Python 3, cette indication est devenue facultative.

Cette classe baptisée Truc (pour l’exemple) permet donc d’instancier de nouveaux objets sur lesquels on applique différentes méthodes.

Les méthodes

Tout comme une fonction, une méthode se déclare avec le mot-clé def. Il existe toutefois deux différences majeures entre les fonctions et les méthodes :

  1. Une méthode est toujours encapsulée dans une classe, c’est-à-dire déclarée et définie à l’intérieur d’une classe.
  2. Contrairement à une fonction qui peut n’avoir aucun paramètre, une méthode compte toujours au moins un paramètre qui est, par convention, la référence d’instance self.

Instancions un meuble de bibliothèque virtuel

Ce que je suis en train de vous raconter est un peu abstrait voire totalement abscons… Alors avant de manipuler les classes et les méthodes, notamment avec le module Tkinter, prenons un peu de bon temps et amusons-nous  à créer virtuellement un objet de notre quotidien, en l’occurrence un meuble de bibliothèque.

biblio

Pour ce faire, nous allons définir une classe ElementsDeMeuble() qui va nous permettre de produire les différents éléments qui composent un meuble de bibliothèque, à savoir sept étagères et deux montants. Les étagères et les montants seront donc des objets de type ElementsDeMeuble().

Allez, c’est parti! Définissons la classe :

class ElementsDeMeuble (object) :
    """Production des différents éléments qui, une fois assemblés,
       composeront le meuble."""

    def __init__(self, largeur = 0, longueur = 0, quantite = 0)
        """Définition de la méthode constructeur qui se déclenche
           automatiquement lorsque la classe est activée.
           Elle est dotée de paramètres par défaut qui permettent
           d’éviter de générer une erreur (largeur = 0, etc...)."""

        # Création des attributs d’instance self :
        self.largeur = largeur    # en millimètres
        self.longueur = longueur  # en millimètres
        self.quantite = quantite

    def debiter(self):
        "Débit des éléments"

# Création des différents objets:
etagères = ElementsDeMeuble(1000, 300, 7)
etagères.debit() #Application de la méthode debit sur l'objet nouvellement créé.

montants= ElementsDeMeuble(2000, 300, 2)
montants.debit()

Nous obtenons deux montants de 2000 mm de longueur et 300 mm de largeur ainsi que sept étagères de 1000 mm de longueur et 300 mm de largeur.

Maintenant que nous avons tous nos éléments, nous allons pouvoir créer l’objet meuble de bibliothèque. Pour ce faire, nous allons définir la classe Meuble(). Notre meuble de bibliothèque sera donc un objet de type Meuble() :

class Meuble (object) :
    "Assemblage des différents éléments du meuble."

    def __init__(self, etageres = 0, montants = 0, trous = 0, vis = 0)
        "méthode constructeur"
        self.etageres = etageres
        self.montants = montants
        self.trous = trous
        self.vis = vis

    def percer(self):
        "Usinage des éléments"

    def visser(self):
        "Montage des éléments"

# Création de l'objet meuble de bibliothèque:
meuble_bibliotheque = Meuble(étagères, montants, 26, 26)

# Application des méthodes
# percer et visser sur l'objet nouvellement créé:
meuble_bibliotheque.percer()
meuble_bibliotheque.visser()

Et le résultat, c’est que nous obtenons au bout du compte un meuble de bibliothèque certes virtuel mais tout à fait fonctionnel!

Créons une interface graphique avec la bibliothèque Tkinter

Tkinter est une bibliothèque graphique libre pour Python  permettant de créer des objets, en l’occurrence des interfaces graphiques, par instanciation de différentes classes. Tkinter signifie Tool kit interface.

Il faut tout d’abord télécharger Tkinter  en entrant la commande suivante dans un terminal:

sudo apt-get install python3-tk

Ouvrons l’éditeur de texte Gedit et écrivons les premières lignes de code :

#!/usr/bin/env python3
# -*- coding: utf8 -*-

from tkinter import*

Ligne n° 4 : Importation de la bibliothèque Tkinter

Complétons notre code :

#!/usr/bin/env python3
# -*- coding: utf8 -*-

from tkinter import*

main_window = Tk()
main_window.mainloop()

Ligne n° 6 : Création de l’objet main_window (= fenêtre principale) par instanciation de la classe Tk(). À ce stade, si on exécute le programme, nous n’obtenons rien du tout!

Ligne n° 7 : Il faut en effet appliquer la méthode mainloop() sur l’objet main_window pour déclencher le réceptionnaire d’événements et ainsi matérialiser la fenêtre. Voici le résultat obtenu:

fen_1

Rajoutons un widget de type bouton nous permettant de quitter l’application. Pour cela, nous allons créer un objet quitter, par instanciation de la classe Button(). Nous avons la possibilité de lui passer plusieurs paramètres nous permettant de choisir la taille et la couleur du bouton ainsi que la couleur du texte :

#!/usr/bin/env python3
# -*- coding: utf8 -*-

from tkinter import*

main_window = Tk()
quitter = Button(main_window, width = 20, height = 5,\\
          text = 'quitter', bg = 'green', fg = 'white',\\
          command = main_window.quit)
quitter.pack(padx=60, pady=40)
main_window.mainloop()

Lignes n° 7, 8 et 9 : Création de l’objet quitter par instanciation de la classe Button(). Nous lui passons plusieurs paramètres qui sont :

À ce stade, si nous exécutons le programme, le bouton n’apparaîtra pas et c’est tout à fait normal car il faut d’abord appliquer une méthode qui va placer le bouton dans le widget parent. C’est ce que nous faisons à la ligne n° 10.

Ligne n° 10 : Application de la méthode de placement pack() sur le widget quitter avec les paramètres padx et pady. padx réserve un espace à droite et à gauche du widget tandis que pady réserve un espace en haut et en bas.

Et le résultat, c’est un joli bouton tout vert qui ferme l’application lorsque nous cliquons dessus!

fen_2


Gravatar de Benoît Boudaud
Original post of Benoît Boudaud.Votez pour ce billet sur Planet Libre.

Jean-Baptiste Holcroft : Measuring success - l10n/language

samedi 17 juin 2017 à 00:00

As I invite each of us to use the native language when blogging, here is my first english message for a very late answer to Brian's Fedora Magazine blog post: Measuring Success.

There is many aspects we can measure in a distribution, we can measure achievents of objectives for particular kind of targets (main Fedora products, spins and specific builds), but here I would like to see something else : language support. Like packaging, in impacts every aspects of Fedora, but unless packaging, this is something we can't easily handle on our own (packaging is part of the "Distribution world", language support is part of the "upstream world"). Maybe, as a consequence, we don't have any tools to monitor/manage/... it.

Please note I use language support as a whole, including both i18n and l10n as they are bound together. You can't translate a software if it's not internalized and there isn't much interest to internalized it if you don't translate it. Also, Fedora sometimes use g11n, wich is a meta group for i18n, l10n, language testing and tooling.

Here are my assumption:

For easier adoption and consumption, software need to be translated and to have quality resources in local languages.

Why? In its Internet Health report, the Mozilla foundation and a number of researchers evaluate that 52% of online resources are in English while only 25% of the planet’s inhabitants understand it. A restricted proportion of these can use it as a work language and be effective with it.

How? By using open standards, clear tools and processes and local communities who translate the software and evangelize it.

Where? Emblematic free and open-source software projects are translated, from the Firefox browser to the LibreOffice suite, the GNOME desktop or VLC player; all of these tools are using the same techniques and practices to reach an advanced level of localization and of exclusive local content.

However, translators are undervalued, ill-equipped and insufficiently structured, which tends to make their action not very effective.

Even when they care about it, FLOSS projects do not know how to interact with language communities.

Projects managers are often fine experts, with a high level of education and fluent in English.

Comfortable with English speaking communities, they tend to shy away from localization issues.

Focused on product delivery, the impacts of technical choices on localization are often unknown to them.

Open-source tools are structured by project, from development to inclusion in distributions, in containers and now in Flatpack. Nevertheless, users like translators use tools across contexts, consuming translations through dozens of projects.

Improvement of language support quality requires therefore improvement of various software and a strengthening of practices.

At most, 15% of (gnome) software descriptions are translated in French, whereas 10% of software might be translated in French, which has a significant community (2nd non-English Wikipedia community in number of active contributors).

How to help translator communities to be efficient?

What sources can we get these information from?

Flock

This is quite a lot of subjects to discuss about at Flock! If you feel like helping, you're really welcome!

Gravatar de Jean-Baptiste Holcroft
Original post of Jean-Baptiste Holcroft.Votez pour ce billet sur Planet Libre.