scorpio810 wrote:

Je ne comprend pas pourquoi tu veux cette variable dans le widget propriétés de la sélection

car c'est une info à part entière, au même titre que "localisation".

scorpio810 wrote:

%M est renseigné dans les propriétés du cartouche de ton folio champ "installation" plus tard groupe fonctionnel, donc %M est lu depuis le cartouche du folio encours et on peut l'utiliser dans les formules de label.

oui mais cela ne concerne que le folio.
En premier lieu, l'info "groupe fonctionnel" du folio est destiné à ordonner le folio dans une arborescence mais cette focntion n'existe pas (pas encore ?) car le panel "projets" n'a pas (pas encore ?) été revu pour afficher une arborescence, par exemple :

=GF1
      +LO1
            1
            2
            3
            101
            102
      +LO2
            1
            2
=GF2
      +LO1
            11
            12
            13

Pour l'instant, on peut entrer les valeurs =GF1, =GF2, +LO1 et +LO2 dans les infos cartouches, mais le panel n'affiche que les "labels" de folio, c'est-à-dire cela :

1
2
3
101
102
1
2
11
12
13

Si, par exemple, sur le folio =GF2+LO1/11, je dois câbler dans un circuit un relais qui appartient à =GF1, il faut clairement que je puisse entrer cette info dans l'identification du relais. Et donc, il me faut un champ "groupe fonctionnel" dans les propriétés de l'élément.
Et, en plus, si ce même relais n'est pas dans +LO1 mais dans +LO2 alors là aussi il faut que je rentre cette info dans ses propriétés. Mais dans le cas de la "localisation", c'est déjà faisable, vu que le champ correspondant existe déjà dans le widget.

scorpio810 wrote:

et on peut l'utiliser dans  les formules de label.

Pas moyen d'utiliser ca dans les formules. Il faut que l'info sorte dans sa propre colonne dans l'export csv.

...Et donc, dans le widget "Propriétés du folio", il faut effacer le nouveau champ "groupe fonctionnel" et renommer "installation" en "groupe fonctionnel".
Idem pour les pages sommaire : pas besoin d'implémenter une nouvelle colonne, il suffit de renommer "installation" en "groupe fonctionnel".

Dans le widget "propriétés de la sélection", on a avait pas encore le champ "installation" mais tu viens de créer "groupe fonctionnel" donc c'est bon pour ce widget maintenant.

Désolé pour ce basar nomicons/blush .
Cela vient du fait qu'autrefois je parlais d' "installation" alors que maintenant je pense qu'il vaut mieux traduire par "groupe fonctionnel".

@ Laurent

merci pour ta réactivité nomicons/cool .

Par contre, je pense que je t'ai un peu emmêlé les pinceaux :

Le "groupe fonctionnel" ne manquait que dans le widget "propriétés de la sélection". A part ca, ce champ avait déjà été implémenté dans les cartouches. C'est le champ qu'on avait nommé "installation".
Pour les formules de labels, c'est la variable %M. Pourquoi elle a été nommée "Machine", j'en sais rien !
Bref, on a quelques problèmes de terminologie.

Faut faire attention avec les traductions.
En allemand, l'identifiant [=] s'exprime par "Anlage".
Ca se traduit littéralement en francais par "installation" mais je pense pas que ce soit le bon terme car la signification est trop vaste en francais. "Groupe fonctionnel" traduit mieux ce qui est réllement signifié en allemand.
Partout où on a "installation" dans la GUI, il faut le changer en "groupe fonctionnel".

Si je récapitule :

identifiant =
[DE] Anlage
[FR] Groupe fonctionnel
[EN] Plant

identifiant +
[DE] Ort
[FR] Localisation
[EN] Location

scorpio810 wrote:

"<li>%{machine} : nom du groupe fonctionnel du projet</li>"

La variable devrait s'appeler %{plant}. On la traduira par :
[FR] Groupe fonctionnel
[DE] Anlage
[EN] Plant
"Nom du groupe fonctionnel du projet", ca veut rien dire. On peut avoir 50 groupes fonctionnels différents dans un seul projet. Cette info n'est pas liée directement au projet.

scorpio810 wrote:

Ok, je verrai ça demain, je rajoute ce champ entre quel champs ?

Entre "numéro interne" et "localisation".
Ne pas oublier l'export csv dans l'implémentation du nouveau champ !

Je sais pas si vous voulez un jour mettre un peu d'ordre dans le widget propriétés de la sélection, mais je pense qu'on devra un jour ou l'autre ranger un peu...
Grosso-modo, on a 3 types d'informations :

1. les champs servant à l'IDENTIFICATION des composants :
[Formule du label]
[Label] (qui devrait s'appeler "repère" nomicons/whistling )
[Groupe fonctionnel]
[Localisation]

2. les champs servant à la DESCRIPTION des composants :
[Commentaire]
[Fonction]
[Tension / protocole]
[Bloc auxiliaire 1]
[Bloc auxiliaire 2]

3. les champs relatifs aux DONNÉES D'ARTICLE (si pas d'article, alors tous les champs ci-dessous restent vides)
[Description textuelle]
[Numéro d'article]
[Numéro de commande]
[Numéro interne]
[Fabricant]
[Fournisseur]


scorpio810 wrote:

C'etais le cas avant la 0.5. voir commit 4206 QETApp::settings() -> QSettings settings;
On n'avaient pas prévu, ce type d'utilisation...

Joshua wrote:

Oui mais on avais décidé de passer par le registre, car c'est la conf par défaut de Qt et windows.

nomicons/getlost oui, je m'en souviens. A l'époque, le passage au format natif de QSettings a été vu comme une avancée.
Ben désolé... Moi aussi j'avais pas prévu le problème posé par Windows et sa base de registre.

Joshua wrote:

Mais c'est bon, j'ai regardé hier soir la doc des QSetting, et j'ai trouvé une solution qui devrais être plutôt simple à coder, compatible pour tous les OS.

Super ! Surtout le fait de ne plus avoir les différents OS pour nous [s]emmer..[/s] embêter !

Joshua wrote:

Par la même occasion, comme les conf seront dans un fichier (un par conf) tu pourra facilement, par exemple, la donner à ton client si il a besoins de reprendre par la suite les schémas.

Ca aussi, c'est super pour les utilisateurs. Portabilité maximale nomicons/rolleyes. En général, les clients sont ravis car ils n'ont pas à se battre avec la config pour que tout marche correctement.
C'est clairement ce genre de fonctionalités qui font un jour changer les gens d'un système proprio à un système ouvert.

Joshua wrote:

Tu fait la reprise de schéma sur QET, c'est une demande de ton client et/ou QET est suffisamment mâture pour le type de schéma que tu doit faire?

C'est une demande du client qui dispose de schémas uniquement en pdf (générés par Eplan) et qui souhaite les modifier à sa sauce tout en se passant d'Eplan. Bref, il veut une nouvelle base sous QET pour pouvoir travailler les schémas.
Les schémas sont réalisés selon l'IEC 81346 (avec groupe fonctionnel = et localisation +) est c'est pas facile-facile de tout reprendre sans casser les labels existants.
Mais pour l'instant ca va, j'ai pas eu de gros obstacle insurmontable.
A part peut-être le fait qu'il manque toujours le champ "groupe fonctionnel" dans le widget propriétés de l'élément. Je contourne le problème en utilisant "champ auxiliaire 1" mais ce serait mieux d'avoir un champ dédié à cela (exactement comme quand t'as implémenté le champ "localisation").

Pour rappel, dans un schéma selon IEC 81346, les composants sont totalement identifiés avec les 3 variables :
[= groupe fonctionnel] + [+ localisation] + [- repère].
Le relais =G1+A1-K1 n'est pas le même que =G2+A1-K1 bien que tous les deux aient le même "label" -K1.
Joshua a écrit:

Joshua wrote:

Après c'est tout à fait faisable, mais demande du boulot car en regardant la doc de QSettings j'ai rien trouvé de rapide sur le sujet (sauf erreur de ma part).

Et y'a pas du tout moyen d'enregistrer la config QET dans un fichier sous Windows ?
J'ai vu qu'on peut aussi utiliser QSettings pour enregistrer dans un format custom, par exemple un fichier xml :
http://doc.qt.io/qt-5/qsettings.html#registerFormat
J'ai bien conscience que ca demande du boulot, c'est clair.
Mais comme j'écrivais dans mon post précédent, cette fonctionalité fait partie des "fonctions pro" : il faut pouvoir changer rapidement toute la config pour jongler entre différentes exigences, en l'occurence pour différents clients.

Remonté d'un petit bug :

Dans l'éditeur d'élément, bouton "Editer les propriétés de l'élément", puis onglet "informations".
Les valeurs entrées dans le tableau ne se laissent pas effacer.

Par exemple :
je rentre la valeur "Leroy Somer" dans le champ fabricant et j'enregistre l'élément.
Ensuite, je fais "enregistrer sous" pour créer un nouvel élément à partir du précédent.
Je retourne dans le tableau pour effacer "Leroy Somer". J'enregistre et je ferme l'éditeur.

J'insère l'élément dans l'éditeur de schéma et la valeur "Leroy Somer" est toujours présente dans le champ fabricant.
Si j'ouvre l'élément à nouveau avec l'éditeur d'éléments, la valeur "Leroy Somer" reste effectivement dans le tableau. Pas moyen de l'effacer.

J'ai fraîchement acquis un deuxième client (francais cette fois) pour qui je dois faire des reprises de schémas vers QET.
Je dois alors maintenant "jongler" entre 2 clients qui ont des besoins différents et qui utilisent donc des configurations de QET complètement différentes.

Pour me faciliter un peu la tâche et pas tout dérégler quand je passe d'un client à l'autre, j'ai créé 2 fichiers qelectrotech.conf dans /home/nuri/.config/QElectroTech. Par exemple :
qelectrotech.conf_A et qelectrotech.conf_B

Si je veux travailler pour client A, je charge le qelectrotech.conf correspondant (je le renomme) et si je veux travailler pour client B, je renomme l'autre fichier conf avant de lancer QElectroTech.

Maintenant je pense que tout le monde voit venir ma proposition avec ses gros sabots :

Est-ce qu'il serait envisageable d'avoir une option dans le menu Configuration --> Configurer QElectroTech --> Général pour charger une méta-configuration sous forme de fichier conf ?
Je sais bien que le changement à la volée ne sera pas possible et qu'il faudrait toujours passer par un nouveau démarrage de QET mais cela pourrait être bien pratique quand même !

C'est définitivement une proposition du registre "utilisation professionelle de QET".

scorpio810 wrote:

Attention donc avec certaines polices exotiques, certains y trouverons leur compte pour embellir leurs schémas, hein Nuri...

J'utilise la police Arimo car elle ne pose aucun problème sous Linux, est libre et a exactement la même métrique qu'Arial.

sudo apt install fonts-croscore

.

Quand j'utilise Arial directement sous Linux, je sais pas pourquoi mais QET me met tous les textes en Arial Bold nomicons/pinch .
J'ai pas trouvé d'où cela venait, aucune idée...

Par contre, quand je livre un fichier *.qet à ma clientèle sous Windows, je remplace "Arimo" par "Arial" avec XML Copy Editor.

Moi ce qui m'intéresse, c'est qu'on puisse utiliser une police qui ait le même rendu sous tous les OS pour éviter les décalages et les empiètements qui font dégueulasse et qui rendent certains textes illisibles.
L'idéal serait que QET embarque une petite panoplie de polices libres avec lui et puisse les déployer indépendamment de l'OS.
Disons une petites dizaines de polices, ca devrait largement suffire.

Et pour ceux qui ont besoin de plus, on leur permet de faire des surcharges en utilisant les polices installées dans l'OS en question, comme actuellement avec les options de police implémentées par Laurent.

Petite proposition d'amélioration :

lorsqu'on ajoute un nouveau texte dynamique à un élément, ce serait bien si la largeur du texte était fixée à -1 par défaut.
C'est, je pense, la configuration qui fonctionne le mieux pour la plupart des cas (textes sur une ligne dans 95% des cas).

Pour l'instant, le défaut est à 0 et cela provoque un comportement qui n'est pas facile à comprendre au premier abord (faut faire joujou quelques minutes avant de capter les différences).
Le réglage à -1 est aussi celui qui fonctionne le mieux avec l'option d'alignement.
Le comportement de l'option d'alignement est assez dépendante du réglage de largeur. Pour les débutants, c'est assez déroutant et, si on n'expérimente pas assez, on a même l'impression que le comportement d'alignement est bogué.

Hallo julianpe,

Der Begriff und die Funktion "Gerätekasten" gibt es in QElectroTech nicht.
Ich glaube es war Mal in Diskussion, ob etwas Ähnliches entwickelt werden sollte oder nicht. Bis jetzt habe ich keine Fortschritte in dieser Richtung gesehen. Ich denke also nicht, dass es in der Version 0.7 auftaucht. Vielleicht später...

Aber Gerätekasten werden in QET auch nicht wirklich benötigt. Wieso, warum...:
Zeichne deine 5-polige Mennekes Steckdose als neues Bauteil und füge sie in deine Schaltung ein.
Solltest du später merken, dass z.B. der Abstand zwischen den Klemmen zu klein ist, dann kannst du eine zweite Variante davon erstellen.

In Gegenteil zu Eplan hast du in QET den kompletten Zugriff auf alle Bauteile bzw. Symbole, die in deinem Projekt vorhanden sind.
Im Panel "Sammlungen" (Hauptmenü --> Einstellungen --> Anzeige von Werkzeugsleisten --> Sammlungen) wird die Bauteilsammlung von deinem Projekt angezeigt, ganz oben im Baumverzeichnis. Von da aus kannst du Bauteile verändern und die Änderungen betreffen nur die Bauteile von deinem Projekt, nicht die von deiner Benutzersammlung.

Prinzipiell ist es sehr ratsam, Breite und Anordnung von Bauteilen (Symbolen) gut zu überlegen, BEVOR man sie in die Schaltung einfügt und BEVOR man sie verbindet mit Leitern. Im Nachhinein geht es auch, ist aber manchmal etwas mühselig, da man alle Verbindungen neu erstellen muss.

Ouuulllllaaaaaa...  nomicons/w00t  J'allais l'oublier celle-là :

Joshua wrote:

Une chose que j'aimerais faire (mais y'a plus important à l'heure actuel) c'est revoir les .elmt afin de coller à 100% avec le svg sur tout ce qui est graphique, ce qui permettrais entre autre d'ajouter facilement des nouvelles chose (d'un point de vue graphique) sans se prendre la tête sur comment l'implémenter dans le dans le .elmt, car ce sera forcément documenté dans le format svg.
Un autre avantage, c'est qu'il serais possible de crée un élément depuis un éditeur svg, puis de l'importer dans QET sans convertisseur, étant donné que ce serais le même format.
Et pour finir, des convertisseur dxf->svg on en trouve même en ligne.

Alors ca, ce serait vraiment le pied ! nomicons/kissing
Plus besoin de convertisseur. Attention, je respecte le boulot énorme de Ronny mais le convertisseur a ses limites, notamment avec les arcs de cercles et les polylignes, les blocs, etc... Rien d'insurmontable mais il faut parfois être très bricoleur pour arriver à ses fins nomicons/happy .
Cela permettrait aussi d'importer plus facilement tout graphique vectoriel embarqué dans un pdf (par exemple, des morceaux de schémas Eplan nomicons/whistling ), de travailler avec la puissance d'Inkscape et d'importer directement dans QET.

clabacchio wrote:

Editing the schematic file as text, directly copy-pasting the text field in the xml structure of every component

It's obviously the most effective way at the current time to achieve what you want to do.
But it's risky! nomicons/unsure
Make a backup of your project before you tweak its xml content.

@clabacchio

If you add the dynamic text from the diagram editor it won't work!
Because this is the purpose why "dynamic texts" have been implemented: to give you the possibility to add some text on a particular instance of an element. That's the reason why they had been named DYNAMIC texts.

If you want that your changes are made in all instances of the element, do this:

Nuri wrote:

Make a backup of your project before !!!
you go to the "Collections" panel
you open your project (at the top of the tree directory of the collections), then / imported items ... until you find your component.
Then double click on the part to edit it.
Make the changes you want to make.
Save, close component editor.
Save and close your project.
Reopen your project and see if the changes are visible.

But I'm not sure it will work...
It works very good with STATIC texts.

@Stebo:
ich wollte nicht "élément" mit "Symbol" übersetzen, da die QElectroTech Bauteile eigentlich mehr als Symbole sind.
Sie können irgendwas Grafisches sein, unter anderem auch Symbole, aber eben nicht nur (eine Tabelle, ein Text, usw.).
Ok, dann bleiben wir bei "Bauteil" für die deutsche GUI.
Ich dachte, "irgendein Teil, um irgendwas zu bauen" (also ein Bauteil) passt gut dazu nomicons/grin .

@seyt

die Bauteile unter QET Sammlung / Elektrik / Allpolig / Verbindungen sind sehr alt und entsprechen nicht mehr so richtig dem aktuellen Stand von QElectroTech.
Sie sind teilweise unvollständig und bestehen zum Teil nur aus Anschlüsse (die roten Balken mit dem blauen Ende).
Also in die Benutzersammlung kopieren und mit Linien vervollständigen. Dann passt es auch mit dem Ausdruck und man muss nicht die Option "Anschlüsse zeichnen" anwählen.

Zu "richtungsweisenden Verdrahtung" sagt man auch "Zielverdrahtung" und es sind die Bauteile, die man unter QET Sammlung / Elektrik / Allpolig / Verbindungen findet:
- Combine
- Splice
- Thru left
- Thru right

@ Calypso

du nutzest ja das Wort "Element" (wie im Französischen) und nicht "Bauteil".
Gibt es einen Grund dafür?
Soll ich Software-umgreifend das Wort "Bauteil" durch "Element" ersetzen?
Welches Wort macht im Deutschen am Besten Sinn?

Danke für die Info!
Es sieht so aus, als es ein kleiner Bug wäre.
Ich leite die Info an den Entwickler weiter.

scorpio810 wrote:

Il est déjà empaqueté puisque disponible sur https://pypi.org/project/qet-tb-generator/#files, l'user a juste a installer python sur son OS lancer les commandes fournies par Raul.

désolé, me suis mal exprimé.
Si j'ai bien compris, on peut aussi empaqueter le langage avec le programme, ce qui aurait quelques avantages :
- l'utilisateur n'a plus rien à installer, simplement faire tourner l'éxécutable
- on évite les problèmes de compatibilité de version de Python
L'inconvénient, c'est la taille de l'appli qui devient assez conséquente.

Il y a quelques semaines de cela, je m'étais intéressé à Python pour voir si je pouvais porter ma macro LibreOffice vers ce langage. J'en aurais aussi profité pour rendre la macro (le script Python, en l'occurence) plus universelle et donc utilisable pour tout le monde (d'avantage configurable et moins portée sur mes propres besoins). Mais en fait, faut tout ré-écrire... nomicons/getlost

J'avais donc créé un fichier *.ui avec QtDesigner pour faire la petite GUI du programme.
Ensuite je l'ai convertie en Python en utilisant PyQt5.
C'est super pratique : on peut très rapidement créer une GUI sans faire une ligne de code C++. Et ensuite, toutes (mais j'en suis pas sûr) les classes Qt et tous les widget Qt peuvent être utilisés par le script Python. Donc facile de faire un FilePicker pour choisir le fichier csv.
Je précise que je n'ai pas porté la macro LibreOffice vers Python. J'ai simplement créé une GUI pour faire quelques essais.

Après, j'ai essayé d'empaqueter le tout avec PyInstaller. Cela a fonctionné : j'avais donc un petit éxécutable Python avec toutes ses bibliothèques. Puis après, ca a commencé à devenir plus difficile car j'ai remarqué que l'appli ne tournait que sur ma machine, donc j'ai dû manquer quelque chose pendant l'empaquetage (visiblement, le langage Python n'était pas empaqueté dans l'éxécutable).

Puis, finalement, j'ai laché l'affaire car, même en portant vers Python, le script resterait assez lourdingue pour l'utilisateur vu qu'il faut toujours passer par la collection utilisateur pour lui fournir les éléments nomenclature. Et il faut lui demander où elle se trouve, où est le fichier csv, etc.
Bref... Pour moi, c'était trop peu de gains pour beaucoup de travail.

Si un jour l'édtition de nomenclature était intégrée à QET, y'aurait moyen de faire ca en 2 clics de souris (sous-réserve d'utiliser un fichier config).

rpirela wrote:

Is there any plan or possibility to develop an utility to import these macros to qelectrotech?

Yes, you can! Write to Eplan something like:

"dear Friedhelm Loh Group, dear Eplan developers,

your software Eplan P8 is incredible but I much prefer use a libre and open source software like QElectroTech.
So... It would be very nice if you could open the XML format of your EMS macros and release it under the GPL license so that the open source community can understand what you've coded and then write a converter to import everything into QElectroTech.
This way, I would never again use your very good (but very expensive) software.

regards,

Rafael"

rpirela wrote:

If that were done the software could have access to a huge data base of products.

With a lot of mistakes and with innumerable features that you never will use, or ever have need...

galexis wrote:

Je pense que les modules externes doivent permettre d'évaluer les caractéristiques nécessaires à un outil intégré, mais doivent finir par disparaître tôt ou tard par simplicité pour l'utilisateur et les gens qui en font l’assistance.

Je pense que tout le monde est d'accord avec cela.
Mais, au final, les problèmes sont toujours les mêmes et d'ordre pratique :
le manque de bras et de temps. Donc il faut des roues de secours. Souvent, ce sont des scripts ou des outils externes.
Faut rester réaliste, c'est déjà exceptionnel le travail réalisé par Joshua et Laurent à eux seuls.

Pour en revenir au générateur de Raul :
ce sera déjà plus facile à mettre en oeuvre si le script Python était empaqueté avec toutes ses bibliothèques pour en faire une vraie application à part entière (avec PyQt5 ou un truc dans le genre).
Mais bon... avec ca, on aura un script qui pèsera plus que QET lui-même, mais c'est pas trop grave par les temps qui courent (quand on voit ce que pèsent certaines applis Windows...).


De toute facon, la gestion des bornes et des câbles, c'est le plus difficile à venir à mon avis.
Surtout les câbles !
Quand je vois parfois le temps que je passe à configurer des câbles sous Eplan, j'ai l'impression d'aller plus vite en faisant tout à la main dans QET.
Donc, des automatismes, je veux bien, mais il faut que cela se répercute en gain de temps pour l'utilisateur sinon quel est l'intérêt de s'embêter avec des usines à gaz ?...

Quand Joshua en sera aux câbles, j'essaierais de lui faire part de quelques réflexions.
Mais j'avais déjà dis que tant que les connexions (bornes rouges et bleues) n'auront pas leurs propres textes, ce sera difficile de générer des borniers et câbles en automatique.

galexis wrote:

C'est dommage que pas plus de personne ne s'expriment sur leur vision de QET et leurs besoins, j'ai un peu l'impression d'être le seul. Il est vrai que je fais partis des utilisateurs exigeants...

Ben moi j'ai l'impression d'avoir déjà exprímé la plupart des grosses demandes durant les 3 dernières années :
- les bornes et câbles
- l'édition nomenclature
- les entrées/sorties API
- la gestion des données d'articles
- la norme IEC 81346
Voilà pour les plus gros morceaux.

nuri wrote:

Depuis le temps que je vous tanne le cuir avec ces machins...

Pas toujours facile de trouver le compromis entre "faire le gros lourd" et "faire avancer le logiciel"
nomicons/smiley-green

@ fredhuber:

Schau mal in der QET Bauteilsammlung unter:
/Elektrik/Herstellerartikel/BWO/VIO 64
die Bauteile Kanal (Verweis) und Übersicht (Verweis) kann man zusammen linken.
Es sind eigentlich nichts anderes als Folienverweise, die zu einem anderen Zweck modifiziert wurden (zum Verweisen von SPS E/A'S).

Damit solltest du deine FU Verweise auf der gleichen Art und Weise ziemlich leicht kreieren können.

Juste une petite proposition au passage :

Quand on charge un element_text_pattern peut-être faudrait-il simplement ajouter une petite checkbox "écraser les textes existants". Si la checkbox n'est pas coché, on ajoute le element_text_pattern aux textes déjà existants (fonctionnement actuel).

christophe.lemaitre wrote:

Autre question, existe t-il une astuce pour utiliser une cartouche fournie par mon client en dwg?

dwg, c'est mort, c'est un format propriétaire mal aimé dans le monde du libre, et pour cause...
De plus, dans QET, les cartouches ne peuvent créés uniquement en format natif en utilisant l'éditeur intégré pratique et bien fait.
L'astuce consiste donc à refaire le cartouche avec l'éditeur en s'inspirant du cartouche original.

123

(16 replies, posted in Bar Fourre-tout)

C'est bien ce qu'il me semblait :

If install Debian
then stable
else "tu vas ramer comme un malade"

nomicons/alien
nomicons/laughing

Je confirme, Timeshift c'est vraiment bien quand on a système toujours au bord du gouffre.nomicons/dizzy
Timeshift est maintenant livré d'office avec Mint car ils ont laissé tomber leur politique étrange de mise à jour.

124

(16 replies, posted in Bar Fourre-tout)

...Juste pour die que mon nouveau système productif est maintenant Debian Stretch (stable) avec le bureau Gnome Shell.
Adieu Unity et Ubuntu, snif...
Après avoir essayé Ubuntu 18.04 et Linux Mint 19 Cinnamon, j'ai préférer me mettre enfin sous Debian.

J'ai installé QElectroTech v0.7 dev en tant que programme principal.
J'utlise l'AppImage v0.6 pour ouvrir les projets déjà réalisés sous cette version.

Encore un grand merci à Laurent pour avoir fait les Appimages nomicons/smile 
C'est vraiment top pour avoir plusieurs versions de QET sous Linux sans se prendre la tête et, surtout, cela facilite grandement la migration vers la v0.7 sans bousiller les projets existants.
Chapeau nomicons/cool

Bien !
nomicons/smile