Re: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet
« Risposta #30 il: Novembre 15, 2015, 13:07 »
solo per parlare
E proprio questo il problema con questo thread... sono ormai due paginate di post, e nemmeno una riga di codice. Con le parole, si possono descrivere un sacco di cose. E magari sono anche realizzabili. O magari no. E magari io penso di sì, tu pensi di no, l'altro pensa che forse. E possiamo andare avanti a parlare, parlare, parlare... Un labirinto di possibilità alternative, a ogni svolta un interesse nuovo, a ogni nuova variante qualcosa che si potrebbe o si dovrebbe fare in un modo o in un altro... Perché no?

Citazione
una sorta di meta linguaggio non so come dire
Non sai come dire, e soprattutto non sai come fare.
Ok, puoi immaginarti un domain-specific language (e puoi scriverti un parser e un compilatore per questo), per... già, per fare cosa, esattamente? Per rendere più facile scrivere degli adapter per delle chiamate alle primitive sottostanti, bla bla bla? Ok, ma questo non risolve il problema, lo sposta solo un po' più in là (o forse lo affronta con degli strumenti diversi). Ok, potrebbe essere più facile in questo modo, invece di scrivere gli stessi adapter direttamente in python. O potrebbe essere più difficile. Ne parliamo ancora per qualche decina di post? Evvai.

Citazione
Perché non usare HTML5 per le interfacce? In un colpo solo, mi vengono in mente questi vantaggi
GIà, perché no? Ma l'OP cercava qualcosa che avesse un look nativo cross-platform. E poi, python nel browser non ci entra. Ehi, mi viene un'idea. Perché non scriviamo un'implementazione di python in javascript, prima? E poi con quella... Parliamone un po'.



Non vorrei sembrare troppo sbrigativo, ma per chiudere il discorso, onestamente tutta questa insistenza sul semplice "disegno" della gui in modo cross-nativo, mi sembra molto esagerata.
Anche ammesso che sia possibile (e non si può) realizzare un coso che blitta punto-a-punto un pulsante "proprio-come-windows" su windows, "proprio-come-mac" sul mac, eccetera... non è che l'utente impazzirebbe per questo. Gli utenti non sono dei maniaci del rispetto formale delle gui, che analizzano l'aspetto di ogni componente con la style-guide del sistema operativo sotto mano. FInché non fai proprio delle stranezze assurde (e spesso si fanno), l'utente si accontenta di una gui simil-windows (per dire) anche all'80%. E in fin dei conti, gli va bene anche una gui completamente non-simil-windows. Ciò che importa davvero, è che la gui abbia una sua coerenza interna, prevedibile e facile da ricordare. E il rispetto di una serie di linee-guida generali, ovvio.
Ed è per questo che (guarda caso) sia l'approccio wx (simil-nativo all'80%, e accontentatevi) sia l'approccio qt (non-nativo, e fatevene una ragione) hanno avuto entrambi molto successo.

Quindi, se l'OP vuole costruirsi un nuovo gui framework, non credo proprio che sarà un game-changer _in_ _quanto_ disegna delle gui cross-native al 100% (ammesso e non concesso che ci riesca).
Il vero problema che l'OP deve affrontare, se vuole percorrere la strada "delle wx", è rendersi conto che la _funzionalità_ dei diversi componenti è diversa da sistema a sistema. E non parlo del semplice look (che comunque tanto semplice non è) ma proprio delle api, e non parlo delle cose esotiche ma proprio anche dei componenti di base, e non parlo di semplici cose in più/in meno ma proprio di differenze. Un ListCtrl GTK è una cosa diversa da un ListCtrl windows, c'è poco da fare.
Quindi, puoi scegliere di selezionare solo un ridotto sub-set di cose "davvero" uguali (ma così non è più cross-nativo al 100%, e comunque riduci la funzionalità) o puoi decidere di costruire un super-set che comprende tutte le funzionalità possibili (ma così in pratica costringi il programmatore a scrivere codice diverso per le diverse piattaforme, e allora tanto vale...).
Oppure puoi decidere di stare in qualche punto nel mezzo, e allora hai le wx. Puoi decidere che le wx non fanno un buon lavoro, e che tu riusciresti a stare in un punto un po' più vicino al limite... E allora vai avanti, e scrivi un framework migliore delle wx...
Oppure, all'opposto, puoi abbandonare l'idea della cross-natività, e allora hai le qt. Puoi decidere che le qt non fanno un buon lavoro, e allora vai avanti, e scrivi un framework migliore delle qt...

Ma devi renderti conto che questo è un vincolo ineliminabile, dovuto al fatto (in ultima analisi) che le gui native sulle varie piattaforme sono differenti, punto. E puoi avvicinarti quanto vuoi al concetto di "cross-natività al 100%", ma non esiste nessuna polverina magica (python, opengl, pyglet, cairo, canvas html5, un metalinguaggio, fai tu) che, spruzzata sopra tutto questo, ti restituirà un "traduttore universale" di api native.
Spero che sia un po' più chiaro.