Salut les C/C++ et pythons,
je vient vous présenter ma dernière création: mk-project: un créateur, gestionnaire, de projets basé sur make.
mk-project permet de créer des projets C, C++, python2 et python3.
:note: Ceci est un poste dans le but que vous testiez mon programme afin de voir ce que vous en pensez…
Vos remarques, commentaires, etc… sont chaleureusement la bienvenue.
Ce poste sert de base afin d'amélioré le release final et est une sorte de pre-release bien que les fichiers sont déjà packager correctement.
+ Page de présentation de mk-project.
+ Documentation de mk-project.
mk-project permet d'automatiser complètement la compilation, l'exécution, le débogage et l'investigation de code machine, le profilage,…
Mais ce n'est pas tout car mk-project permet aussi de générer de la documentation a base de 3 différents langages de balisage:
texinfo.
markdown (Dans plusieurs dialectes.)
ReST (ReSTructured Text)
Mais si vous désirez utilisez un moteur de documentation plus avancé, tel que sphinx, doxygen, ou autres, la manipulation est facile et bien décrite dans la documentation.
mk-project permet aussi d'enjoliver votre code grâce aux outils suivants:
indent
astyle
bcpp
pindent
Avec beaucoup de styles prédéfinis mais vous laissant une ouverture afin de complètement personnaliser votre formatage de code source.
mk-project permet de créer une archive de votre projet au format suivants:
tar
tar.gz
tar.bz2
zip
Et mk-project permet aussi bien d'autres choses…
mk-project est disponible sous forme de paquetage debian et d'archive tar.gz.
:note: Une fois installer vous pourrez hacker le code grâce au Makefile contenus dans le dossier de destination (habituellement /usr/local/share/mk-project).
.. warning::
mk-project a pas mal de dépendances entre autre la bibliothèque libvte-2.91 qui vient d'apparaître dans les dépôts remplaçant l'ancienne version libvte-2.90
sur laquelle mon éditeur de texte a terminaux intégrées it-edit (Integrated Terminals Editor) est basé (sniff !).
Ne vous inquiétez pas trop pour les nombreuse dépendances, car elle, sont optionnelles dans le programme.
Dans le tarball elle sont pour la plupart optionnelle et dors et déjà sans doute déjà installer sur votre machine, pour la plupart.
Dépendances de mk-project:
libgtk-3-dev
libvte-2.91-dev
libxml2-dev
pandoc
python(3)-docutils
texinfo
xdg-utils
findutils
libc-bin
binutils
bsdmainutils
indent
astyle
bcpp
gettext
make
P.S: Je suis ouvert a toute formes de critiques mais j'ai conçus cet outil pour des besoins personnels et si je le distribue c'est parce que je pense qu'il peut être utile a d'autres (les utilisateurs de vi et compagnie vont être ravis).
# ya un truc qui me fait tiquer ...
Posté par totof2000 . Évalué à 3.
Que vient faire libgtk-3-dev pour un truc censé être utilisé sur un terminal ?
[^] # Re: ya un truc qui me fait tiquer ...
Posté par Linuxator (site web personnel) . Évalué à 1.
Et bien gtk+-3.0 dispose d'une library complémentaire qui permet d'intégrer un terminal dans gtk+-3.0,
nommer libvte-2.91.
J'en ai donc profiter pour implémenter des terminaux d'une pour la sortie des
targetsmake et de deux pour les utilisateurs de vi et compagnie.Sinon vous pouvez tout a fait générer un projet et ignorer la G.U.I en utilisant le projet (
Makefile) dans un terminal.# ca n'intéresse pas les utilisateur de vim.
Posté par Linuxator (site web personnel) . Évalué à 1.
Ça branche vraiment personne ?
Même pas les utilisateur d'éditeur en mode terminal comme vi, vim, nano, edcetera…
Car j'aimerai savoir si les raccourcis clavier du programme (De la G.U.I) interfère avec ceux de votre éditeur favoris.
Et si mon implémentation du terminal est assez bonne pour vous ?
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par freem . Évalué à 2.
Tu sais, je me demande vraiment pourquoi tu ne fais jamais de journaux. La plupart du public de linuxfr ne lit probablement que les journaux, et je n'ai aucun doute que tu recevrais nettement plus de réponses et d'enthousiasme sur cette section.
De mon côté, j'y jetterais sûrement un œil, même si j'ai tendance à freiner des 4 fers quand je vois des dépendances à gtk :) (les goûts et les couleurs…)
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par Linuxator (site web personnel) . Évalué à 1.
Salut,
En faîtes la dépêche est prévue mais pour l'instant je recueille les avis de programmeurs ce pourquoi le poste dans la section C.
Concernant gtk je suis abasourdie sachant que gnome est le bureau de référence de Linux et non KDE et d'ailleurs sous gnome les programmes KDE ressemble fortement au programme gnome.
Sinon je te conseille vivement d'installer quelques themes gtk (2 et 3) pour les programmes utilisant gtk, car si tes programmes gtk ont une interface middlegray c'est que tu n'a pas de theme gtk d'installé.
Concernant mes programmes ils s'adaptent au theme (gtk) de l'utilisateur sinon les icônes sont de icônes KDE (oxygen) et personnellement l'esthétique est un de mes derniers critères, préférant le coté pratique de l'outil et son ergonomie.
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par freem . Évalué à 2.
Je n'utilise pas de DE. Que ce soit Gnome ou KDE, que je fuis comme la peste (monolithiques), XFCE (mieux mais toujours monolithique) ou LXDE (dont j'utilisais certaines parties encore récemment, mais j'ai trouvé aussi bien et sans dépendances GTK). Je préfère i3-wm + urxvt + quelques logiciels triés sur le volet, qui pour la plupart peuvent se configurer facilement et indépendamment (pour la plupart, car il me reste malheureusement des logiciels qui dépendent d'une façon ou d'une autre de saletés comme gconf). Question de goût, comme je disais.
Du coup, l'installation d'un logiciel dépendant de Gtk tends à m'installer pas mal de cochonneries, surtout si c'est du Gtk3 (j'ai encore 8 logiciels dépendant de Gtk2).
Mais je comprend que l'on puisse utiliser certains outils pour dev qui se basent eux sur Gtk.
Je n'ai jamais dis que je n'avais pas de thème. Juste, je n'apprécie pas l'interface Gtk, et pas pour les icônes (dont je me moque, au final, tant qu'elles ne sont pas trop grosses) mais surtout pour ce foutu dialogue d'ouverture de fichiers absolument pourri et l'espacement exagéré entre les items. Ça peut sûrement se configurer, mais s'il me faut installer un DE juste pour ça, c'est pas la peine, je préfère encore utiliser des alternatives (ceci dit, si tu connais un logiciel permettant de configurer gtk et qui n'aie pas 30000 dépendances débiles, je suis preneur).
C'est bien pour ça que j'utilise beaucoup de logiciels TUI :) au moins on sait qu'on peut utiliser le clavier et être efficace avec eux et ils se configurent généralement en même temps que le terminal, au moins pour tout ce qui à trait aux polices et couleurs (vive ~/.Xdefaults).
Par contre, c'est pas sexy du tout… mais peu m'importe, il n'y a pas de place gâchée, c'est lisible, ça se manipule très bien au clavier… ça me va.
Question de goûts, encore: certains préfèrent la souris.
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par NeoX . Évalué à 2.
j'ai pas testé, mais VI/VIM/NANO/EMACS et les fichiers de configuration qui sont dans .gconf,.gconf2 ou .config….
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par Linuxator (site web personnel) . Évalué à 1.
Je ne comprends pas:
Qu'appelle tu un DE ???
Qu'appelle tu un TUI ??? (Terminal U.I ?)
Dans ce cas: a part la barre de menu et la fenêtre de configuration et bien dans mon programme il n'y a que des terminaux…
Et je te rappelle que les terminaux de nos jours ne sont plus des terminaux mais
des émulateurs de de terminaux virtuelle: V.T.E (Virtual Terminal Emulator) sauf pour les TTY (je crois).
Et dans le temps les terminaux était des genre de machine avec un clavier et un écran afin de traiter les données avant de les envoyer a l'ordinateur lui même afin de na pas casser le matériel avec de fausse commandes.
Donc sans interface graphique pas de terminal smart (configurable, easy to use, etc…).
Après si tu veut du lightweight tu peut installer une version serveur de ta distribution et utiliser les TTY, sans Desktop.
Concernant ta haine envers GTK+ je ne jugerai pas ce que je connaît pas:
Certes gtk dépends de pas mal (quelques a vrai dire) de libraries complémentaire qui ont toute une utilité très pratique quand ont fait de la programmation gtk.
Mais j'ai l'impression de pisser contre le vent, en rédigeant ce poste car tu va me répondre que des insanités.
Mais sache que c'est toi qui m'a donner l'idée d'intégrer un|des terminaux pour utilisateurs d'éditeurs T.U.I…
(Lors du poste de la pré-parution de it-edit 2.0)
Et mon programme tu l'a tester avant de parler ?
Après il est vrai que il reste quelque chose a rajouter, changer, corriger dans mon programme mais si personne le teste je suis tous seule.
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par freem . Évalué à 2.
Mea culpa, je deviens un vrai technocrate avec mes abbreviations à la con… et je déteste ce fait :/
DE: Desktop Environment, ou environnement de bureau en français.
TUI: Text User Interface, en gros, du ncurses, des trucs style midnight commander ou aptitude.
En fait, même les TTY sont des terminaux virtuels, puisque tu as très bien fait de le faire remarquer, un terminal ce n'est qu'un périphérique d'entréeS/sortie, qui envoie et reçoit les informations nécessaires à son fonctionnement via un réseau (pas forcément éthernet).
La, je suis en désaccord. Le problème est que, et j'ai fait moi-même l'erreur récemment, on confond «GUI» (Graphical User Interface) et ta définition de «smart». Ironiquement, 90% des applications GUI que j'ai utilisées ne sont pas utilisables aisément au clavier, alors que les TUI que j'ai utilisées sont utilisables aisément à la souris (justement grâce aux émulateurs de terminaux).
Debian n'a pas de version serveur. Et j'utilise un environnement graphique, c'est juste que la plupart des applications que j'utilise sont au travers de terminaux. Pour référence, et parce que je pense que ça peut t'intéresser (aujourd'hui ou demain, peu importe), voici ce dont je parle.
Au final, ce qui est lourd (pour gnome/kde/whatever), c'est tous les outils qui tournent en arrière-plan pour donner des services divers et variés (que l'utilisateur en ait besoin ou non est une autre question et dépend dudit utilisateur)
Ce n'est pas de la haine.
Je ne vomis pas sur Gtk (ni aucune technologie d'ailleurs, seulement sur certains usages de celles-ci en général), je considère juste qu'il y a plus d'inconvénients que d'avantages.
D'ailleurs, j'ai encore quelques applications Gtk qui tournent, et le fait de fuir gtk n'a commencé que quand les applications sous Gtk3 ont commencé à arriver sur ma Debian.
Gtk2 ne me posais pas (autant) de problèmes moraux (parce que soyons honnêtes, c'est pas moi qui maintiens le code, donc c'est pas des problèmes pratiques… avec les appli gtk, je ne maintiens que le côté admin :))
Désolé de te décevoir, mais je préfère avoir affaire à des gens qui ne sont pas d'accord, ça me permets d'évoluer. Hors, quand on insulte les gens soit ils ne répondent pas, soit ils deviennent agressifs, ce qui nous empêche d'évoluer. Moi, je suis anar, et j'ai des gens que j'apprécie qui sont limite facho. Alors, insulter pour une lib logicielle? Nan. Vraiment. Au pire, je pourrai troller, mais jamais sur les forum, c'est pas l'endroit.
Bien, au moins je t'ai aidé a voir plus d'horizons, sans te priver (manifestement) de ton esprit critique, j'ai géré!
Je sais que je ne suis pas un grand diplomate, comme tu as pu le constater, mais j'espère que mes commentaires à tes messages sont plutôt constructifs, une fois la forme (aka diplomatie) mise de côté.
Bon, j'avoue, ce n'était pas très explicite de ma part. Donc, non, je n'ai pas encore testé, mais si j'ai répondu, c'est pour:
Et dans le pourquoi, il y a 2 problématiques.
L'une d'elles est Gtk (en argumentation, toujours mettre les arguments les plus faibles en 1er). En t'adressant à des utilisateurs de vi ou nano. Même techniquement, il y a une différence (vi&nano, tu peux les utiliser sans Xorg, pratique via ssh).
L'autre, est le fait que ton programme est… fait pour toi. Tu le dis, et c'est normal. Franchement, coder pour les autres, c'est un tue-l'amour :D mieux vaut coder pour soit et diffuser: ceux qui aimeront en profiteront.
Et il est hors de question pour moi de dire que tu fais mal ton dev, parce que justement, c'est ton workflow et pas le mien. Moi, je n'utile pas les autotools déjà, mais cmake. Je n'utilise pas Gtk, et j'évite les trucs graphiques, mais pas toi. Des visions différentes, c'est une bonne chose.
Du coup, je pense sincèrement que ton terminal amélioré peut intéresser beaucoup de monde, et moi-même il m'intéresse pour l'aspect technique, mais pas pour l'usage.
Donc, je le testerai probablement, pour voir tes idées. Je ne sais pas quand, c'est sur ma TODO-list, mais oui le sujet m'intéresse. Là était mon propos.
PS: désolé pour le temps de réponse, je ne me connecte plus autant qu'avant sur linuxfr
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par Linuxator (site web personnel) . Évalué à 1.
Bon d'accord enfin une réponse de ta part.
Désolé pour l'agressivité de mes 2 précédents postes je me suis laisser emporter car je fait pas partie de la génération vieux barbue.
A vrai dire je n'ai que 3 ans de C a mon actif et 5 en programmation.
Il faut savoir que il semble d'après le peu de personnes qui ont tester mon T.D.E basé sur gtk-3 il est vrai qu'il a quelques lacunes d'ou l'intérêt de faire un poste pre-release.
Par contre j'aimerai savoir un truc sur toi, si tu désire bien le révéler:
Est-ce-que tu t'y connais en termcap/termios car j'ai fait une mini library (qui est en mode mort pour l'instant car je bloque sur un problème va_list et d'accès aux paramètres qu'il faut que je modifie).
Et cette mini library est basé sur les séquences d'échappements ANSI et permettent une sortie colorié d'ou le nom de libaescprintf (library ANSI Escape Sequence Color Print Format).
Bon tu aura deviner ou je veut en venir avec ma question.
Ma library permet d'avoir une sortie colorier (foreground & background) et stylé (bold, dim, italic, blink, etc..)
Il est aussi prévue de faire de asvprintf() et les redirections vers des fichier sont déjà possible mais non tester…
Car je bute sur les problèmes suivant:
Je n'arrive pas accéder aux arguments transmis par une va_list (…)
sinon le programme (de teste) crash, me si je suis le code de la manpage, que j'ai besoin de modifier car
il faut que, si l'argument est de type char * et se termine par un linefeed il faut le remplacer par un '\0'…
Sinon les terminaux quel qu'ils soient vont jusque la fin de la ligne voire plus si l'on met une couleur de background, d'après ce que j'ai pu hacker c'est intrinsèques aux terminaux.
Qu'en pense tu ? régler le problème et se servir de termcap pour récupérer les codes d'échappement afin d'être compatible avec tout type de terminaux…
Tout seul je n'y arriverai pas et laisserai tomber: est tu tenter ?
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par freem . Évalué à 2.
Pas de soucis, ça arrive à tout le monde.
Je n'ai que peu utilisé ce type de programmation, mais difficile à dire sans voir le code.
Ça, c'est lié au fait qu'en C, le \0 est le seul moyen de savoir la fin de ta chaîne de caractères. S'il n'y en a pas, ton programme affichera la mémoire jusqu'au prochain 0, et continuera l'exécution du code. Du coup, il est très possible qu'il ait affiché tant de code que ça explose une fonction.
Je pense que moi, j'aurai d'abord utilisé une lib de type ncurses pour les fonctions de bas niveau, et que si je voulais m'en débarrasser par la suite (pas impossible du tout, me connaissant), alors je n'aurai qu'à implémenter les fonctions qui l'appellent.
Tout la mécanique de plus haut niveau (gestion des évènements et leur liens par rapport à des fonctions de manipulation de GUI?) étant stable.
Il faut voir. Personnellement j'y ai déjà pensé, mais qu'apportes-tu par rapport à l'existant? Pour avoir un peu utilisé ncurses, je sais que l'API est pas terrible, mais je n'ai jamais encore testé son concurrent (me souviens plus le nom, mais je sais qu'il y en a).
Accessoirement, je code plutôt en C++, même si je n'utilise pas certaines fonctionnalités.
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par Linuxator (site web personnel) . Évalué à 1.
Salut,
C'est un essaie de library qui a pour simple but non pas de proposer une alternative a ncurses mais une library très légère dont le humble but est de proposer une sortie colorée et stylé (rediriger vers différent flux, dont fichiers) et c'est tout.
Je parlai d'une proposition de collaboration sur un petit (voir mini) projet car je n'ai les connaissances pour rendre ma library compatible avec tout type de terminaux (pour cela il nous faut termcap dont je ne connais rien), car actuellement basé sur les séquences d'échappements ANSI pour ce qui est du bas niveau…
Est tu partant ou pas ?
Si je t'envoie le code (c'est juste un fichier avec de nombreux #define, enum et typedef) en l'état actuel ?
PS: Et je ne veut pas dépendre d'une library quelconque, j'ai juste besoin de quelqu'un qui s'y connais vraiment en terminaux pour trouver les codes censé remplacer les séquences d'échappement ANSI…
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par freem . Évalué à 2.
D'accord. En fait, c'est pour te faire la main, donc.
C'est le but de ncurses et newt (j'ai retrouvé le nom).
Vu que je ne vois pas trop l'intérêt (autre qu'apprendre, je veux dire), pas vraiment.
Comme tu l'as dis toi-même, c'est juste une liste de définitions, avec éventuellement quelques fonctions pour encapsuler les portions de texte dans les bonnes balises (parce qu'au final, c'est juste un système de balise).
Par contre, je pense que tu pourrais être intéressé par le code de divers enjoliveurs de code. Souvent, ils émettent divers formats, dont un pour la console.
Dans ce cas, l'idéal est sûrement de télécharger les spec ecma-48.
Ça peut être intimidant de prime abord (comme toutes les specs), mais pour l'avoir lue, c'est plutôt clair (plus que les RFCs que j'ai lues en tout cas), et ça permets de faire tout ce qu'on veut.
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par Linuxator (site web personnel) . Évalué à 1.
De toute façon si tu utilise un V.T.E (Virtual Terminal Emulator) ou terminaux, mise a part les 6 TTY (F1-F6) je crois,
tu utilise une G.U.I qu'importe lequel (de terminal) et laquelle (de G.U.I)…
[^] # Re: ca n'intéresse pas les utilisateur de vim.
Posté par freem . Évalué à 2.
Tout dépend en fait de ton système d'init. Avec sysVinit, le nombre de «terminaux» textes est défini dans /etc/inittab, cherche donc getty dans ce fichier. Pour systemd, j'en sais rien et je m'en tape ;) mais de mon côté, j'utilise runit et… bon, c'est un peu particulier. Toujours est-il que ça se configure.
En gros, l'arborescence des processus de mon système ressemble à ça:
init (systemd/sysVinit/runit/…) > tty (agetty/ngetty/…) > Xorg > i3wm > [rxvt>ncurses | xlib | gtk/qt | sdl]
Comme tu peux le voir, les toolkits graphiques interviennent tard, et d'ailleurs, ils sont eux-mêmes basés sur une lib utilisant X11 (il n'y a pas que xlib, mais aussi xcb… peu importe).
Leurs grands intérêts, parce que même moi je le reconnaît qu'ils en ont, c'est qu'ils sont portables et plus jolis. La portabilité, c'est important à mes yeux. La beauté, non.
Sauf que du coup, dans pas mal de cas, la portabilité si chère à mes yeux n'est pas nécessaire. Pour de la compilation, on a en gros 2 plates-formes (que je connais): windows et unix-like (mac os, linux, *bsd). La 1ère utilise un IDE (pas mon truc, même si c'était facile à utiliser quand j'apprenais), la 2nde est… chaotique, et pas mal de systèmes (le tien, cmake, scons, les autotools…) se contentent au final de générer un makefile qui est au projet ce que l'assembleur est au code.
Mais je sors du sujet, je m'arrête donc là :)
[^] # Revient
Posté par Linuxator (site web personnel) . Évalué à 1. Dernière modification le 15 juillet 2016 à 22:59.
Tu veut pas revenir ?
De part la Xlib j'ai appris que celui était basé sur les pixmap concernant les couleurs (one foreground and one background color) ne permettant même pas de restituer toutes les couleurs possibles avec un ordinateur organiser en palettes:
256 * 256 * 256 * 256
Donc en restant sur X est-ce-que Linux ne va pas couler, il le savent et testent des solutions: wayland,…
[^] # Re: Revient
Posté par freem . Évalué à 3.
Je passe de plus en plus rarement :)
Soit plus de couleurs que l'œil ne peut discerner.
Je ne sais pas. Un problème que je vois avec Wayland à l'heure actuelle, c'est qu'il n'existe pas de doc (ou je ne l'ai pas trouvée) permettant de faire quelque chose facilement sans utiliser Gtk ou Qt ou whatever.
Du coup, j'ai plutôt peur que linux meure étouffé par sa graisse que par l'usage d'un outil périmé (parce que Xorg l'est, on est d'accord, surtout pour des problématiques de sécurité).
Après, je ne suis pas visionnaire, ça saurait sinon :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.