IT-Edit (Integrated Terminal Editor).

Version imprimable

09/04/2015, 22h06
Luke spywoker

IT-Edit (Integrated Terminal Editor).

Salut les GTK,
je vient vous présenter ma dernière création, IT-Edit un éditeur de texte avec de multiples fonctionnalités. Créer avec GTK+3, gtksourceview3.0 et libvte.

Motivation pour l'écriture de IT-Edit (the Integrated Terminal Editor).

Ont peut diviser les programmeurs selon leur façon de travailler en 2 catégories:

* Ceux qui utilisent un IDE: un environnement de développement complet.

* Ceux qui travaillent avec des outils séparés: un éditeur de texte, usage du terminal et autres outils.

Comme je suis un programmeur de la deuxième catégorie et comme j'ai remarquer que j’utilisais souvent un client internet pour la doc HTML offline.

J'ai décidé d'écrire mon propre éditeur de texte qui me donne un accès directe a tous les outils dont j'ai besoin.

De cette idée est née IT-Edit.

Fonctionnalités de IT-Edit

IT-Edit implémente un éditeur de texte avec colorations syntaxique, affichage des numéros de lignes et la complétion automatique avec les fonctionnalités de base d'un éditeur de texte:

* Couper / Copier / Coller.

* Dupliquer la sélection ou de la ligne du curseur.

* Undo/Redo.

* Aller a une ligne donnée.

* Recherche et remplacement.

Pour la gestion de fichiers IT-Edit implémente:

* Ouvrir un fichier vierge.

* Ouvrir un fichier donnée.

* Ouvrir un fichier récent.

* Sauvegarder le contenus de l'éditeur.

* Sauvegarder le contenus de l'éditeur dans un fichier choisis.

* Sauvegarder tous les fichiers ouverts.

Il existe évidemment des raccourcis clavier pour ces fonctionnalités.

IT-Edit implémente 2 terminaux dans la fenêtre principale qui sont aisément déployables, repliables et peuvent être redimensionnées.

IT-Edit implémente une fonctionnalité pour exécuter une commande quelqu'onque dans un terminal dans une fenêtre toplevel qui est facilement maximisable, minimisable et redimensionnable.

NOTE: cette fonctionnalité était prévus pour la visualisation de manpages qui a été étendue a toutes sortes de commandes, sans restriction.

IT-Edit implémente un mécanisme d'enregistrement de fichiers quelquonque (doc html, pdf, ps ou musique, vidéo...)
un accès directe a tous les outils dont j'ai besoin
Qui seront après enregistrement lançable par le programme par défaut associé au type de fichier.

NOTE: cette fonctionnalités était prévus pour la visualisation de documentation offline HTML qui a été étendus.

Avec ses terminaux intégré IT-Edit vous fournis une environnement de développement, répondant a tout vos besoin.

Prenez la peine d'essayer de s'habituer a IT-Edit, vous allez sûrement l'adopter.

Le programme est distribuer sous forme de paquetage *.deb, si cela ne vous convient pas allez dans:
Programmes->Accéder a l'index->C->IT-Edit, vous y trouverez un tarball compatible Linux et BSD (non-testé).
Pour installer IT-Edit tapez:

$ ./configure
$ make
$ sudo make install

Je suis ouvert a toute formes de critiques, si vous avez des commentaires a faire sur le code, les fonctionnalités auquelles je n'ai pas penser etc...

PS: J'ai vraiment écrit ce pseudo IDE pour mes propres besoins, mais je tiens a vous en faire profiter, quand même, afin qu'il évolue selon les fondements du free-software.
11/04/2015, 09h11
gerald3d

Test
Je vais y jeter un œil...ou deux ;)

Voila mes premières constatations :
- L'installation sur une Debian SID s'est passée sans aucun problème.
- Je retrouve le lien de l'éditeur dans le menu "Développement" de XFCE, nickel !
Je lance l'éditeur. Tout fonctionne bien. C'est déjà un bon point. Tu utilises des boutons et des menus avec des icônes. Cela ne me gêne pas du tout mais c'est en voie de disparition. Gtk+ ne le permet plus directement dans ses dernières versions.

J'ai ouvert la fenêtre des terminaux. Deux terminaux ouverts, je trouve ca bien. Il m'arrive très souvent aussi d'avoir besoin de deux terminaux, surtout lorsque je code une bibliothèque. J'aurais par contre aimé que les terminaux s'ouvrent dans le répertoire du fichier que j'ai ouvert précédemment. Idem pour le bouton "Cmd". J'ai ouvert un projet constuit avec les autotools. Une fois fait j'ai cliqué sur "Cmd" et tapé "make". Je m'attendais à ce que la commande s'effectue dans le répertoire du projet.

Code source :

J'ai juste ouvert it-edit.c. Tu vas pouvoir travailler ton code selon deux axes :
1. regarde la Glib. Tu as toutes les fonctions nécessaires pour te passer de asprintf, fprintf...Ainsi tu pourras limiter l'appel à des bibliothèques externes (même si certaines sont déjà appelées par la Glib),
2. je ne vois nulle part l'utilisation de Glade. Ou je n'ai pas les yeux en face des trous ou c'est bien le cas. Penche-toi sur cet outil, tu pourras alors alléger ton code de manière drastique.
Voila pour mes premières impressions. Je te félicite pour ce joli travail.

Merci vraiment beaucoup pour ces encouragements, commentaires, impressions et compliments.

J'ai pas mal travailler sur le code après que le programme soit complètement fonctionnel, afin de ne pas faire d'appels inutiles, ce que j'ai beaucoup fait en cours de développement. a voir ici.

Citation:

Tu utilises des boutons et des menus avec des icônes. Cela ne me gêne pas du tout mais c'est en voie de disparition. Gtk+ ne le permet plus directement dans ses dernières versions.

D'accord mais alors qu'est-ce qui est "a la mode" alors ?

Personnellement je tourne sur une Ubuntu LTS donc je n'ai pas la dernière version de GTK+3: les rollings releases fournissent sûrement des version plus récentes de GTK+3.

Concernant le répertoire courant des terminaux leurs initialisation permet de définir un répertoire courant.

J'ai penser que l'on pouvait se déplacer dans les répertoires puis de lancer sa commande puis une autre, puis une autre. le répertoire courant ne change pas sauf si vous quittez l'application.

Et sauf pour le bouton Cmd qui lance a chaque fois un nouveau terminal dans le répertoire $HOME de l'utilisateur.

Pour pallier a ce problème il y a deux solutions:

1) Soit simplement garder le terminal (Cmd) ouvert et se placer là ou l'on veut. Idem pour les terminaux intégrés.

2) Soit mettre les mains dans le cambouis et ajouter un pointeur de type char dans la structure Settings et l'initialiser avec la fonction de libvte2_90:

Code:

const char *vte_terminal_get_current_directory_uri(VteTerminal *terminal) ;

En quittant le programme ou a chaque changement de répertoire avec le signal:

Code:

"current-directory-uri-changed"

Et au nouveau démarrage ou lors de l'appui sur Cmd initialiser le terminal avec la valeur enregistrer auparavant, grâce a la fonction:
Code:

1 2 3 4 5 6 7 8 9 10 11 gboolean vte_terminal_fork_command_full(VteTerminal *terminal, VtePtyFlags pty_flags, const char *working_directory, char **argv, char **envv, GSpawnFlags spawn_flags, GSpawnChildSetupFunc child_setup, gpointer child_setup_data, GPid *child_pid, GError **error);
Note: Ça parait compliqué comme prototype mais beaucoup de paramètres peuvent être mis a NULL.

Libre a vous de modifier, a votre guise, le programme comme dit par la licence GPLv3 l'accompagnant...

D'ailleurs je l'ai distribuer dans ce but afin de vous fournir une base pour construire votre environnement de travail a vous.

Car qui maîtrise le mieux un éditeur que celui qui l'a conçus.

Citation:

regarde la Glib. Tu as toutes les fonctions nécessaires pour te passer de asprintf, fprintf...Ainsi tu pourras limiter l'appel à des bibliothèques externes (même si certaines sont déjà appelées par la Glib),

Je vais regarder, merci.

Il est vrai que l'appel a l'extension GNU asprintf() réduit le nombre d'utilisateur potentiels mais cela m'importe peu, même si ça me gêne aussi d'utiliser une fonction qui ne soit pas complètement standard. (asprintf() est présent sur BSD aussi.)

Citation:

je ne vois nulle part l'utilisation de Glade. Ou je n'ai pas les yeux en face des trous ou c'est bien le cas. Penche-toi sur cet outil, tu pourras alors alléger ton code de manière drastique.

Je n'ai pas utiliser Glade, effectivement mais j'ai implémenter une fonction de setup pour chaque composante de l'interface, enfin presque: menu, buttonbox, terminaux...

Je préfère travailler en dur, même si le code s'en trouve largement alourdis, j'y viendrai peut-être a Glade,
ce n'est que mon deuxième programme en C avec GTK+3 et python est toujours bloquer a GTK+2.

Citation:

Je te félicite pour ce joli travail.

Merci ça fait vraiment chaud au cœur.

12/04/2015, 18h24
gerald3d
En regardant un peu tous tes fichiers sources je me suis arrêté sur editor.c.

Dans la fonction add_file_to_editor(); :
- Tu utilises les mots réservés bool, false et true. Compiles-tu en C++ ?
- Tu utilises un pointeur GError. Si la fonction g_file_fet_contents(); retourne FALSE tu ne libères pas l'espace alloué par ce pointeur (avec g_error_free();).
- Toujours au sujet de GError tu utilises g_strdup_printf(); pour afficher le message d'erreur. Tout d'abord c'est inutile de l'utiliser pour afficher le message et en plus tu as aussi une fuite mémoire à cette occasion, puisque g_strdup_printf(); alloue dans le tas.
- Attention ! g_locale_to_utf8(); alloue dans le tas. Lorsque tu initialises file_content avec g_file_get_contents(); il pointe sur un espace alloué dans le tas. Écrire ensuite file_content = g_locale_to_utf8 (file_content,...); te fait perdre le pointeur sur la première allocation. Une fuite de plus :D.
J'arrête là ma lecture pour le moment. Je regarderai d'autres fichiers quand le temps me le permettra ;).
13/04/2015, 16h50
Luke spywoker

Merci beaucoup pour votre intérêt porter au code source de IT-Edit
Merci beaucoup pour votre intérêt porter au code source de IT-Edit,

Citation:

Tu utilises les mots réservés bool, false et true. Compiles-tu en C++ ?

Non pas du tout ce sont des types C99 du fichier stdbool.h, qui implémentent le type booléen.
par exemple:
Code:

1 2 3 4 include <stdbool.h> bool bool_value = true ;
Citation:

Tu utilises un pointeur GError. Si la fonction g_file_get_contents(); retourne FALSE tu ne libères pas l'espace alloué par ce pointeur (avec g_error_free();).

ET bien il s'avère que je ne savait pas qu'il fallait que je libère les variables de type GError.
Ce n'est pas évident car on déclare un pointeur de type GError statiquement et qu'après on donne l'adresse de ce pointeur a une fonction g_* qui, elle donc alloue de l'espace dynamiquement. Je n'ai pas remarquer.

Et il est vrai que j'ai oublier de libérer la variable file_content en cas d'echec de g_file_get_content().
Chose qui devrai pas se produire souvent, a moins d'une erreur de manipulation, comme ouvrir une fichier exécutable dans l'éditeur par mégarde, se produise.

Citation:

Toujours au sujet de GError tu utilises g_strdup_printf(); pour afficher le message d'erreur. Tout d'abord c'est inutile de l'utiliser pour afficher le message et en plus tu as aussi une fuite mémoire à cette occasion, puisque g_strdup_printf(); alloue dans le tas.

Vous avez totalement raison il suffit de passer error->message comme message secondaire de la fenêtre d'erreur.

Note: Il y a la même fuite de mémoire avec g_strdup_printf() dans le fichier: /Callbacks/search_settings_callbacks.c
Mais dans ce cas je suis obliger de formater le message.
Et comme la fenêtre de message d'erreur est détruite par une fonction de timeout je ne peut que lui passer la variable de type GtkWidget *message_dialog comme argument afin que le callback détruise la fenêtre de message d'erreur.
J'ai bien essayer de faire autrement en déclarant une structure:
Code:

1 2 3 4 typedef struct { char *error_message ; GtkWidget *error_msg_dialog ; } Error_message ;
Afin de pouvoir:
*) Libérer le message (car il faut libérer le string retourner par g_strdup_printf())
*) Détruire la fenêtre de message d'erreur.
Mais malheureusement cela faisait crasher l'application pendant les assertions (Regardez du coté About->Readme dans la section "Notes for C programmers", il y a un mot sur les 2 fonctions de débogage).
J'ai préférer avoir une petite fuite au lieu d'un crash de l'application.

Citation:

Attention ! g_locale_to_utf8(); alloue dans le tas. Lorsque tu initialises file_content avec g_file_get_contents(); il pointe sur un espace alloué dans le tas. Écrire ensuite file_content = g_locale_to_utf8 (file_content,...); te fait perdre le pointeur sur la première allocation.

Il va falloir que j'utilise une nouvelle variable pour le retour de g_locale_to_utf8() ;

Encore grand merci pour l'intérêt porté au code source de IT-Edit.
Car je n'ai personne pour me relire ou me corriger, je suis tout seul, heureusement qu'il existe des forums et des gens qui s'intéresse a ce que je fait, pour cela.
Sinon les erreurs détecter resterai non-corriger.

Je vais corriger ces erreurs dès que vous aurez finit avec les autres fichiers afin de uploader une version corriger sur le serveur.

Je tiens a vous cité comme correcteur dans les README, alors contacter moi si vous voulez que votre vrai nom y apparaisse ou si vous ne voulez pas être cité.

Citation:
Envoyé par Luke spywoker
Merci beaucoup pour votre intérêt porter au code source de IT-Edit,

Non pas du tout ce sont des types C99 du fichier stdbool.h, qui implémentent le type booléen.
par exemple:
Code:

1 2 3 4 include <stdbool.h> bool bool_value = true ;
OK, au temps pour moi ;).
Citation:
Envoyé par Luke spywoker
Note: Il y a la même fuite de mémoire avec g_strdup_printf() dans le fichier: /Callbacks/search_settings_callbacks.c
Mais dans ce cas je suis obliger de formater le message.
Et comme la fenêtre de message d'erreur est détruite par une fonction de timeout je ne peut que lui passer la variable de type GtkWidget *message_dialog comme argument afin que le callback détruise la fenêtre de message d'erreur.
J'ai bien essayer de faire autrement en déclarant une structure:
Code:

1 2 3 4 typedef struct { char *error_message ; GtkWidget *error_msg_dialog ; } Error_message ;
Afin de pouvoir:
*) Libérer le message (car il faut libérer le string retourner par g_strdup_printf())
*) Détruire la fenêtre de message d'erreur.
Mais malheureusement cela faisait crasher l'application pendant les assertions (Regardez du coté About->Readme dans la section "Notes for C programmers", il y a un mot sur les 2 fonctions de débogage).
J'ai préférer avoir une petite fuite au lieu d'un crash de l'application.
Il faut voir les choses autrement. Si tu es dans l'obligation de passer un pointeur sur un espace mémoire alloué dans le tas à une fonction et que tu dois libérer cet espace mémoire une fois transmise, il te suffit de modifier la fonction appelée.
Dans la fonction display_message_dialog(); recopie les chaînes de caractère recues. Tu te retrouves alors dans cette fonction avec des pointeurs pointant sur d'autres espaces mémoires que ceux transmis. La fonction appelante peut alors libérer ses propres pointeurs sans pour autant affecter la fonction appelée.

Voila le code modifié :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 GtkWidget *display_message_dialog(gint message_type, const gchar *message, const gchar *secondary_message, gint buttons) { /** Return a message dialog according to the given arguments. **/ // Recopie des chaînes de caractère gchar *message_one = g_strdup (message); gchar *message_two = g_strdup (secondary_message); GtkWidget *message_dialog = gtk_message_dialog_new(NULL, GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT , message_type, /** GTK_MESSAGE_INFO || GTK_MESSAGE_ERROR **/ buttons, /** GTK_BUTTONS_NONE || GTK_BUTTONS_CLOSE **/ message_one, NULL); if (message_two) { gtk_message_dialog_format_secondary_text(GTK_MESSAGE_DIALOG(message_dialog), message_two, NULL) ; } return message_dialog ; }
Maintenant tu peux faire appel à cette fonction et libérer derrière les chaînes transmises.
Code:

1 2 3 4 5 6 7 /** Display an error message dialog in case th term is not found. **/ gchar *message = g_strdup_printf("Pattern:\n\" %s \"\nnot found in file !", searching.search_text); GtkWidget *not_found_message_dialog = display_message_dialog(GTK_MESSAGE_ERROR, "Pattern not found !!!", message, GTK_BUTTONS_NONE) ; g_free (message);
Intellectuellement c'est plus propre. Tu alloues, tu transmets, tu libères. Il ne reste plus que le problème de libération des deux nouveaux espaces alloués. Vu que tu as l'air de bien maîtriser le passage de données via les fonctions g_obect_set_data(); et g_object_get_data(); pourquoi ne pas attacher les deux nouveaux pointeurs message_one et message_two à la nouvelle fenêtre créée ?
Ainsi, lors de l'appel à destroy_dialog(); tu les récupères et les libères dans la foulée.

Toute cette explication est faite pour te montrer la philosophie générale à suivre tant que faire ce peut lors de l'allocation dans le tas. Pour ton code, si tu appelles display_message_dialog(); toujours de la même manière tu peux la conserver telle qu'elle. Il te suffit simplement de reprendre le code çi-dessus avec l'allocation du pointeur message, sa transmission et sa libération. Ca devrait fonctionner sans problème puisque gtk_dialog_new(); recopie lui aussi les chaînes transmises.

15/04/2015, 20h46
gerald3d

void duplicate(GtkWidget *button, gpointer user_data);

Tu utilises la fonction strcat(); dans void duplicate(GtkWidget *button, gpointer user_data); sur un buffer alloué par la fonction gtk_text_buffer_get_text();.
La documentation de strcat(); dit :

Citation:

DESCRIPTION
La fonction strcat() ajoute la chaîne src à la fin de la chaîne dest en
écrasant l'octet nul (« \0 ») final à la fin de dest, puis en ajoutant
un nouvel octet nul final. Les chaînes ne doivent pas se chevaucher, et
la chaîne dest doit être assez grande pour accueillir le résultat. Si
dest n'est pas assez grande, le comportement du programme est imprévi‐
sible. Les dépassements de tampon font partie des moyens préférés pour
attaquer les programmes sécurisés.

Tu ne modifies pas la taille du buffer pour ajouter le caractère d'échappement. ATTENTION ! DANGER ! Utilises en lieu et place la fonction de la Glib gchar *g_strconcat (const gchar *string1, ...);. Elle va allouer dans le tas pour toi un nouveau buffer à la bonne taille pour la concaténation désirée.
16/04/2015, 09h07
Luke spywoker

Tout d'abord encore merci pour l'intérêt porter a la correction du code source de IT-Edit: tu a sacrément bosser dessus a ce que je vois.

Une subtilité a éclaircir:
le tas c'est bien là ou se font les allocations de mémoire dynamique, voir ici pour confirmation, avec des appels a malloc et co ou par le biais d'une fonction qui s'en charge ?
Car tu en parle beaucoup et je suis un petit peu largué au niveau technique.

Je ne sais si j'ai bien compris mais il faudrait donc en supplément libéré message_one et message_two en les faisant passer à la fonction de libération par des appels a g_obect_set_data(); et g_object_get_data().
Pour ce qui est de l'affichage des messages d'erreurs.
Je verrai ça, plus précisément, au moment de la correction des erreurs détectés, pour voir si cela interfère avec les assertions de débogage.

Citation:

Tu ne modifies pas la taille du buffer pour ajouter le caractère d'échappement. ATTENTION ! DANGER ! Utilises en lieu et place la fonction de la Glib gchar *g_strconcat (const gchar *string1, ...);. Elle va allouer dans le tas pour toi un nouveau buffer à la bonne taille pour la concaténation désirée.

Effectivement c'est une erreur.

Il faut savoir que malloc alloue toujours un peu plus d'espaces que demandé (quelques bytes de plus, ça dépend).
Aussi étonnant que ça puisse paraître c'est pourtant c'est bien vrai j'ai remarquer ça avec la fonction malloc_usable_size.

Dont si vous consulté la manpage il y est écrit:

Citation:

NOTES
La valeur renvoyée par malloc_usable_size() peut être supérieure à la
taille demandée lors de l'allocation, à cause des contraintes d'aligne‐
ment et de taille minimum. Même si les octets en trop peuvent être
écrits par l'application sans effets indésirables, ce n'est pas une
bonne pratique de programmation : l'excédent d'octets dépend du code
mise en œuvre.

Mais bien sur ce n'est pas une raison pour écrire sur un octet qui ne serait pas allouer.
Je vais suivre ton conseil et regarder du coté du fonctionnement de g_strconcat(), comme conseillé.

Bon et bien maintenant je pense que tu a vue le plus gros avec IT-Edit.c, add_file_to_editor() et le fichier /Callbacks/search_settings_callbacks.c.

Je croit que le reste ne sont que des fonction d'initialisation de la GUI et de fonctions callback de certains signaux.

Attention si tu compile le code pour voir l'effet des fonctions de débogage et si tu a une résolution trop petite les boutons ne disposent pas d'assez d'espaces.
Dans ce cas il faudrait supprimer les 2 boutons "Cmd et Terminals" et compiler le programme avec l'option std=c99, -DDEBUG, -DDEBUGBUT...

Encore grand merci pour tes effort de relecture, c'est vraiment gentil de ta part.
16/04/2015, 16h23
gerald3d

Citation:

Envoyé par Luke spywoker

Tout d'abord encore merci pour l'intérêt porter a la correction du code source de IT-Edit: tu a sacrément bosser dessus a ce que je vois.

Une subtilité a éclaircir:
le tas c'est bien là ou se font les allocations de mémoire dynamique, voir ici pour confirmation, avec des appels a malloc et co ou par le biais d'une fonction qui s'en charge ?
Car tu en parle beaucoup et je suis un petit peu largué au niveau technique.

Pour essayer de faire simple, à chaque fois que tu encadres du code entre {}, le système d'exploitation alloue un espace mémoire. Sous Windows si je ne dis pas de bêtise c'est 1Mo, sous Linux 8Mo. Ces valeurs sont modifiables via les réglages du système d'exploitation.
Donc, lorsque tu ouvres une accolade, il y a réservation d'un espace. Toute la mémoire des variables déclarées après cette accolade est allouée dans cet espace. Lorsqu'on ferme l'accolade la mémoire allouée est automatiquement libérée. On appelle cette mémoire la pile. Plus communément on parle de variables locales.

Si pour une raison ou une autre tu as besoin d'avoir des variables portables (les variable globales en font partie), c'est à dire qui continuent "à vivre" après la fermeture de l'accolade, ou bien qui dépassent la taille de la pile, tu vas utiliser la fonction malloc(); (ou ses variantes). Cette fois-ci tu vas réserver un espace mémoire dans la RAM libre de l'ordinateur, en dehors de celle de ton programme. On appelle alors cet espace le tas.

En règle générale lorsque ton application s'arrête toutes les allocations liées à elle sont libérées par le système d'exploitation puisque c'est lui qui en a la charge en définitive. Mais il est quand même bien de faire le ménage dans son application pendant son exécution.

Citation:

Envoyé par Luke spywoker

Je ne sais si j'ai bien compris mais il faudrait donc en supplément libéré message_one et message_two en les faisant passer à la fonction de libération par des appels a g_obect_set_data(); et g_object_get_data().
Pour ce qui est de l'affichage des messages d'erreurs.
Je verrai ça, plus précisément, au moment de la correction des erreurs détectés, pour voir si cela interfère avec les assertions de débogage.

Oui tu as très bien compris. ;)
18/04/2015, 16h27
Luke spywoker

Salut gerald3d,

Il s'avère que le projet IT-Edit ai pris un certains essort (plus de 250 téléchargements du paquet *.deb) grâce a une dépêche sur le site linuxfr.

Bref ça serai sympa de ta part de me dire quand tu aura finit la relecture, ne te presse pas on a le temps.
Simplement afin que je soit informer que je puisse corriger les erreurs détecter et uploader une version corriger sur le serveur.
Et comme convenus tu sera cité comme correcteur, car tu le mérite bien.

En attendant de tes nouvelles, je te souhaite un bon week-end.
Luke Spywoker.
18/04/2015, 18h41
gerald3d

Je peux déjà apporter un début de réponse.

J'ai parcouru tout ton code. Il n'y a pas, à première vue, d'autres erreurs. La seule chose est que je n'ai pas du tout regardé le code de création/gestion de l'interface graphique. Vu qu'elle fonctionne très bien et que Gtk+ n'hurle pas dans la console je ne vois pas pourquoi le code serait défectueux.

Ce que je te propose c'est que tu fasses les modifications et de m'envoyer le code corrigé avant de le publier. Je ferai alors une relecture plus poussée avec quelques outils pour passer ton application à la moulinette ;).

Bon week-end.
19/04/2015, 12h43
Luke spywoker

C'est OK,

on fait comme ça.

Encore mille fois merci pour le temps consacré au projet IT-Edit dans l'effort de faire du code meilleurs.

Car, je me répète peut-être, mais tout seule ce n'est vraiment pas facile et il y a souvent des gens pour critiquer ton code sur un point ou deux sans vraiment donner d'explications et en restant floue, par exemple:

"ta fonction de mixage est inefficace et bugger".

Contrairement a toi qui t'es vraiment invertis dans le projet, je suppose c'est parce-que l'idée et le résultat te plaisait et que GTK+ a l'air d'être ton domaine.
Super boulot de relecture, bravo pour l'effort et encore merci.
09/11/2019, 11h07
turboiii

it-edit est maintennt introuvable

Hello luke spywoker,

les liens vers les sources tarball ne sont plus fonctionnels j'imagine que tu as pu changer d'herbergeur

j'utilise ton editeur pour mon projet en complément du reste.