TIGCC: demandes de fonctionnalités (feature requests)... - Page 4

squalyl (./70) :

Ximoon (./63) :
- Fichiers sources en feuilles MDI (argument de Kevin pour refuser : "je trouve ça inutile")

Plutôt qu'une barre d'onglets à la éclipse/netbeans/firefox?

Bah oui, je ne sais pas pourquoi vous parlez d'onglet, l'intérêt du MDI c'est de pouvoir voir plusieurs fichiers sources en même temps.

ok, je vois.

Ximoon (./91) :

squalyl (./70) :

Ximoon (./63) :
- Fichiers sources en feuilles MDI (argument de Kevin pour refuser : "je trouve ça inutile")

Plutôt qu'une barre d'onglets à la éclipse/netbeans/firefox?

Bah oui, je ne sais pas pourquoi vous parlez d'onglet, l'intérêt du MDI c'est de pouvoir voir plusieurs fichiers sources en même temps.

Oui mais les onglets à la Eclipse ou Netbeans(pas firefox) sont déplacables/dockables. Ce qui permet d'ouvrir plusieurs fichiers en même temps sans avoir a gérer plusieurs fenetres. Personellement j'aime boucoup ce système de fonctionnement.

Hmmm OK
Ceci dit, peu importe l'implémentation, le sens de la demande est effectivement de pouvoir avoir plusieurs fichiers ouverts en même temps

Vous avez des écrans en 2048×1536 ou quoi?
Il n'y a pas la place pour plusieurs sources!

Kevin Kofler (./95) :
Vous avez des écrans en 2048×1536 ou quoi?
Il n'y a pas la place pour plusieurs sources!

Alors explique moi pourquoi toutes les IDE dignes de ce nom permettent de faire ça.

Kevin Kofler (./95) :
Vous avez des écrans en 2048×1536 ou quoi?
Il n'y a pas la place pour plusieurs sources!

Ce n'est pas la question, ce n'est pas à toi de juger ça.

c'est faisable, c'est demandé par ton client. Ca devient la chose la plus importante à réaliser.

squalyl (./97) :
c'est faisable, c'est demandé par ton client. Ca devient la chose la plus importante à réaliser

autant c'est comme ça que ça marche quand tu es employé en entreprise, autant c'est pas vraiment non plus la façon dont marche le logiciel libre (peut-être en particulier pour des "petits projets")

le problème du LL c'est que la technique du soft devient plus importante que sa fonctionnalité, du coup ce genre de request est négligé.

c'est vraiment si chiant à réaliser?
c'est vraiment impossible de faire cohabiter le mode mdi avec autre chose avec une option?
ce petit projet peut il vraiment se permettre de perdre des utilisateurs?

ce sont effectivement des questions à poser.

tu ferais quoi toi?

squalyl (./99) :
tu ferais quoi toi?

en lisant ton post ./97, s'il s'adressait à moi, la première chose que je te dirais serait "vas te faire foutre" ; ne serait-ce que pour la non-compréhension de la philosophie libre, et pour la façon dont tu demandes les choses ^^

squalyl (./99) :
le problème du LL c'est que la technique du soft devient plus importante que sa fonctionnalité, du coup ce genre de request est négligé.

plus ou moins d'accord ; pour des petits projets "amateurs", oui, assez d'accord : un projet de ce genre, en tant que développeur, tu veux aussi t'amuser.
Mais sur un projet plus orienté "pro", tu peux être un peu plus modéré, et être plus enclin à répondre aux demandes de tes utilisateurs, même si elles ne correspondent pas à ta vision technique (ou d'utilisateur) du soft -- tout simplement parce que cette vision "pro" du projet l'emporte sur ta vision du soft.

squalyl (./99) :
ce petit projet peut il vraiment se permettre de perdre des utilisateurs?

Kevin étant le seul développeur du projet, à lui de voir ^^
Après, si vous n'êtes pas d'accord avec lui, un des avantages du libre, c'est que vous pouvez vous mettre à coder aussi (que ça soit en proposant des patches, en forkant, ou en participant à un fork ou un prjet "parallèle" existant)
Et si vous n'avez pas envie de participer... Bah, libre ou pas, dans ce cas, ça change pas grand chose ; tant pis pour vous, utilisez autre chose ^^

squalyl (./99) :
ce sont effectivement des questions à poser.

Une autre question éventuellement (ou pas) à se poser est "qu'est-ce que ça va apporter au projet ?"
Ne serait-ce qu'en termes de maintenabilité : plus de code, plus d'options, ça veut dire plus de risques de bugs, ça veut dire plus de régressions possibles, ça veut dire plus de tests à effectuer, et ça veut dire moins de temps pour d'autres fonctionnalités (et nous savons tous que nous n'avons déjà jamais assez de temps pour faire tout ce qu'on a en tête )
=> faire plaisir à un utilisateur ? ce n'est pas forcément le meilleur choix sur le long terme...

squale
Ceci dit, si Kevin répondait "ça me soûle" au lieu de "tu ne sais pas ce qui est bon pour toi, MOI je trouve ça inutile !", ça passerait peut-être mieux

./101 > certes

bon évidemment ça ramène à l'éternel débat du choix des features

et d'accord avec 100 aussi ^^

./101: . Ca fait des années qu'on lui explique, Kevin n'a toujours pas compris...

Ximoon (./96) :
Alors explique moi pourquoi toutes les IDE dignes de ce nom permettent de faire ça.

Ben, je ne sais pas, mais en tout cas ça m'agace de voir ma source réduite en une fenêtre de 320×200 pixels et devoir la maximiser avant de pouvoir travailler dessus.

Et +1 pour le ./100 de squale92.

Tu n'as qu'à acheter un 24", comme tout le monde


(vu que c'est le genre de réponse que tu affectionnes...)

Kevin Kofler (./105) :
Ben, je ne sais pas, mais en tout cas ça m'agace de voir ma source réduite en une fenêtre de 320×200 pixels et devoir la maximiser avant de pouvoir travailler dessus.

Moi aussi mais il y a des cas ou c'est pratique ponctuellement. C'est pour cela que j'apprécie le système d'onglet dockables d'Eclipse et Netbeans(c'est ceux que je connais le mieux, mais ça doit exister avec d'autres IDE, je suppose):
- En fonctionnement normal tu as toute ta fenêtre.
- Si tu en a ponctuellement besoin tu déplaces un onglet pour le docker, en dessus ou à droite
- Tu n'as pas a t'embêter a organiser les fenêtre.

Après que tu trouves que le rapport intérêt/complexité de la feature ne vaut pas la peine, je suis entièrement d'accord.
C'est sur que c'est un comportement, complexe à mettre en place, surtout si c'est dans un framework qui n'est pas fait pour le gérer.

C'est un des cas qui me fait dire qu'il vaut peut-être mieux adapter un IDE existant que de reprendre tout from scratch. Un bon IDE gère déjà ça ainsi que tout un tas de petit trucs utiles, mais trop couteux à implémenter individuellement par rapport à l'intérêt. Pourtant tous ces petit détails accumulés rendent le tout vraiment plus pratique.

Bon, je ne suis pas un expert de Delphi, mais en ce qui concerne KTIGCC, pour avoir cette fonctionnalité, il faudrait remplacer le QSplitter par des QDockWidget. Ce serait intéressant à essayer, mais ça aurait probablement aussi des désavantages, genre le positionnement deviendrait plus complexe (avec le splitter, on ne peut pas rendre ça trop bordélique, on peut déplacer à gauche ou à droite et c'est tout).

(sinon, pour répondre à ta question, 1680*1050 chez moi, 1280*1024 au boulot, et je travaille presque en permanence sur plusieurs fichiers sources en parallèle)

C'est clair que splitter les sources, c'est chiant (sauf peut-être avec une séparation verticale, mais pas horizontale). Je sais pas pour vous dans d'autres langages, mais en assembleur, il me faut un maximum de lignes affichées (du coup ma "barre des tâches" est à gauche du bureau (1280*1024), il me reste tout ce que je veux horizontalement).

pareil, mais si ça plait à quelques, c'est ptet une option à ajouter à l'ide. mode mdi ou mode pas mdi.

Ah mais bien sûr ! (j'aurais p-ê dû le préciser en fait )

J'ai créé http://tichessteamhq.yuku.com/topic/4670 pour discuter de trois éléments de la todo/wish list de TIGCC-fork, dont au moins deux sont aussi sur la todo list de Kevin pour TIGCC.
Ca serait sympa que la discussion ne soit pas qu'un tête à tête Kevin / Lionel

Merci d'avance

Kevin, veux-tu STP nous reposter la liste des features qu'ont l'IDE Delphi et KTIGCC, que n'ont pas, built-in, d'autres IDE ?

Non, je ne veux pas.
Franchement, je l'ai répété au moins 100 fois et à chaque fois je dois me rappeler de tout et le retaper (je ne l'ai pas prêt pour le copier-coller), j'en ai marre, utilise le moteur de recherche...

je ne l'ai pas prêt pour le copier-coller

Tu as tort

Il n'y en a pas tant que ça, en fait.

J'ai retrouvé, dans "kdewin foutage de gueule" ( topics/113677-kdewin-foutage-de-geule ), c'est à dire le topic déclencheur du fork,

sinon te fais pas chier, c'est juste un proof of concept [des projets TIGCC avec Code::Blocks] pour prouver qu'on peut utiliser TIGCC avec autre chose que TIGCC IDE

Et tu perds:
* des switches par défaut raisonnables pour les nouveaux projets!!! Rien que pour ça, je déconseille totalement l'utilisation de la ligne de commande ou d'un EDI autre que TIGCC IDE ou KTIGCC: nos EDIs savent ce qu'est un nouveau projet et ce qui est un ancien projet réouvert, et ils appliquent automatiquement les options fortement conseillées (lire: si vous n'avez pas une très bonne raison de ne pas les mettre, c'est un bogue de ne pas les mettre!) pour les nouveaux projets. La ligne de commande est obligée de présupposer que tous les projets pourraient être d'anciens projets et donc garder la compatibilité antérieure, ce qui fait que les réglages par défaut sont totalement inutilisables et qu'il faut passer au minimum (sauf exceptions justifiées) -Os -ffunction-sections -fdata-sections --optimize-code --cut-ranges --reorder-sections --merge-constants --remove-unused -Wall -Wextra -Wwrite-strings. L'EDI met aussi le MIN_AMS par défaut à 100 pour les nouveaux projets (optimal parce que ça ne nécessite pas de détection de la version minimale), pour les anciens projets et donc aussi en ligne de commande, le MIN_AMS par défaut est 101 pour des raisons de compatibilité.
* un EDI adapté à la tâche, qui présente toutes les fonctions utiles pour la programmation avec TIGCC (comme les dialogues des options du projet avec les options de TIGCCLIB, la complétion qui connaît les fonctions de TIGCCLIB etc.), et qui ne présente pas des fonctionnalités qui n'ont rien à voir, genre tout ce qui est spécifique au C++.
* l'intégration avec TiEmu et son débogueur C. Bref, je ne comprends pas du tout cette manie de vouloir à tout prix utiliser autre chose que les EDIs que nous proposons. TIGCC est une solution complète, l'EDI en fait partie intégrante. Le compilateur en ligne de commande n'existe que pour la compatibilité avec les anciens projets, je déconseille absolument l'utilisation (même indirectement à travers un EDI qui n'est pas celui de TIGCC) pour tout nouveau projet. (Et attention, ça ne veut pas dire qu'il faut appeler les composants directement, ce n'est pas du tout supporté, ça crée des problèmes de portabilité (cf. ld-tigcc qui n'existe pas en tant qu'exécutable sous W32) et les composants peuvent changer à tout moment sans avertissement. tigcc et tprbuilder sont les seules interfaces documentées pour la ligne de commande.)

Se débarrasser autant que possible des outils en ligne de commande et tout intégrer dans un IDE est une façon possible de voir les choses.

Une autre possible est, au contaire, de déplacer le maximum de choses hors de l'IDE lui-même, et faire de l'IDE un front-end pour les outils qui font le vrai travail. Ca vaut au moins pour:
[ul][li]pour la communication avec les émulateurs & calculettes réelles[/li]
[li]pour la construction d'un projet (en ajoutant à tprbuilder un mode de compatibilité avec le comportement de IDE vis à vis des dossiers virtuels)[/li][/ul]
Je me dis que ça pourrait aussi valoir pour Project -> Options...

Mais il n'y a pas tout dans le post que tu viens de citer, justement. Par exemple la lecture/écriture des sources en le charset de la calculatrice.

Mouais. Je ne pense pas être le seul à ne pas considérer cette gestion du charset comme absolument vitale. D'autant plus que l'IDE Delphi, utilisé par plus ou moins 90% des utilisateurs de TIGCC (les utilisateurs de Windows), ne la propose pas.

D'autres features ?


J'ai édité mon post précédent juste après que tu aies posté le tien.

Lionel Debroux (./119) :
Mouais. Je ne pense pas être le seul à ne pas considérer cette gestion du charset comme absolument vitale. D'autant plus que l'IDE Delphi, utilisé par plus ou moins 90% des utilisateurs de TIGCC (les utilisateurs de Windows), ne la propose pas.

Raison de plus d'utiliser KTIGCC partout.

Cela dit, ce n'est effecitvement pas vital sur les plateformes utilisant une variante de l'ISO-8859-1 comme charset système.

D'autres features ?

* Les options du projet connaissent aussi les options de ld-tigcc.
* L'envoi aux calculatrices réelles (mais là encore l'EDI en Delphi est incomplet parce qu'il manque la gestion des câbles USB).
* La compilation dans un dossier temporaire, ce qui permet:
- de compiler un projet sans l'enregistrer et
- d'utiliser les dossiers virtuels.
Mais j'en oublie sans doute.

Lionel Debroux (./117) :
Une autre possible est, au contaire, de déplacer le maximum de choses hors de l'IDE lui-même, et faire de l'IDE un front-end pour les outils qui font le vrai travail. Ca vaut au moins pour:
[ul][li]pour la communication avec les émulateurs & calculettes réelles[/li]
[li]pour la construction d'un projet (en ajoutant à tprbuilder un mode de compatibilité avec le comportement de IDE vis à vis des dossiers virtuels)[/li][/ul]

Ce n'est pas aussi simple que ça, parce que ces fonctionnalités ont tous une partie graphique (progress bar etc.).

Et l'EDI ne peut pas compiler avec tprbuilder parce que c'est l'EDI qui doit enregistrer les fichiers dans le dossier temporaire parce que seul l'EDI connaît la version actuelle, qui n'est pas forcément enregistrée.

Je me dis que ça pourrait aussi valoir pour Project -> Options...

C'est une fonctionnalité purement graphique, il n'y a rien à déplacer en ligne de commande là.