Besoin de votre avis sur un "projet" perso

Programmation
#1

Bonjour à tous,

Je suis en train d’apprendre en autodidacte le C à l’aide de plusieurs bouquins…
Et comme j’aime bien appliquer ce que j’apprends, je souhaiterais faire un petit soft qui me manque beaucoup sur Linux, à savoir un copier/coller multiple.

Je sais qu’il en existe sur notre OS préféré sauf que, pour moi, ils ne sont pas aussi intéressants et pratiques que celui que j’utilise sur Window$. (ClipX)

Et c’est là que j’aurais besoin de votre avis :
[ul][li]est-ce un “projet” accessible pour un débutant ? (en gros, est-ce que je me lance pas dans quelque chose qui nécessite une bonne expérience en programmation C système ?)[/li]
[li]le C est-il le langage le plus judicieux pour faire ça ? (cette question n’est pas un troll, mais une réelle question… de débutant : donc merci de ne pas partir en vrille à ce sujet !)[/li]
[li]auriez-vous des conseils pour réaliser correctement un tel soft ? (des exemples aussi , peut-être ?)[/li][/ul]

Je vous remercie d’avance pour vos précieux conseils,
@+
Eric

#2

Il à quoi de si particulier ce ClipX ? Merci

#3

Copier/coller = interaction avec XWindows (XOrg) = beaucoup de complexité pour un débutant. J’aurais plutôt tendance à te conseiller d’apprendre les bases avant de t’engager là-dedans (sauf si tu as déjà une solide expérience en programmation dans d’autres langages, ce que tu n’as pas précisé).

#4

Merci déjà pour vos réponses.

@terix :
Je vois déjà deux avantages : l’accès au contenu du presse papier par un raccourci paramétrable (pas besoin de cliquer sur un icône) et la gestion de l’accès à la donnée désirée soit par la souris, soit par les flèches du clavier, sachant que quand on se trouve tout en haut, on peut repasser tout en bas en un seul appui de la flèche haute (et vice-versa)…

Ça fait un petit bout de temps que j’ai regardé ce qui ce faisait sur Linux : peut-être que ça s’est amélioré… mais je crois que ça plantait aussi avec beaucoup d’entrées dans le presse papier (par ex, j’en utilise 67 au moment où j’écris !)

@syam : aïe ! pas cool ça…

#5

Je sais pas trop le niveau de difficulté que ça représente.
Je sais pas si Gnome et KDE n’ont pas leur propre API pour ça.

Sinon comme conseil versionne avec git et buid avec make ou cmake ^^

#6

Une micro recherche et je vois que gnome possède^possédait un gnome-clipboard-daemon.

Je viens de regarder glipper. Il est écris en python et utilise gtk pour s’interfacer avec XOrg, ça devrait te simplifier un peut la vie. Mais il faut quand même apprendre GTK (plus simple que d’apprendre XCB je pense).

Commence par créer une sorte xclip qui garde l’historique des copies, ça te permettra de réfléchir à la manière dont ça devrait fonctionner sans te prendre la tête avec des trucs en plus (GTK/Qt/XCB/Xlib) et tu pourras le faire évoluer vers ce que tu veut.

Pour xclip : apt-get install xclip et man xclip.

#7

Tu ne nous as toujours pas dit quel est ton niveau réel en programmation : débutant complet, bricolage de quelques scripts shell, d’autres langages ? As-tu déjà des bases en algorithmique (variables, boucles, tests, fonctions, structures etc) ?

Je vais peut-être me faire accuser d’être de la vieille école, mais je reste persuadé que l’apprentissage des bases est bien suffisamment compliqué quand on débute pour ne pas y rajouter de complexité inutile type XOrg (même si c’est via une API de Gnome). Un “bête” programme en console est déjà bien assez complexe à faire correctement, pas la peine de griller les étapes.
Après ça reste un point de vue, hein… :wink:

#8

[quote=“MisterFreez”]Commence par créer une sorte de xclip qui garde l’historique des copies, ça te permettra de réfléchir à la manière dont ça devrait fonctionner sans te prendre la tête avec des trucs en plus (GTK/Qt/XCB/Xlib) et tu pourras le faire évoluer vers ce que tu veut.

Pour xclip : apt-get install xclip et man xclip.[/quote]

#9

[quote=“MisterFreez”][quote=“MisterFreez”]Commence par créer une sorte de xclip qui garde l’historique des copies, ça te permettra de réfléchir à la manière dont ça devrait fonctionner sans te prendre la tête avec des trucs en plus (GTK/Qt/XCB/Xlib) et tu pourras le faire évoluer vers ce que tu veut.

Pour xclip : apt-get install xclip et man xclip.[/quote][/quote]
Ah oui j’ai confondu avec xclipboard, qui est graphique lui. :mrgreen:
M’enfin je maintiens quand même (oui, je suis têtu :stuck_out_tongue:) que l’interaction avec X apporte une complexité qui n’est pas nécessaire pendant l’apprentissage. YMMV.

#10

@Syam : oops, pas vu la question !
J’ai fait de la prog il y a longtemps de cela (à l’école, puis en perso aussi) en basic, pascal et assembleur Z80 et un peu de 68000…
Sinon, je m’essaye aussi dans quelques scripts shell.
Au niveau algo, à part ce que tu précises (variables, boucles, tests et fonctions) mes connaissances ne vont pas plus loin.

Je comprends parfaitement ton point de vue : je ne cherche pas à griller les étapes, je cherche juste à savoir si m’atteler à un projet de la sorte tout en apprenant est utopique ou non…

@MisterFreez : je ne connais pas xclip… je vais le tester ce soir, merci à toi !
J’ai trouvé un cours GTK-2 ici, pour débuter c’est déjà pas mal, non ?

#11

Je pensais surtout à refaire les options -i et -o sans interactions avec X. Je pense que la sauvegarde de texte et la possibilité de les lister en C donne déjà pas mal de boulot à un étudiant (gestion de mémoire, création de structure de données adéquate, choix d’implémentation sur la manière de sauvegarder (les X derniers ? Tous ?), etc).

Si tu t’y met, Eric75, n’hésite pas à nous poser des questions quand tu bloque ça devrait être intéressant.

#12

[quote=“Eric75”]J’ai fait de la prog il y a longtemps de cela (à l’école, puis en perso aussi) en basic, pascal et assembleur Z80 et un peu de 68000…
Sinon, je m’essaye aussi dans quelques scripts shell.
Au niveau algo, à part ce que tu précises (variables, boucles, tests et fonctions) mes connaissances ne vont pas plus loin.

Je comprends parfaitement ton point de vue : je ne cherche pas à griller les étapes, je cherche juste à savoir si m’atteler à un projet de la sorte tout en apprenant est utopique ou non…[/quote]
Ok, c’est déjà plus précis comme ça. Mes remarques avaient juste pour but de m’assurer qu’on n’avait pas affaire à un énième “j’ai commencé la programmation hier, je voudrais faire <projet totalement irréalisable pour un débutant complet>”… :wink:

Mauvaise idée à mon avis, apprends déjà le C lui-même avant de te lancer dans du graphique.

Ça par contre c’est une excellente idée : suffisamment simple pour ne pas te gêner dans ton apprentissage du C, et ça commence à poser les fondations du projet que tu veux faire (même si ça reste encore assez éloigné du but que tu t’es fixé). Ça te permettra de te rafraîchir la mémoire pour tout ce qui est algorithmique, et de découvrir le C de manière relativement douce.
Comme le dit MisterFreez y’a déjà pas mal de boulot.

#13

Ça par contre c’est une excellente idée : suffisamment simple pour ne pas te gêner dans ton apprentissage du C, et ça commence à poser les fondations du projet que tu veux faire (même si ça reste encore assez éloigné du but que tu t’es fixé). Ça te permettra de te rafraîchir la mémoire pour tout ce qui est algorithmique, et de découvrir le C de manière relativement douce.
Comme le dit MisterFreez y’a déjà pas mal de boulot.[/quote]
Ça n’empêche pas d’ajouter l’historique (par exemple -i pourrait prendre un paramètre optionnel de nombre). Il peut même inclure sqlite (en fait ce serait une excellente solution pour gérer convenablement l’historique, je trouve). Puis créer un couche graphique en Qt pour s’interfacer, finalement avec le clipboard classique.

(en plus s’il garde l’interface CLI, ce serait un logiciel que j’utiliserais volontiers en lieu et place de xclip)

#14

Ouais parce qu’un fichier plat, bonjour la misère pour gérer convenablement les chaînes copiées/collées contenant des retours chariot. Ou sinon faudrait partir sur un autre délimiteur (\x00 ?) mais rien ne garantit qu’il ne se retrouve pas non plus dans le flux d’entrée. Bref, un bon vieux blob et sa longueur associée, c’est encore ce qu’il y a de mieux. :mrgreen:

#15

Ouais parce qu’un fichier plat, bonjour la misère pour gérer convenablement les chaînes copiées/collées contenant des retours chariot. Ou sinon faudrait partir sur un autre délimiteur (\x00 ?) mais rien ne garantit qu’il ne se retrouve pas non plus dans le flux d’entrée. Bref, un bon vieux blob et sa longueur associée, c’est encore ce qu’il y a de mieux. :mrgreen: [/quote]
Tu peut à peut prêt être sur qu’il n’y aura jamais de EOF dans la copie et au départ t’es pas obligé non plus d’être fiable et de gérer tout les cas. Commencer par gérer soit même le truc en mémoire avant de se mettre au SQL (toujours en mémoire parce qu’un clipboard persistant n’a pas ou peut d’intérêt) ça me semble être une bonne feuille de route. Il y a le problèmes des instances multiples qui se résoud bien avec l’utilisation de sqlite.

#16

J’avoue que j’ai jamais rien bité à cette histoire d’EOF sous *nix. Un coup c’est un vrai caractère, un coup c’est juste la fin du flux (fermeture de la socket), c’est à ne plus rien y comprendre.
Et malheureusement, mon côté maniaco-parano n’arrive pas à se contenter d’à-peu-près (un jour peut-être j’y arriverai, qui sait…). Du coup, j’ai tendance à blinder tous les cas de figure. :mrgreen:

#17

@Syam : le cours GTK-2 c’était surtout pour savoir si c’était un bon cours… (on voit tellement de “pseudo” cours bourrés d’erreurs sur le Net)
Mais je suis d’accord avec toi, je ne compte pas mettre la charrue avant les bœufs et vais (essayer de ) suivre les conseils de MisterFreez et donc commencer doouuuucement…

[quote](en plus s’il garde l’interface CLI, ce serait un logiciel que j’utiliserais volontiers en lieu et place de xclip)[/quote]Heu… j’espère que tu n’es pas trop pressé, quand même !!! :unamused:

[quote]Commencer par gérer soit même le truc en mémoire avant de se mettre au SQL[/quote]Ouais, chaque chose en son temps. (rome ne s’est pas fait en un jour !)
Et si j’arrive déjà à faire ça, ça sera déjà un bon début…

[quote]parce qu’un clipboard persistant n’a pas ou peut d’intérêt[/quote]Si, si justement, le coté persistant est pour moi une fonctionnalité super pratique…

:arrow_right: En résumé, d’après ce que je comprends de tout ça : il y a quand même du boulot on dirait bien !!!

#18

Si j’étais pressé je serais entrain de l’écrire (quitte à ne pas publier pour ne pas te causer du tord).

Il me semble que c’est un bon projet car il peut être progressif.