Curiosità: qualcuno utilizza Eto per creare un minimo di interfaccia ai propri script in Python o C?
Eventuali opinioni?
Da utente non mi dispiace per cose semplici in alternativa alla riga di comando.
Ciao Giuseppe,
Non ho mai provato a usare Eto.
Avevo solo fatto una prova con Windows Forms (con Python). Prova molto semplice, ma scriptare il widget e’ comunque un lavoro in piu’ rispetto allo script ‘nudo e crudo’ 
.
… Anche se credo che con un po’ di pratica il tempo in piu’ richiesto sia ragionevole.
A me per certe cose sembra piu’ comodo da usare rispetto alle opzioni dei comandi.
Soprattutto quando serve provare a cambiare ripetutamente dei valori per vedere il risultato.
Forse sarebbe bello avere uno strumento tipo GH per costruire il widget … 
Ma a questo punto servirebbe poter costruire anche il resto dello script … o no ? …
Mah …
Ciao !
Mai usato, ma vorrei provarlo. Per cose non troppo complesse (quindi quasi sempre) è perfetto. Per scenari più complessi userei Blazor soprattutto se serve persistenza dei dati.
Concordo!
Esattamente come vorrei impostare alcuni script in Python.
Adoro GH ma mi rendo conto che se devi scrivere cose che useranno altri, o tu stesso, per una operazione, anche molto strutturata ma ripetitiva, lo script semplicemente non si batte.
2 Mi Piace
Sono cose diverse … e secondo me un po’ e’ un peccato 
, perche’ toglie la possibilita’ di fare cio’ di cui parli.
Penso dipenda sia dall’impostazione di Rhino, che mi sembra nato puntando sull’uso interattivo, senza particolare attenzione alla scriptabilita’/programmabilita’,
che dall’impostazione di GH, che utilizza operazioni, dati, grafica, interfaccia utente indipendenti da cio’ che si usa solitamente in Rhino.
(Ma questo non impedirebbe, forse su GH2 ?, di utilizzare GH, tramite apposito add-on, per generare script per Rhino indipendenti da GH, volendo comprensivi di interfaccia Eto.
Ma suppongo che scrivere l’add-on sarebbe un lavorone)
Tornando a Eto …
A giudicare dal semplice esempio mostrato qui Rhino - Writing Custom Eto forms in Python
sembra abbastanza lineare.
Forse TkInter lo e’ di piu’, anche perche’ meno prolisso come sintassi, ma ormai Eto sembra decisamente maturato. C’e’ anche la documentazione della API online.
Molto meglio di quanto ricordo riguardo ad alcuni anni fa, c’erano solo alcuni esempi di cui non capivo assolutamente inente … 
Una cosa che pero’ mi convinceva poco riguardo ai widget per gli script era il fatto del modale/non modale, cioe’ la possibilita’ o meno di interagire alternativamente con l’interfaccia grafica di Rhino e con il widget dello script, senza che nulla si bloccasse o sparisse.
Anche qui parlo di alcuni anni or sono, per cui forse nel frattempo le cose sono cambiate.
O forse ero solo io a non essere abbastanza sveglio per riuscire a fare queste cose.
Resta solo da provare come se la cava la AI a scrivere gli script …
Ma non so quanto sarebbe utile in questo caso.
Se il widget Eto e’ semplice, direi che lo schema dello script cambia poco e forse basta, volta per volta, copiare e adattare lo script precedente.
Forse sbaglio, ma a occhio mi sembra piu’ semplice cercare eventuali errori in un vecchio script modificato, che so come funziona, piuttosto che in uno script scritto dalla AI, che puo’ incasinarsi chissa’ dove …
Anche se io non faccio testo … sono di una lentezza inconcepibile … 
Verissimo. Devo infatti guidarlo bene e pretendere una certa struttura logica, altrimenti fa casino o se è corretto non sai dove mettere mani.
1 Mi Piace
Puoi fare un esempio di operazione strutturata?
Ottima domanda.
Prendiamo un esempio nel campo della gioielleria:
Devo iniziare un progetto di anello per il quale il punto di partenza è la misura.
Rhino mi permette di usare l’opzione di comando “Circumference” che crea una cerchio basato sulla lunghezza della circonferenza. Che è esattamente il valore a cui si riferisce la misura.
Serve uno script?….no. Serve GH….no.
Il passo successivo è assegnare la circonferenza ad un layer (bloccato) che abbia come nome: “Mis: (e la misura della circonferenza).
Ecco che già la macro diventa stretta. Voglio avviare GH, caricare la definizione e produrre il risultato? No. Faccio prima a mano. Un bel bottone con lo script in Python che fa tutto questo in due righe? Direi di si.
Anche perché il problema potrebbe essere quello di lavorare con misure USA, per le quali esiste una tabella delle equivalenze che NON è basata su alcuna formula matematica. Uno script utilizza una lista di valori misuraUsa cui si riferisce l’equivalente valore della lista circonferenze.
Voglio dire: non dobbiamo essere “generativi” ma semplificare una operazione puntuale.
Stesso ambito e stesso discorso se devi importare una pietra (diamante taglio brillante) per diametro o per peso e averla nella dimensione corretta per poi lavorarci sopra.
Secoli fa lo faceva Vittorio ( e ancora lo fa Lucio) con VB per generare componenti meccaniche.
1 Mi Piace
Ok grazie. Capisco. Prima non lo facevo, ma adesso con Rhino8 scrivo script anche io, ma in C#. Molto comodo effettivamente e questo consente di usare GH solo come precursore di script. Personalmente infatti mi capita di scrivere parte della definizione in GH e poi trasformarla in script senza passare da GH.
La cosa bella è che si possono referenziare anche librerie esterne (non so se con la versione 7 si poteva fare senza scrivere un plugin, ma mi pare di no).
L’aggiornamento a .Net Core mi sembra un gran passo avanti.
Alla fine sono tutti linguaggi…
Una delle cose che mi piacciono di più di Rhino 8 è lo ScriptEditor. E la possibilità di compilare gli script come .rhp e .rui.
Con Python c’è stato un po’ di bailamme nel passaggio da 2 a 3 ma niente di insormontabile. In particolare ci ho sbattuto il naso con Eto avendo usato in precedenza EditPythonScript e la vecchia abitudine di legare lo script a -_RunPythonScript “….” nei bottoni.
Ora creare comandi “nativi” è una passeggiata.
3 Mi Piace
Concordo anche io. Molto utile.
1 Mi Piace
Cavoli, detta così mi fa sentire ancora più vecchio di quello che sono… 
L’interfaccia script - utente è sempre stata una pecca in quanto i metodi per passare i dati (finestre di testo e caselle a selezione multipla) erano sempre molto scarni… cioè, si fa tutto ma se devi avere una finestra di richiesta dati dove vuoi organizzare più cose insieme (spunte “SI” “NO”, caselle a tendina, caselle per inserire valori in base ad altri dati già inseriti…) il tutto diventa più complesso del codice dello script stesso.
Se dici che Eto è diventato più “mestego” cioè che si lascia gestire, magari ci provo… sai mai che mi piaccia anche… dopo secoli…
2 Mi Piace
Io non vedo l’ora di usarlo, ma rispetto al editor c# di Rhino 7, quello di Rhino 8 è veramente orrendo, e trovo assurdo che sia passato tutto questo tempo e non abbiano ancora finito.
Veramente una situazione vergognosa.
Su Rhino 7 è divertente scrivere codice in c#. Su Rhino 8 è frustrante.
—
Detto questo, vorrei aver avuto la necessità di creare UI, con Eto magari, ma per i miei lavori negli ultimi anni il grosso delle interazioni con l’utente sono pochissimi input e bastano gli slider e bottoni di grasshopper… poi il codice si arrangia a fare tutto da solo…
ah ecco. Mi riferivo a Python unicamente. Ma anche la parte di compilazione dei componenti GH è così scarsa per C?
Io parlo dello scrivere codice c# direttamente in Rhino.
Sul 7 si poteva solo con un componente c# in grasshopper.
Su 8 si può anche con lo script editor.
Non parlo di VisualStudio e codice compilato. Ad oggi, io lo uso ancora pochissimo.
Veramente, io ho imparato c# e a districarmi con Rhinocommon esclusivamente provando e giocando con il componente c# su grasshopper in Rhino 7. (e credo che altri abbiano fatto simile)
Con 8 questo è impossibile. L’editor c# ti mette i bastoni tra le ruote in ogni istante, non c’è identazione automatica, apre tendine inutili e ti formatta il codice di testa sua spesso con risultati non richiesti.
In pratica sei te che assisti l’editor invece del contrario.
Se oggi un utente di Rhino 8 prova a imparare c# e/o Rhinocommon, rinuncia dopo 5 minuti. Veramente troppo frustrante!
I componenti c# su 8 sono molto lenti a essere creati la primva volta E ad aprirsi nelle volte successive!
La beffa? I componenti c# creati su rhino 7, se aperti in Rhino 8, hanno un pseudo-editor inutile per qualsiasi modifica.
Quindi è stata interrotta la retrocopatibilità (solo l’esecuzione rimane), e al contempo il nuovo editor è molto inferiore a quello precedente. Una situazione lose-lose.
La soluzione? Rimanere sul 7, come sto facendo io.
È da mesi che scrivo periodicamente sul forum ma a quanto pare ho sprecato tempo.
(Ho parlato con altri utenti tipo Laurent Delrieu, e anche lui mi ha confessato che non si trova con il nuovo editor, e quindi esperimenta su 7, e poi fa i plugin su VS anche per 8… ma un utente che ha solo 8 non può fare questa cosa…)
Rhino 7 con c# (e quindi lo sviluppo di plugin seri) era divertente, veloce, interessante, didattico.
Rhino 8 con il nuovo editor c# ha creato un “tappo”. Gli effetti li vedremo in futuro, ma già oggi io vedo sul forum gli utenti utilizzare c# molto meno che in passato.
Ucciso lo sviluppo e la crescita.
Perdonatemi per l’OT.
1 Mi Piace
Più che “altri” di pure il 90%…
Mi hai messo curiosità e voglio vedere come stanno le cose su youtrack per lo ScriptEditor.
Un utente che ha Rh8 può scaricarsi la chiave legacy Rh7 e usare Rh7 ma certamente non è una soluzione. Ci si aspetta che le cose migliorino….
Per niente OT
1 Mi Piace
A titolo informativo:
Ho scritto più volte a vari dev, sia in thread pubblici che in chat private, con più dev assieme o con un solo dev alla volta.
Un paio di settimane fa ho provato a riconttattare Ehsan ma non mi ha risposto, una settimana fa gli ho ri-scritto ma sempre silenzio.
Sicuramente lo sto stressando, e credo sia da solo a gestire la questione.
Avevo intenzione di riscrivergli dopo un paio di settimane dentro il 2026 …
Ormai mi conoscono e credo di averli sfiancati un po tutti. 
Visto tutto ora!
Sul fatto che i suggerimenti dei metodi siano troppo ingombranti è verissimo e preferisco anche io l’autocompilazione precedente.
Le cose che chiedi: questa e anche il problema indent sono attualmente “open”. Ci vorrà del tempo e alcune le vedo assegnate a 9.0 ma devono essere risolte. Si è Ehsan che se ne occupa.
1 Mi Piace
Ecco, io non conosco assolutamente le dinamiche interne di un’azienda come McNeel….
ma vi suggerisco fortemente di portare in Rhino 8 tutte le migliorie finali, insomma l’ “editor c# definitivo”.
Se non lo fate, chi ha 8 rimane tagliato fuori, ed è grave.
—
Della stessa importanza se non superiore: non rifatelo!
L’editor c# del 7 oggi su 8/9 è inutilizzabile! (esegue il codice, ma qualsiasi modifica è di fatto come scrivere sul blocco note, nessun ausilio se non peggio)
Verificate bene questa cosa ^.
L’editor c# su 8 praticamente pesa da solo 500MB o più sull’installazione di Rhino… rendetelo sempre apribile correttamente sulle versioni successive.
Quello che è successo per c# dal 7 al 8 è stato un danno incalcolabile.
Ai miei clienti ho detto di recuperare licenze 7 , usate o quello che c’era… se non potevano hanno preso l’8, ma li siamo costretti a lavorare male (tenendo gli script c# del 7, “legacy” su grasshopper nel 8).
Retrocompatibilità. L’avete interrotta e al contrario il “sostituto” è peggio del precedente.
Non rifatelo.
1 Mi Piace