Newsgroup: it.comp.programmare
Titolo: quale IDE sotto Linux?

Sto cominciando a scrivere qualcosa in C++ sotto Linux, ho provato Emacs 
ma NON mi piace assolutamente. Brrrrr!
Ho visto KDevelop 4 ma ha dei problemi di stabilitï¿œ... per ora lavoro 
con Geany che mi pare funzionare discretamente. Altrimenti??? Eclipse? 
Nient'altro?
 
Secondariamente, cosa c'ï¿œ sotto Linux per costruire visualmente le 
interfacce a finestre, come si fa in VS o in CBuilder? Il set di widget 
lo devo scegliere io ogni volta visto che non ce n'ï¿œ uno predefinito?
 
Terzo ed ultimo, fino a che punto ï¿œ una buona idea usare una IDE sotto 
Linux, invece di prendere un semplice text editor e lavorare a programmi 
separati usando direttamente la toolchain?

 separati usando direttamente la toolchain?
 
Solita risposta che do ad ogni post del genere:
1- usa vi + toolchain da riga di comando
2- scherzavo, lo dicevo solo perché lo faccio io. Scegli l'ambiente con cui ti trovi più a tuo agio.
Lato mio, ti posso giusto dare dei consigli per quello che ho capito lavorando ma YMMV.
Prima di tutto, quando devi fare interfacce lascia perdere il C++, usa un linguaggio più ad alto livello, magari con IDE integrato: come tutti i programmi unix-like lascia il core in C/C++ e programma separatamente una GUI che s'interfaccia con questo (è più semplice da fare e lascia la libertà di chiamare il tuo applicativo negli script, cosa che prima o poi *vorrai* fare).
Detto questo metti in fila i requisiti che vuoi il tuo IDE abbia (refactoring automatico, costruzione script di build (quasi fondamentale se non hai esperienza con gli autotools), auto-completamento, etc.etc.) e vedrai che ti si delineerà la strada verso il tool migliore per te.
Ciao!

 Detto questo metti in fila i requisiti che vuoi il tuo IDE abbia (refactoring automatico, costruzione script di build (quasi fondamentale se non hai esperienza con gli autotools), auto-completamento, etc.etc.) e vedrai che ti si delineerï¿½ la strada verso il tool migliore per te.
 
Mi sono sciroppato i tutorial e gli help di autoconf e automake.
Belli, ma se per caso uno programma in pascal? O in erlang?? :-)
 
Ho visto un programmino per creare interfacce visuali in GTK2, ora non 
mi ricordo come si chiama. Geany funziona bene ma fa casino con i 
progetti, ï¿½ peggio che se non esistessero :-(
Domani provo Anjuta, l'IDE di Gnome... se pure quella fa schifo metto su 
Eclipse e tanti saluti.
 
Make lo vorrei evitare proprio: dall'esperienza che ne ho qualsiasi 
makefile piï¿½ lungo di 100 linee diventa rapidamente illeggibile, e 
quindi inmanutenibile... ho installato Scons, da quello che ho letto 
*dovrebbe* essere meno incasinato. Ma comunque preferirei che a 
organizzare la build ci pensasse l'IDE.

 Nient&#39;altro?
 
QtCreator e Qt Quick per disegnare la GUI.
 
'ao

 organizzare la build ci pensasse l'IDE.
 
Aaaargh. Per me avere l'IDE che fa il mestiere del build-system e' una
bestemmia terribile. E in effetti se ne stanno rendendo conto un po'
tutti (pensa a tutto l'interesse per mvn e ivy e prima per ant). 
 
Posso essere d'accordo che l'IDE parli bene con il build-system, ma
delegare all'IDE il build vuole dire che (in ordine sparso):
 
1. leghi tutto il tuo team ad uno specifico IDE (intollerabile)
2. potenzialmente leghi tutto ad una specifica versione del tuo IDE,
anche se, in pratica, tendono ad essere piuttosto retro-compatibili.
3. non necessariamente le configurazioni degli IDE giocano bene con i
sistemi di version control: spesso c'e' una parte "user only" e una
parte "project", non tutti gli IDE hanno una chiara e incontrovertibile
distinizione fra le due. Aggiungo, spesso gli IDE si scrivono roba loro
(irrilevante da tenere in un VC) e incasinano il tutto. Niente di grave
se il build e' slegato dall'IDE, molto seccato altrimenti.
 
 
 
 
-- 
-riko
http://www.enrico-franchi.org/
 
http://rik0-techtemple.blogspot.com/
 

verso il tool migliore per te.
 
Per i build-tools, io mi sono trovato molto bene con CMake, decisamente
piu' comodo degli auto-tools. E, per i maniaci degli IDE, e' pure in
grado di generargli il progetto per l'IDE.


 biased). 
 
Ho una questione simile con LISP: sto avvicinando il linguaggio e lo 
strumento ufficiale è Emacs, io sono abituato ad usare vim per cui ho 
già le mie scorciatoie e plugin e non vorrei imbarcarmi nella laboriosa 
conversione ad Emacs (che ho già provato ma proprio non mi piglia). Per 
quanto ne sai quello che hai scritto si applica anche nel caso di LISP?
Finora ho montato slimv per la REPL e non vedo problemi ma non avendo 
esperienza in merito non so capire se mi mancherà qualcosa o meno.

 esperienza in merito non so capire se mi mancher� qualcosa o meno.
 
Io uso VIM anche per Common Lisp. ;)
 
Ma nel caso specifico mi sono accontentato parecchio. Diciamo che se ho
giusto i fondamentali va bene, perche' comunque non devo sviluppare
davvero in CL e quindi non mi paga tunarmi l'environment se della
produttivita' non mi importa.
 
Qualcosa te lo perdi, direi... slime e' parecchio maturo. Quindi o provi
slime + emacs + viper, pero' non saprei. 


 se il build e' slegato dall'IDE, molto seccato altrimenti.
 
Mah, anche su questo non sono molto d'accordo. Basta non versionare 
quelle parti.
In ogni caso, io uso raramente l'integrazione nell'IDE, tendo a tenere 
il VC e l'ambiente separati (vedi TortoiseSVN sotto Windows).
 
 

 il VC e l'ambiente separati (vedi TortoiseSVN sotto Windows).
 
Non sviluppo sotto windows. 
 
In generale un sistema di Vc moderno non e' interamente interfacciato
all'IDE (anche se ormai stanno facendo passi da gigante e le cose piu'
frequenti funzionano bene). Personalmente non ho nessun problema ad
usare CLI (e spesso lo faccio). Se sono dentro l'IDE trovo abbastanza
comodo pero' fare le cose da dentro. 
 
Ci sono proprio classi di cose che trovo superiori dentro l'IDE (e.g.,
IntelliJ nella finestra di commit mi fa anche vedere tutti i diff, cosa
che da cli devo ottenere con una combinazione di comandi -> piu' tempo).
Altre che sono piu' rapide da cli (e.g., i branch, mi ci trovo meglio).


 Non sviluppo sotto windows. 
 
Ecco, appunto :-P

 e devo dire che la produttivit� dei gruppi � calata di tanto.
 
Errata Corrige: NON � calata di tanto.
 

 Ecco, appunto :-P
 
Beh, mi trovo bene con il mio macbook... 


 Ma no dai, e' che uso spesso cose per cui gli IDE non ci sono.
 
Ma s�, scherzavo ;)
 


 
Finora mi salvo solo grazie alla barba nera e alla mancanza di bretelle.
Ma il mio destino e' segnato. E ad una soprendente eta' anagrafica per
ora lontana dall'incubo degli anta, anche se quando parlo di OSF1 non si
direbbe. ;)


 Mah, non so, chiaro che dipende dai contesti. A me è sempre capitato di lavorare in gruppi in cui si usava tutti gli stessi tool.
 
Nella mia ditta si è abbastanza liberarli sull'uso dell'IDE, ma negli 
anni ci siamo tutti convertiti a sviluppare con Visual Studio anche 
quando dobbiamo rilasciare sotto Linux. Con qualche script che ci siamo 
fatti in casa ora siamo decentemente produttivi. Certo, niente 
intellisense, ma pazienza.
 
Dovendo sviluppare programmi multi piattaforma alla fine è comodo usare 
un unico ambiente di sviluppo, e un unico ambiente di debug.
 
C'è infatti anche un simpatico tools a pagamento per fare debug da 
dentro Visual Studio di un programma che gira su una macchina linux. 
Simpatico, ma io che faccio una delle librerie multipiattaforma,
in realtà non ne sento bisogno.