Newsgroup: it.comp.os.linux.development
Titolo: [OT] linux e sviluppo

Ciao a tutti,
 chi vi scrive e' un programmatore C++ che purtroppo lavora in un ambiente
"microsoft certified".
Riesco ad utilizzare linux solo nel tempo libero, la domanda e':
ma voi riuscite a sviluppare su linux per lavoro?
Nella mia esperinza quotidiana vedo che la maggior parte di lavoro per i
sistemi UNIX e' di tipo sistemistico, e soprattutto meno che mai ho visto
necessita' di applicazioni desktop con interfaccia grafica.
Qual'e' la vostra esperienza e opinione in merito?
Grazie e ciao,
    Didimo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 necessita' di applicazioni desktop con interfaccia grafica.
Forse perché ormai l'"hard work" non è più nella programmazione delle
interfaccie grafiche?
Detto in altro modo: ormai tra Web applications & servers dislocati mi
pare che l'esigenza della grafica sia scemata...
Ciao!
Azathot

pare che l'esigenza della grafica sia scemata...
In realtà, io credo che l'esigenza della grafica non ci sia mai stata,
almeno per tutto quel software che, appunto, non ha bisogno della
grafica.  Oggi, per esempio, sotto Windows un gestionale si scrive con
interfaccia grafica, ma l'interfaccia vecchio stile (a caratteri) io
la preferirei di gran lunga, per un'applicazione del genere.  In tutti
quei sistemi in cui la grafica non è una scelta obbligata, alla fine
si sceglie quello che è meglio per l'utente (è probabile che per
questo, sotto Unix/Linux, si preferisca un'interfaccia standard a
caratteri per molte applicazioni).  Ricordo che in una filiale della
Chrysler di Roma avevano dei terminali IBM collegati a un AS/400 e
quando ho visto le operatrici lavorare, mi sono reso conto che era di
gran lunga l'interfaccia migliore che io abbia mai visto per un
programma gestionale. 
-- 
Andrea Laforgia
#exclude <windows.h>

 pare che l'esigenza della grafica sia scemata...
Sono d'accordo, ma quello su cui mi interessava avere la vostra opinione
e' essenzialmente capire se esiste la possibilita' concreta di lavorare su
linux, la domanda in se e' banale e la risposta e' certamente si, pero'
guardandomi intorno vedo che la stragrande maggioranza delle aziende
offrono soluzioni(?) basate su piattaforma m$...
ciao Didimo


 offrono soluzioni(?) basate su piattaforma m$...
Ciao, io lavoro su Linux e vado a lavorare con Linux.
Ora sviluppo applicazioni web, intranet più che altro, e andrò a fare 
automazione industriale tra pochissimo.
In Italia è più dura che altrove, ma non è una questione tecnica,
solamente manageriale.
I miei due cents della giornata sono che, al momento, ti conviene tenere i
piedi in due scarpe (vabbè... mostrando chiaramente le tue preferenze
:p)... quando il guadagno sarà palese i managerucoli vorranno attaccare
come sempre l'ultimo carro in fondo al treno e salirà molto la richiesta. 
Ciao,
	Nicholas

"Andrea Laforgia" <x@x.x> ha scritto nel messaggio
news:ppfl3vkvea7lfscpr...@4ax.com...

Sono d'accordo con te (mi occupo anche di sviluppo per AS/400 e di 5250 ne
ho vista parecchia!!!!).
Sta di fatto che IBM sta cercando con tutte le forze di portare la grafica
in ambiente ISeries (vedi Webfacing e altre...).
Sara' utile questo???
Ma.......


 offrono soluzioni(?) basate su piattaforma m$...
Guardi le aziende sbagliate.
Ciao!
Azathot

offrono soluzioni(?) basate su piattaforma m$...
Dipende dal tipo di attività che svolge l'azienda, in particolare.
Se lo sviluppo del software è destinato a un pubblico di utenti
"normali" (ovvero che lavorano in ambiti gestionali/amministrativi) è
molto più frequente dover lavorare su piattaforma Microsoft e magari
integrarsi con le applicazioni d'ufficio.  D'altronde questo è anche
giustificato, Windows è il sistema operativo più diffuso lato desktop
e più conosciuto dagli utenti "normali".  In ambito più tecnico, è
possibile che Linux sia maggiormente utilizzato.



La mia esperienza e` un po' contraria, nel senso che mi sono spesso
trovato a lottare per riuscire a stare lontano dalle GUI (anche sotto
unix) non sempre con successo.
Ultimamente mi dice bene comunque, speriamo che duri!
Ciao e in bocca al lupo!
	Andrea

 unix) non sempre con successo.
Perchè stare lontano dalle GUI ? Che hanno di male.
Soprattutto che c'entra con lo sviluppo sotto Linux ? 
Ciao,
	Nicholas

 Perchè stare lontano dalle GUI ? Che hanno di male.
Ti fanno concentrare sui dettagli distraendoti dal cuore del problema, che
di solito è fare un programma che funzioni.
Azathot



Questo è un problema del programmatore, non del fatto che esista o meno
una GUI.
Nel momento in cui un programma ha una GUI si allarga la base di utenti,
conseguentemente bug report e richiesta di features (di fatto quindi il
programma tende a funzionare sempre di più).
Dubito che qualcuno riesca a pensare a Linux senza GNUCash, GNUmeric, The
Gimp, BlueFish o Mozilla (e molti altri), dubito anche del fatto che
programmi di questo tipo (ovviamente togliendo The Gimp e Mozilla) siano 
fattibili senza una GUI. Tra l'altro funzionano discretamente bene.
Sicuramente non avrebbe il successo che ha oggi.

una GUI.
...e non è neanche vero che l'esistenza di una GUI fa concentrare su
"dettagli" e distrae dal cuore del problema, anzi spesso è l'esatto
contrario: con Delphi (sotto Win) e con Kylix (sotto Linux) si impara
proprio ad astrarre dai dettagli implementativi della GUI, grazie alla
libreria precostruita di base, la CLX.


 libreria precostruita di base, la CLX.
Certo, però hanno un difetto molto grosso: il linguaggio di sviluppo è il
pascal, mentre sono decenni che si programma usando il C sotto Linux.
Azathot

 Sicuramente non avrebbe il successo che ha oggi.
I webserver installati non ti danno ragione.
Ciao
Azathot

	Nicholas
Ciao
	Andrea
-- 
Per favore non inviatemi file in formato .exe .doc .xls o .pps
Please, don't send me .exe .doc .xls or .pps attachments

 [...]
E' un bellissimo post, che conserverň!
Grazie!
Azathot

 pascal, mentre sono decenni che si programma usando il C sotto Linux.
Kylix 3 ha due ambienti di sviluppo: Pascal e C++.
-- 
Vincenzo

 Kylix 3 ha due ambienti di sviluppo: Pascal e C++.
C++ ANSI compliant, I suppose...
Altrimenti, è come non averlo...
Azathot ... che, ovviamente, deve ancora vedere un compilatore con
            ambiente che possa gareggiare con un compilatore GNU C++...

 I webserver installati non ti danno ragione.
? X c'è e da prima che fosse possibile far girare Apache su Linux, non
vedo un senso nella tua affermazione, oltra ad essere indimostrabile.
Guarda caso i miglioramenti di Linux vanno di pari passo con
l'allargamento della base di utenza.
Anche perchè al di la di Apache sarebbe interessante usare il sistema 
operativo per qualcosa di differente che 'servire pagine'.
Saluti,
	Nicholas

 grafiche su unix ne ho viste piu` d'una!
Ho interpretato male il tuo post infatti, sorry.
E' che capita di tanto in tanto di trovare gente che trova le GUI
universalmente inutili. 
Bada bene, nello specifico di un wget o anche di un mutt può essere vero,
ma come regola generale assolutamente no, anzi... :)
Saluti,
	Nicholas



Il C ha un difetto molto grosso: i programmatori Delphi magari non lo
conoscono, e portare sviluppatori da Windows a Linux è bene.
Inoltre direi che si utilizza anche qualche altro linguaggio oltre al C,
tipo tutti. Nonostante questo le GTK+ sono in C.

 universalmente inutili. 
Domanda a bruciapelo: è possibile pensare a disaccopiare sempre una
interfaccia grafica dal "core" di una applicazione?
Se sì (come credo) ecco l'inutilità delle GUI!
Azathot ... che lascia l'onere a programmatori di scarso livello ...

 conoscono, e portare sviluppatori da Windows a Linux è bene.
A) Non tutti i programmatori Windows usano Delphi;
B) Non tutti i programmatori Windows sono interessati a passare a Linux;
C) Non tutti i programmatori Delphi sono in grado di programmare
decentemente sotto una piattaforma diversa da Windows;
D) Non tutti i programmatori Windows sono capaci di produrre buoni
programmi.
Il rischio del passaggio indiscriminato è: software pessimo sotto Linux.
La barriera del C è decisamente la soluzione migliore per fare da barriera
di contenimento ed evitare che programmi spazzatura arrivino sotto Linux.
Azathot ... che ne ha viste di ciofeghe sotto Delphi ...

 operativo per qualcosa di differente che 'servire pagine'.
Mi pare che Apache sia il cardine di molto software "distribuito"...
Azathot ... che, invece, ritiene fondamentale un buon core e ricamarci
            attorno una interfaccia grafica, come avviene per la maggior 
            parte del software Linux attuale...

Kylix 3 ha due ambienti di sviluppo: Pascal e C++.
I messaggi dell'elemento in questione non li leggo, ma il linguaggio
alla base di Kylix NON è Pascal, ma un linguaggio piuttosto evoluto
rispetto al vecchio standard.  In ogni caso, l'efficacia di un
linguaggio si dimostra con i risultati ottenuti e con Delphi e con
Kylix i risultati sono MOLTO buoni.  Tutto il resto è pura religiosità
e discutere di questo non mi interessa.


             ambiente che possa gareggiare con un compilatore GNU C++...
gareggiare in che senso? Se parli di velocita` di compilazione ci
sono ordini di grandezza a favore di Borland.
-- 
Vincenzo

 sono ordini di grandezza a favore di Borland.
Aderenza allo standard, efficienza del codice prodotto, portabilità su
diverse piattaforme, correttezza delle ottimizzazioni.
Ciao!
Azathot

 Se sì (come credo) ecco l'inutilità delle GUI!
Rallenta!  E' possibile separare anche gli altri tipi di interfaccia
(TUI, CLI) dal core di una applicazione, questo non le rende inutili.
Bash non sta mica nel kernel. ;-)

 Al di la del 'punto' non vedo motivazioni, come non aver detto nulla.
Calma gente. :-) E' normale che sviluppare un'interfaccia (qualunque
tipo) distragga dal cuore del problema!  Scriviamo il programma per il
cuore del problema, e l'interfaccia per l'utente, o no?
Semplicemente, credo, l'obiezione di NoSpamThanks nei confronti delle
interfacce grafiche e` che portano via piu` tempo delle altre nella
realizzazione, quindi a parita` di tempo concesso per un programma,
svilupparlo con l'interfaccia grafica significhera` necessariamente
meno tempo passato sul cuore del problema che se non si fosse
sviluppato a linea di comando.  Hey, e` solo aritmetica! :-)

 Bash non sta mica nel kernel. ;-)
Però non si sviluppano device drivers con la shell!
Azathot
P.S. Per me la miglior interfaccia è quella che non si vede!

 Mi pare che Apache sia il cardine di molto software "distribuito"...
Quindi tu vorresti che Linux vivesse in funzione di Apache :D
Ok, inquadrato il soggetto, mi fermo qui. Per fortuna che sono rimasti ben
pochi sviluppatori con questa mentalità, altrimenti saremmo ancora nelle
cantine dei nerd anzichè lavorarci.
Addio,
	Nicholas

 Azathot ... che lascia l'onere a programmatori di scarso livello ...
ROTFL !
Senti, intanto che ci siamo, mi fai vedere qualche tuo contributo dato che
sei un programmatore di 'alto livello' ?

 P.S. Per me la miglior interfaccia è quella che non si vede!
...tipo?

 sviluppato a linea di comando.
Ma vogliono dire, come ho già detto, un maggiore feedback, il che è
completamente in linea con la filosofia del 'release first'.
O forse 'concentrandovi' sul problema siete in grado di risolvere tutti i
bug senza avere una base di utenza ?
Strano, perchè ad esempio Sendmail e Bind di bachi ne hanno avuti
parecchi... qual'è stato il fattore distraente in quel caso ?
Cmq non credo che sia il pensiero di NoSpamThanks, credo sia più qualcosa
del tipo 'ahhh, ma le interfacce sono da l00s3r, io sono un Hax0r e non
ne ho bisogno' :p
[...]

 ...tipo?
Tipo: televisore, videoregistratore, lavatrice, lavastoviglie, automobile,
...
Ma nel futuro ci vedrei: computer comandati via voce.
Ciao!
Azathot

 sei un programmatore di 'alto livello' ?
Ma vai sempre in puzza o ci vai solo ogni tanto? cmq, io faccio programmi
senza interfaccia utente, di norma... hint: qualcosa che ha a che vedere
con il suono...
Azathot

 Quindi tu vorresti che Linux vivesse in funzione di Apache :D
Evidentemente ci sono dei momenti, nella vita di una persona, in cui hai
la netta sensazione che l'interlocutore non ti comprenda.
Questo è uno di essi.
Azathot ... che spera che ricolleghi il cervello prima di proseguire ...

 diverse piattaforme, correttezza delle ottimizzazioni.
Aderenza allo standard ti ho gia` risposto, come efficienza del codice
(dimensioni e velocita`) Borland non ha mai brillato particolarmente, ma 
dato l'hardware che c'e` in giro oggi (parlo dal PII in su) non ho mai
visto problemi in questo senso. La portabilita` e` limitata a Windows
e Linux, ma stiamo parlando di portabilita` di un framework (CLX),
non solo del compilatore. Non esiste nessun'altra alternativa veramente
RAD ad oggi che ti permetta di intraprendere lo sviluppo tra le due
piattaforme suddette.
-- 
Vincenzo

 con il suono...
Non preoccuparti, riuscirò ad usarli comunque (spero).
Dammi un link, ora che mi hai incuriosito voglio vedere, dato che hai una
così alta stima di te stesso adesso non puoi tirarti indietro.

 così alta stima di te stesso adesso non puoi tirarti indietro.
Non ci sono link. Ci sono solo numeri di telefono. E voci.
Azathot ... numeri di telefono internazionali, beninteso ...

 piattaforme suddette.
Tranne quelle autosviluppate, suppongo.
Ciao!
Azathot

 Azathot ... che spera che ricolleghi il cervello prima di proseguire ...
Si, molto interessante,
Nicholas ... che spera che l'arrampicata sugli specchi non distragga
troppo Azathot dalla programmazione

 Tranne quelle autosviluppate, suppongo.
Ho scritto RAD.
-- 
Vincenzo

 Ho scritto RAD.
???
Ciao!
Azathot

 Definire "programmi più utilizzati sotto Linux".
Li ho elencati sopra. Non è un concetto difficile, ce la puoi fare.

 Li ho elencati sopra. Non č un concetto difficile, ce la puoi fare.
Non sono certo quelli che hai elencato sopra. Dalla mia personale indagine
i piů usati programmi sotto Linux sono:
* apache
* pop3d
* sendmail
* bind
Ciao!
Azathot

 le due piattaforme suddette.
si vede che non conoscete python: GUI che piu' RAD non si puo', facile 
inserimenti di codice compilato in altri linguaggi, assolutamente 
portabile non solo su Win e *nix
-- 
#include <stdio.h>/* (C) BW2K+3 This code is released under GPL 2+ */
int main(){char c[]={98,108,97,99,107,119,111,108,102,64,100,101,115,112,
97,109,109,101,100,46,99,111,109,32,119,101,98,46,116,105,115,99,97,108,
105,46,105,116,47,98,108,97,107,119,111,108,102,0};printf("%s\n",c);}

 di solito è fare un programma che funzioni.
Sono daccordo, dove lavoro (in ambiente M$ pero') a volte molto spesso i
clienti, si impuntano sulla scrittina rossa invece che nera o sul logo un po
+ spostato o boiate del genere e non provano neppure a vedere se il
programma funziona (a volte mi verrebbe il desiderio di consegnarli solo le
GUI senza il codice...hihhi :-D ) ....
mio parere ...
ciao
CLaudio .

 fare tu.
...
Anche io mi rompo di fare il documento di specifica di requisiti funzionali.
E anche l'ER, e pure i diagrammi UML. Ma se non li facessi sarebbe peggio.
Allo stesso modo progettare un'interfaccia a prova di utente e' un
lavoro spesso schifato, ma che ha una grossissima ragion d'essere.
Se qualcuno che non puoi mandare a fare in culo si sente in dovere di
metterci il naso possono bastare poche misure per zittirlo.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
-<! Computer programmers never die, they just raise an unhandled exception.!>-

 ne ho bisogno' :p
Gia`, temo; speravo di trovare un terreno comune.

 Ma nel futuro ci vedrei: computer comandati via voce.
Il che va comunemente sotto il nome di interfaccia vocale.

 Tipo: televisore, videoregistratore, lavatrice, lavastoviglie, automobile,
Secondo me l'interfaccia del televisore e' il telecomando, per lavatrice e
lavastoviglie manopole e/o pulsanti, e cosi' via.
E' cio' che l'utente si trova davanti per utilizzare il programma/oggetto
imho.
Ciao,
Riccardo
-- 
-=Riccardo Galli=-
 _,e.
s~  ``
 ~@.   ideralis Programs
.   ol 
 `**~  
http://www.sideralis.net

 Azathot
Certo che se limiti la sfera dei programmi a 4 (quattro!) titoli, e' ben
difficile rientrare nella rosa.
Programmi come gimp sono universalmente riconosciuti come tra i piu'
utilizzati.
notare il 'tra', e non tirarne fuori una disputa dialettica, che e' fuori
luogo.
Per alcuni programmi la gui e' fondamentale, come per l'appunto i
programmi di grafica. Non dico che sia impossibile farne senza, ma
mancherebbe quella usabilita' per la quale sono nati gli ambienti grafici.


 si vede che non conoscete python: GUI che piu' RAD non si puo',
Non tai parlando di idle, vero?
Alessandro
...incuriosito.

 E' cio' che l'utente si trova davanti per utilizzare il programma/oggetto
Domanda: hai mai dovuto addestrarti per usare un televisore?
Ciao!
Azathot ... domanda suggestiva, IMHO ...

 Il che va comunemente sotto il nome di interfaccia vocale.
Sì ma, siccome non richiede addestramento, chiamarla interfaccia è, IMHO,
eccessivo. Diciamo che per me interfaccia è un accordo *stringente* tra due
parti, una che si chiama "cliente" ed una "servente". La servente fornisce
delle funzionalità con delle regole per usarla, mentre la parte cliente
conosce l'elenco delle funzionalità e come usarle. Però, per potere usare
tali funzionalità, il cliente deve essere "addestrato" -- deve conoscerle,
deve saperle usare, ecc...
Cosa succede quando un cliente non ha bisogno di essere addestrato per
usare un servente? Succede che non esiste, di fatto, una interfaccia.
Non devi essere addestrato per parlare con una macchina -- ci parli e
basta.
Ciao!
Azathot

 ne ho bisogno' :p
Lo sai che è razzismo, puro e semplice?
Non sai confrontarti con gli altri come le persone normali?
Bah...
Azathot

 Non tai parlando di idle, vero?
idle e' solo una shell python, un po' come tcsh per tcl/tk
prova a farti un giro sul sito italiano di python, o su quello 
internazionale
http://www.python.it
http://www.python.org


 Domanda: hai mai dovuto addestrarti per usare un televisore?
Scherzi ?
Assolutamente si: hai un sesto senso che ti dice quale pulsante fa cosa ?

 dell'interpretazione che se ne vuole dare.
Ok, sono d'accordo.
Ciao,
	Nicholas



Beh... io consegno innanzitutto un prototipo che molto spesso *è*
l'interfaccia senza codice.
Ciao,
	Nicholas



Io uso Komodo se ti interessa. E' una applicazione sviluppata su
piattaforma Mozilla che a mio avviso vale molto (anche se costa
fottutamente tanto cazzo).
Ma non credo sia quello che intende BW 2K+2, lui prende letteralmente
Rapid Application Development e in effetti Python permette di sviluppare
rapidamente applicazioni anche complesse.
Ci sto dando dentro in questi giorni e devo dire che mi trova
totalmente d'accordo.
Ciao,
	Nicholas

universalmente inutili. 
Certamente, come del resto chi invece le considera essenziali a 
prescindere.
Per fortuna esiste l'aurea via di mezzo!
Ciao
	Andrea
-- 
Per favore non inviatemi file in formato .exe .doc .xls o .pps
Please, don't send me .exe .doc .xls or .pps attachments


In genere se sono in grado di zittire qualcuno sono anche in grado di mandarlo 
anche a fare in culo (o a coniugare mirabilmente le due cose ;-), non sempre
e` vero il viceversa.


 portabile non solo su Win e *nix
Parliamone. Un RAD per la GUI? Glade, ma pygtk1 non e' il massimo della
portabilita'. wxWindows (cioe' wxglade e wxdesigner) non e' completissimo
come binding e il porting su MacOS e' "discutibile". In generale comunque ti
do ragione, e' uno dei miei linguaggi preferiti.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Heavy Metal Or No Metal At All! Whimps And Posers Leave The Hall !>-
 	 			Manowar - Metal Warriors

 Assolutamente si: hai un sesto senso che ti dice quale pulsante fa cosa ?
No, ma se vedo dei numeri disposti a mo' di tastiera... inoltre, il
pulsande di spegnimento è sempre rosso...
Azathot

 pulsande di spegnimento è sempre rosso...
Si`, ma il 99.9% dei televisori hanno i canali desintonizzati quando li
compri, e la prima cosa che fai e` cercare nel manuale le istruzioni per
sintonizzarli, perche` sono tutti diversi.
C'e` una interfaccia standardizzata (i numerini) e una no (il
sintonizzatore, il televideo, le regolazioni di contrasto, luminosita` e
colore, ecc).
Per le interfacce utente e` lo stesso.
Tutti sanno che per aprire un file devi andare sul menu "File" e
scegliere "Apri". Si presuppone che uno sappia cosa e` un file e che
bisogna aprirlo, come si presuppone che uno sappia cosa e` un programma
televisivo e che bisogna accendere la TV per vederlo, e che e`
memorizzato in un certo numerino.
Anche nei programmi c'e` una interfaccia standardizzata e una no (e c'e`
chi cerca di cambiare gli standard, ma questo e` un altro discorso).
La progettazione dell'interfaccia e` proprio fatta sulla parte non
standardizzata, solitamente.
Io sono per la via di mezzo: un programma con interfaccia inesistente
non serve a nessuno, uno con interfaccia eccessiva serve a pochi. Uno
con interfaccia intuitiva, ben progettata, ma che faccia fare delle
funzioni utili al programma, e` utile.
Perdere tempo sull'interfaccia va bene fino a un certo punto.
Ci sono piu` utenti Linux che usano TMPGEnc sotto Windows di quanti ce
ne siano che usano mencoder, anche se e` piu` potente, perche` e` un
incubo ricordarsi tutti i parametri possibili e farli interagire tra di
loro nel miglior modo possibile. E infatti stanno nascendo interfacce
(sotto forma di script, per ora, probabilmente presto ce ne saranno di
grafiche con preview e selezione grafica delle scene e altro.
Se si fosse partiti dall'interfaccia probabilmente non si avrebbe la
potenza che ha adesso mencoder, ma se questa potenza rimanesse
inutilizzata sarebbe come non averla.
Bye.

 basta.
Come ho detto, abbiamo differenti idee di interfaccia.  Una
interfaccia `semplice' e `naturale' rimane una interfaccia.

 pulsande di spegnimento è sempre rosso...
La nozione che il pulsante di spegnimento del televisore sia rosso non
e` codificato nel genoma umano.  La prima volta che si prende in mano
un telecomando, si *impara* che su *quel* telecomando, il pulsante di
spegnimento e` rosso.  La seconda volta, si comincia a *generalizzare*
la nozione, e poiche' il codice visuale dei telecomandi e` abbastanza
costante in questo senso, la generalizzazione risulta utile.
Di fatti, c'e` chi sostiene e non senza attendibilita` che il
vantaggio delle GUI consista non tanto nel trovare metafore grafiche,
quanto nell'averne standardizzato una buona quantita`.  
Riporto un post da comp.lang.scheme:
From: 
ol...@pobox.com
 (
ol...@pobox.com
)
Newsgroups: comp.lang.scheme
Subject: Graphical vs. textual notations
Date: 10 Dec 2002 12:40:52 -0800
Perhaps the paper "Why looking isn't always seeing: readership skills
and graphical programming" by Marian Petre (Comm. ACM, v38:6, June
1995, pp. 33 - 44) is relevant:
"The topic of the article is graphical notation, especially
programming notation. The article reports several _experimental_
studies of reading comprehension of visual vs. textual programs and
schematics. The article has many illustrative examples from the
studies. The main result: overall, graphics was _significantly_ slower
than text, both for novice and experts. Novices were especially
confused by visual notation: they don't know where to start looking
and how to continue looking...."
	The full summary is available at
 
http://lambda.weblogs.com/discuss/msgReader$1987
See also
 
http://lambda.weblogs.com/discuss/msgReader$1926
about musical notation (at the very end). The musical notation is far
more complex and richer than it may appear; therefore, it takes years
and years to master.
Another relevant article is
 
http://www2.linuxjournal.com/lj-issues/issue74/3959.html
This is a book review by Paul Holloway. His article is a case when the
review is far better than the book. Here's a small excerpt:
"When we speak of icons or desktops as being ``metaphors'', we mean
that icons, desktops and such, are analogies where the visual likeness
to some physical object or action should suggest a certain function of
the computer program. Stephenson's argument, then, is that the
analogies are poor. <strong> But mainstream GUIs are not based on
analogies (let alone metaphors); they are based on visual codes
</strong>. I work with several hundred new and experienced computers
users every year and I see no evidence that any of them consider the
things on their computer screens as analogies for anything. They must
be taught the visual code of the GUI, and until they have learned it,
those little symbols on the screen do not suggest any function. Once
they learn the code, the icons acquire meaning. These interfaces are
simply learned, and the significant revolution in their design was not
by analogy, but through the standardization of the visual code.
The danger of the GUI by ``metaphor'' argument is that it can be taken
as a plea for better ``metaphors'' (i.e., better analogies), while in
fact these interfaces need to be examined for what they are:
<strong>lists of canned commands, the existence of which the user must
simply learn.</strong> When seen this way, we can try to think of
better commands to store, or we can think about ways to let users
build commands of their own that the programmer never thought of, all
the while keeping within some more-or-less standard visual code. But
if we only try to think of better analogies, we will never get
anyplace new and useful."

 do ragione, e' uno dei miei linguaggi preferiti.
Beh, ci sarebbe TkInter e, sperando che il progetto non si affossi (e
sulla ml tutto tace) 
anygui.org
.
Ma Python già per i fatti suoi è un linguaggio RAD, senza bisogno di tool
come wxGlade, almeno per me.

On Wed, 05 Feb 2003 09:26:35 +0100, NoSpamThanks wrote:

Oh, non so te ma la mia interazione con il televisore non è così
semplice e il mio telecomando è formato da un bel po' di pulsanti, non
solo numeri e pulsante di spegnimento (che non è rosso ma uguale a tutti
gli altri). Più che altro il pulsante di spegnimento è sempre in basso a
destra.

 destra.
Ho un televisore in cui e` in fondo al centro. E lo spegnimento del mio 
videoregistratore e` in alto, a sinistra se ben ricordo.
Tanto per mescolare un po` le carte :)
-- 
Ikitt 
*** mailserver: 
freemail.it

 portabile non solo su Win e *nix
Magari, io manderei a quel paese subito Borland se trovassi un'alternativa
con qualsiasi linguaggio. Mi puoi dare qualche link ad ambienti RAD che
siano comparabili a quello di Borland e che girino sia sotto Windows che 
Linux? (anche non free).
-- 
Vincenzo

 sotto Windows che Linux? (anche non free).
Allora: basta andare su google, cercare Tcl/Tk GUI editor, e scegliere 
uno dei milioni di ambienti RAD per la GUI, che il piu' delle volte sono 
scritti in Tcl/Tk stesso. E al 99% sono opensource


 preferiti. 
mi associo, insieme a smalltalk ed eiffel




Vincenzo, se vuoi usare un linguaggio RAD puoi usare Python.
Ovviamente niente a basso livello, ma puoi creare applicazioni anche molto
complesse con Python (ad esempio guardati sketch o GNUmed) e sicuramente
puoi usarlo insieme al C o C++ dove le performance sono un problema.
Per ambienti inteso come tool di sviluppo da un'occhiata a PythonCard e
Boa Constructor (entrambi sourceforge), anche se io, per essere sincero,
uso il semplice Scite :)
Ciao,
	Nicholas

 si, Tcl/tk esiste ovunkue, anke sul palm
Giusto, me lo sono dimenticato. Ma avanzo delle perplessita' sul TkInter.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Drink To Your Brothers Who Are Never To Fall, We Are Brothers Of Metal
  		Here In The Hall! !>- Manowar - Brothers Of Metal PT1

 come wxGlade, almeno per me.
Io mi rompo a disegnare la gui a mano.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**


 TkInter.
quali sarebbero?


 quali sarebbero?
Grosso. Privo di fighetterie grafiche.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! There are 10 kind of persons: who understands binary and who doesn't. !>-

 Privo di fighetterie grafiche.
man TixIntro
(e molti altri)


 (e molti altri)
Giusto. Ero rimasto un poco indietro.
Rilancio: il toolkit tk e' ad un livello di astrazione piu' basso di, per
es. wxWindows.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
	**ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! When you say "I wrote a program that crashed Windows", people just stare
     at you blankly and say "Hey, I got those with the system, *for free*" !>-
                                (By Linus Torvalds)

 per es. wxWindows.
e visto che lo stavamo usando per python, puoi benissimo crearti le tue 
(o usare una delle gia' pronte) interfacce al toolkit
non credo che sia poi tanto peggio di wxWindows, messe cois' le cose


 non credo che sia poi tanto peggio di wxWindows, messe cois' le cose
Ho esperienza di perl/TK e (scarsa) di wxPython. A parte le peculiarita' del
linguaggio wxWindows mi soddisfa assai di piu'.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 


 peculiarita' del linguaggio wxWindows mi soddisfa assai di piu'.
bah, de gustibus... comunque prova swig come detto sopra, un buon 
tutorial lo trovi su
http://www.swig.org/tutorial.html


 non lo so per esperienza diretta
Jython o come si chiama magari e' quello che dici tu. Anche a me il java da'
problemi di stomaco e me ne sto alla larga.
...  
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
           -<! GOD is real, unless declared as integer !>-

 altre cose SWIG e' un buon layer di astrazione.
Perchè ? Se la classe è disegnata bene *è* estendibile e facilmente
mantenibile. E' un approccio che si adotta soltanto quando le prestazioni
sono importanti, contando inoltre che ottimizzare prima del tempo è
male(c) si presuppone la presenza di un'applicazione funzionante e
semidefinitiva (definitiva tranne l'ottimizzazione delle preformance). Per
quel che mi riguarda solitamente ottimizzo quando ho già messo tutto in
produzione.
[...]
Ciao,
	Nicholas
p.s. Giuseppe dato che sei iscritto alla ml del mio lug non è che ci siamo
incontrati al LinuxDay ?

 anzichè Tkinter.
su questo, nulla quaestio. il problema e' che non le posso usare (ad 
esempio) su HP-UX, o su PDA (anche se so di alcuni tentativi di porting 
a riguardo) 
Personalmente, ignoro fino a che punto le diverse implementazini siano 
altrettanto reattive: magari su linux e windows vanno da dio, su MacOS 
boh?
Ah, tra l'altro, per crearle hanno usato SWIG :)


 termini temporali. Per altre cose SWIG e' un buon layer di astrazione.
be', considera che la GUI sarebbe comunque diretta dalla lib*.so 
sottostante, comandata da un oggetto compilato, i cui metodi sono 
chiamati da python. Penso che di meglio si possa fare solo con metodi 
nativi.
SWIG lo uso abbastanza, e va benissimo per classi semplici che facciano 
da semplici contenitori di metodi, il che e' quello di cui stavo 
parlando.
certo non ci implementerei un Model/View/Controller, che si fa meglio in 
Python direttamente


 Ah, tra l'altro, per crearle hanno usato SWIG :)
Io non ho nulla contro SWIG :p

 Io non ho nulla contro SWIG :p
lo dicevo per GC ;)


 incontrati al LinuxDay ?
No, perche' non c'ero :-) Per ragioni "storiche" sono piu' legato al LUG di
Brescia.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! I Never Wanted To Be What They Told Me To Be
  		Fulfill My Fate Then I'll Be Free >!- Blind Guardian - Mordred's Song

 Ah, tra l'altro, per crearle hanno usato SWIG :)
Rifare tutto con le API di Python sarebbe un suicidio direi.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! Gesu' e' morto per i nostri peccati.  Non rendiamo inutile il suo
		martirio non commettendone !>-

 lo dicevo per GC ;)
Neanch'io ho nulla contro SWIG, sia ben chiaro. E' che la prima volta che
l'ho provato mi aspettavo la pappa pronta e quando ho scoperto che comunque
ci devi mettere le mani piu' o meno pesantemente ci sono rimasto male :-)
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
  -<! Where's the warrior in you And the spirit he got? You say - "lost" No!
		It's somewhere inside !>- Lost Horizon - Sworn In The Metal Wind