Topic: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet  (Letto 4406 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline yoplett

  • python unicellularis
  • *
  • Post: 13
  • Punti reputazione: 0
    • Mostra profilo
Buonasera a tutti, sono nuovo del forum, vorrei porre una domanda agli esperti, credete sia possibile creare un nuovo Framework GUI in alternativa a pyQT  e pyWX utilizzando pyglet, OpenGL, Cairo e ovviamente python? Ho alcune idee e ho già abbozzato alcune cose che pare funzionino, ovviamente non so se l'approccio è corretto o dei migliori, comunque sembrerebbe fattibile, vorrei un parere da esperti. L'idea e riuscire a creare una GUI graficamente completamente indipendente rispetto alla piattaforma su cui gira, per intenderci, all'occorrenza riuscire ad emulare più o meno fedelmente ad esempio una interfaccia mac sin win e viceversa o addirittura qualcosa di completamente nuovo.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
possibile, tutto è possibile... se non hai niente di particolare da fare per i prossimi dieci anni...

Offline yoplett

  • python unicellularis
  • *
  • Post: 13
  • Punti reputazione: 0
    • Mostra profilo
Grazie per la risposta, dai non credo ci voglia così tanto, ho già provato a mettere giù qualche cosa con ottimi risultati, lavorandoci solo qualche ora alla sera con credo ottimi risultati, almeno credo, non dico di aver fatto già tutto ma sicuramente molto più di quanto potessi sperare fino ad ora, sto perdendo molto tempo, causa anche i vari impegni lavorativi sulla parte che gestisce la politica di gestione dimensioni finestre, sovrapposizione, trasparenze ecc. Ovvio che questa è una delle parti sicuramente più corpose ma ho buone speranze... In verità avevo già messo a punto una sorta di window manager perfettamente funzionante, ma era a mio avviso poco flessibile, poco efficiente, non teneva conto delle possibili animazioni di transizione e quindi lo sto rivedendo da capo. La mia domanda è se secondo voi ha un senso un progetto del genere, e magari se qualcuno è interessato, condividere i problemi incontrati, approccio utilizzato ed soluzioni o migliorie da apportare. Se foste interessati disponibile a condividere il codice già scritto. Avrei delle domande in merito anche al discorso gestione eventi, io ho utilizzato un approccio simil WXwidget, event/callback, con identico schema propagazione degli eventi tra i parent distinguendo tra command e noncommand event, secondo voi sarebbe stato meglio utilizzare un approccio QT? E se si, mi sfugge la sostanziale differenza e vantaggi nell'utilizzo signal/slot, a me sembra si riesca ad ottenere agevolmente lo stesso risultato per l'utente finale utilizzando il sistema Calback, voi che ne pensate? 

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
Citazione
dai non credo ci voglia così tanto,

Guarda non so che dire, e non mi permetterei mai di dubitare.
In questo momento, la repository di wxPython "classic" è composta da 3052 file, e la repository di PySide è composta da 1478 file. Ovviamente, dietro a entrambi i progetti ci sono anni di lavoro e molte, ma molte persone con competenze davvero approfondite (alcuni, sono proprio dei geni, diciamolo).
Se per te fare una cosa del genere, da solo e da zero, "non ci vuole così tanto", prima di tutto sinceri complimenti, secondo mi spaventi anche un po', e terzo manda un curriculum a google e vivi felice il resto della tua vita da miliardario.


Citazione
L'idea e riuscire a creare una GUI graficamente completamente indipendente rispetto alla piattaforma su cui gira, per intenderci, all'occorrenza riuscire ad emulare più o meno fedelmente ad esempio una interfaccia mac su win e viceversa o addirittura qualcosa di completamente nuovo.
Allora, "emulare un'interfaccia mac su win e viceversa", credo che non sia mai stato fatto nella storia (senza virtualbox di qualche tipo, voglio dire...). Addirittura il fatto che lo stesso toolkit che fa questo possa anche fare "qualcosa di completamente nuovo" se attivo uno switch... beh, ok, adesso sto letteralmente sbavando nell'attesa.
In genere l'approccio è quello di farsi "tutto in casa", a la PySide (o tk, per dire)... mirando ad avere un look and feel diverso da quello del toolkit grafico del sistema operativo, ma coerente tra i vari porting. WxPython fa eccezione, in quando l'approccio è di astrarre un'API comune che sotto delega alle primitive grafiche del sistema operativo su cui si trova... In modo da avere dovunque l'aspetto di una "normale" gui del sistema operativo.


Citazione
Avrei delle domande in merito anche al discorso gestione eventi, io ho utilizzato un approccio simil WXwidget, event/callback, con identico schema propagazione degli eventi tra i parent distinguendo tra command e noncommand event, secondo voi sarebbe stato meglio utilizzare un approccio QT? E se si, mi sfugge la sostanziale differenza e vantaggi nell'utilizzo signal/slot, a me sembra si riesca ad ottenere agevolmente lo stesso risultato per l'utente finale utilizzando il sistema Calback, voi che ne pensate?

Mah... la verità è che neanche wx usa più un sistema propriamente "a callback"... e tra l'altro, storicamente, il sistema di binding delle moderne wx è stato proprio ideato da Robin Dunn per wxPython. Ora, il modello signal/slot permette ovviamente un broadcasting molti-a-molti, che i callback tradizionali non permettono... e in effetti wxPython mette a disposizione almeno altri due meccanismi "alternativi" al binding tradizionale per venire incontro a questo scenario (pyevents e, banalmente, wx.lib.pubsub).
Non ho la necessaria competenza c++ per apprezzare in pieno la differenza. Specialmente da un punto di vista più astratto (python), in effetti le due tecniche sembrano convergere parecchio.


Citazione
La mia domanda è se secondo voi ha un senso un progetto del genere
In breve, non molto. Per tutta una serie di motivi, le tradizionali gui desktop stanno sparendo. Le gui si fanno nel web (e in javascript). E anche le gui per mobile, soprattuto python ha perso il treno già dalla partenza, con buona pace di Kivy... Comunque il tuo prodotto potrebbe essere un game changer.


Citazione
magari se qualcuno è interessato, condividere i problemi incontrati, approccio utilizzato ed soluzioni o migliorie da apportare. Se foste interessati disponibile a condividere il codice già scritto.
se non è su github, non è.

Offline yoplett

  • python unicellularis
  • *
  • Post: 13
  • Punti reputazione: 0
    • Mostra profilo
Si forse ho esagerato, no assolutamente non sono un genio, assolutamente... sono solo un appassionato e probabilmente anche mediocre, lo so che i team di professionisti che sviluppano o hanno sviluppato le relative wx o qt sono dei veri geni e tanto di cappello, so anche che dietro ci sono migliaia e miglia di righe di codice, probabilmente hai ragione tu, voler creare da solo un framework completo in tutte le sue parti, richiederebbe 10 anni della mia vita. Diciamo che l'idea era quella di sviluppare il core del sistema poi con l'aiuto e la collaborazione di eventuali appassionati procedere con lo sviluppo di tutte le parti accessorie, rifacendomi alle wx ad esempio, una semplice classe panel contiene centinai di metodi da implementare spesso non comuni ad altri widget, hai ragione il lavoro aumenterebbe in maniera esponenziale senza contare tutto il resto quali ottimizzazioni ecc.
Per quanto riguarda l'emulazione, le mie intenzioni sarebbero quelle di avere una emulazione puramente grafica, nulla a che vedere con Virtualbox.
Forse hai ragione anche quando dici che le gui si fanno nel web, ma credo anche che le gui desktop, del tutto non scompariranno mai, addirittura pare che contrariamente a quanto in passato si è pronosticato, oggi si registra una contro tendenza, è ovvio che il futuro o meglio il presente e il web ma rimarranno sempre una miriade di applicazione che per forza dovranno girare desktop.
Forse anche qui mi sbaglio, ma kiwy (progetto bellissimo) non mi sembra propriamente un sistema per creare gui web quanto un sistema per potare python si android quindi smartphone con l'aggiunta della parte che manca ad altri framework python, cioè l'aspetto touch con MT e rendendo la grafica più appropriata all'utilizzo con dispositivi mobile, del resto anche Nokia oggi Microsoft ai tempi ha acquisito QT con l'intento di implementare la parte grafica dei propri dispositivi.
 
In verità gongolando ho scoperto che la mia idea, in linea di principio, non e poi così nuova, pare che anche Clutter per linux utilizzi un approccio analogo a quello da me ipotizzato per renderizzare la perte grafica, non molto diverso poi da mac con quartz extreme che al posto di cairo utilizza il suo sistema svg proprietario per la creazione della grafica 2D che poi compone con openGL fruttando l'accelerazione hardware. Il problema è che questi sistemi impongono un aspetto grafico predefinito nel caso di mac e programmabile nel caso di clutter ma non in senso assoluto dando piena libertà, non potrò mai ottenere un layout simil windows 10 con clutter.

Ti chiedo scusa nel caso avessi scritto qualcosa di non preciso o corretto e ti prego di correggermi, ad ogni modo mi piacerebbe portare avanti la cosa, anche solo per vedere fin dove si riesce ad arrivare, se qualcuno fosse interessato ad approfondire, pronto a mettere a disposizione idee e codice fin qui creato.
 

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
l'idea era quella di sviluppare il core del sistema poi con l'aiuto e la collaborazione di eventuali appassionati procedere
eh sì ma allora il core del sistema deve essere sviluppato in modo (addirittura) brillante... altrimenti chi glielo fa fare, ai tuoi eventuali appassionati, di unirsi? Perché uno dovrebbe investire tempo per migliorare un progetto sconosciuto, in un campo dove, peraltro, ci sono prodotti molto validi e molto robusti e affermati? Per attirare gente, il tuo codice deve essere proprio tanto bello, e/o contenere qualche aspetto fortemente innovativo... oltre naturalmente alle "solite" raccomandazioni... codice leggibile, architettura chiara, documentazione a manetta, copertura di test, ovviamente nemmeno un commento di due parole in italiano... e poi ancora, il codice deve essere raggiungibile in una repository pubblica, devi pensare a pacchettizzarlo e fare almeno una alfa da installare, devi mantenere un bug tracker... Se hai coperto questo... ancora non basta. Cercare collaboratori per un progetto vuol dire, in qualche modo, essere conosciuto e affidabile. Il che vuol dire intervenire sui forum, contribuire a progetti di altri, etc. etc. Altrimenti perché qualcuno dovrebbe imbarcarsi in un progetto di queste dimensioni, avviato da te?

Citazione
Per quanto riguarda l'emulazione, le mie intenzioni sarebbero quelle di avere una emulazione puramente grafica, nulla a che vedere con Virtualbox.
ovviamente. E ti ho detto appunto che una cosa come l'hai descritta è... inedita, diciamo. saprai tu.

Citazione
credo anche che le gui desktop, del tutto non scompariranno mai, addirittura pare che contrariamente a quanto in passato si è pronosticato, oggi si registra una contro tendenza, è ovvio che il futuro o meglio il presente e il web ma rimarranno sempre una miriade di applicazione che per forza dovranno girare desktop.
ok, buttati allora. potresti cominciare a dare una mano a kivy, per fare un po' di pratica e farti conoscere, intanto che sviluppi il tuo progetto.

Citazione
In verità gongolando ho scoperto che la mia idea, in linea di principio, non e poi così nuova,
nel campo dei toolkit grafici, non credo che sia così facile formulare un'idea nuova, in linea di principio. non è questo il problema

Citazione
ad ogni modo mi piacerebbe portare avanti la cosa, anche solo per vedere fin dove si riesce ad arrivare, se qualcuno fosse interessato ad approfondire, pronto a mettere a disposizione idee e codice fin qui creato.
ripeto, se non è su github, non è.





Offline shinken

  • python erectus
  • ***
  • Post: 206
  • Punti reputazione: 0
    • Mostra profilo
....
ripeto, se non è su github, non è.

In effetti se uno cerca qualche cosa la trova
Ed ecco a voi pyglet-gui 
https://github.com/jorgecarleitao/pyglet-gui.git
Forse non è proprio quello richiesto, ma potrebbe dare un idea.

Citazione da: yoplett
citando yoplett
>credete sia possibile creare un nuovo Framework GUI in alternativa a pyQT

Si è possibile e alla fine anche abbastanza semplice.
Punto primo se vuoi sviluppare un progetto serio e valido devi trovare un finanziatore molto generoso, che paghi...
Se superi il  punto precedente, ogni altro problema diviene banale, salvo poi reiterare il punto primo.


Offline yoplett

  • python unicellularis
  • *
  • Post: 13
  • Punti reputazione: 0
    • Mostra profilo
pyglet-gui lo conosco, non per voler dire ma in questo caso ci troviamo davanti ad un progetto limitato, non a livelli di wx o altro e che di fatto impone sempre una propria grafica modificabile solo in parte, ci sono anche altri progetti in corso ce si appoggiano a pyglet, mi risulta, ma tutti con lo stesso genere di limitazione.
Ad ogni modo avete ragione voi, sono un entusiasta che non fa i conti con la realtà per la scarsa comprensione di quelle che sono le dinamiche dello sviluppo software nel mondo reale.
Cercherò di seguire i vostri consigli, studierò progetti altrui vedendo si c'è la possibilità di contribuire in qualche maniera e magari, un domani, chi sa riaprire il discorso in maniera completamente diversa e più professionale, intanto continuerò a portare avanti il mio giochino da solo per semplice curiosità e voglia di comprendere meglio come funzionano le cose. Grazie a tutti, qualsiasi ulteriore consiglio o suggerimento è ben accetto e prezioso, non si finisce mai di imparare.
   

Offline Giornale di Sistema

  • python sapiens sapiens
  • ******
  • Post: 3.124
  • Punti reputazione: 4
    • Mostra profilo
    • Distillato di Python
intanto continuerò a portare avanti il mio giochino da solo per semplice curiosità e voglia di comprendere meglio come funzionano le cose.

Nulla ti impedisce di pubblicarlo su github o simili già da adesso... avrai più tempo per trovare eventuali collaborazioni sin dalle prime fasi.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
mah sì infatti... devi capire che sono due cose molto diverse. Un conto è mettersi a fare il project leader di un progetto molto articolato, ambizioso, complesso... questo richiede un approccio professionale, un'esperienza e un livello di competenza *notevole*.

Un altro conto è acquisire esperienza e pratica, e farsi notare, collaborando per esempio a progetti già avviati. Prendi kivy, per esempio... niente di difficile...
1) ti fai un account su github
2) impari a usare git - bene
3) ti fai un fork della repo di kivy
4) ti scegli un issue aperto, e ci lavori fino a produrre una patch
5) fai una pull request per la tua patch
6) e complimenti, hai appena contribuito a kivy

Ovviamente, in tutto questo, vedrai da solo che ti tocca a imparare un sacco di cose "collaterali" ma fondamentali: dovrai leggerti con cura tutte le loro indicazioni e style-guide http://kivy.org/docs/contribute.html. Dovrai imparare a scrivere codice in modo chiaro, e testare testare testare. Dovrai imparare a confrontarti con gli altri, vedere il tuo codice recensito e respinto... Etc. etc. Ovviamente, se inizi da issue facili, sarà più facile...

Ma tutto quello che impari lavorando per questi progetti ti servirà anche per il tuo progetto personale...

Offline yoplett

  • python unicellularis
  • *
  • Post: 13
  • Punti reputazione: 0
    • Mostra profilo
Re: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet
« Risposta #10 il: Novembre 12, 2015, 11:45 »
Grazie a tutti per i preziosi consigli, una curiosità, potrebbe sembrare una affermazione ma in realtà è una riflessione alla quale non ho una risposta: chi sviluppa applicazioni mobile o non oggi, utilizza spesso un approccio web per risparmiare tempo e denaro per avere una piattaforma coerente anche a livello stilistico e non solo su tutti i dispositivi, l'alternativa sarebbe sviluppare per ogni piattaforma con gli opportuni strumenti, Xcode o swift per MAC/IOS, android SDK ecc, sarebbe auspicabile, escludendo windows mobile in una prima fase, avere una sistema indipendente che mi permetta di avere coerenza grafica su tutti i dispositivi mobile e desktop, credo sarebbe magnifico e il sogno di ogni sviluppatore. Oggi tutti i dispositivi supportano, anzi nel caso di android addirittura utilizzano come motore di rendering openGL ES,il sistema sarebbe utilizzabile anche nei sistemi embedded, ad esempio anche la piattaforma raspberry supporta pienamente openGL/ES, CAIRO e tanto altro. Ritorno a farla troppo facile, non capisco come mai nessuno, intendo team di sviluppo, non persone come me, si sia mai addentrato in un discorso di questo genere, non credo si facile ma sicuramente potrebbe essere veramente una sorta di sacro graal, con l'ovvio mal contento delle varie apple e google. Kivy, in parte, cerca di fare questo ma in realtà, di fatto adotta solamente uno stile grafico proprio e comunque impone al contrario un approccio mobile a ciò che gira in desktop.   

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet
« Risposta #11 il: Novembre 12, 2015, 12:40 »
Il thread e' interessante. Provo a buttare giu' due opinioni.
Quello che RicPol dice e' *molto* sensato, anche se sembra buttarti giu'. Sinceramente io faccio fatica a darti consigli: da un lato, da alcuni commenti che fai, dal modo in cui riesci a trovare informazione per guidare le tue decisione, sembra che hai esperienza ed un'idea molto precisa di quello che va fatto e di come farlo; da altri commenti sembra che invece hai una visione relativamente naive di tante cose.

Per esempio, da un lato asserisci di avere gia' scritto un window manager (che e' qualcosa che e' tutto fuorche' semplice), dall'altro sembra che tutta la parte di "come si fa open source" sia relativamente nuova per te. Non so il commento "inizio da solo" poi vedro' e' stranissimo. Prima cosa che faccio per qualunque progetto e' fare un repository git. Semplicemente non e' possibile lavorare decentemente (anche in completa solitudine) senza un sistema di version control. E ovviamente e' super naturale che il repo git sia direttamente su github. Come dice RicPol, prima la gente vede il progetto, prima e' facile che inizi a collaborare. E poi li si apre un mondo su come impostare un progetto.

Anche pensare "scrivo il core" poi il resto verra'... scrivere un API sufficientemente generale da consentire facilmente a chi deve estendere di farlo non e' facile. Specie se vuoi essere decentemente efficiente (e in Python non e' banale). Deve essere gradevole lavorarci se vuoi gente che ti dia una mano. Deve essere promettente e utile.

Non so, probabilmente la verita' sta in qualche punto nel mezzo. Secondo me devi onestamente capire quali sono le risorse che puoi mettere nel progetto, capire se puoi affrontarlo da solo (la gente arrivera' solo quando il progetto e' interessante "praticamente" per qualcuno). Non so... solo tu conosci le risposte. Pensaci. E tipicamente non vuoi investire tre anni del tuo tempo libero in un progetto che poi scopri che non ha nessun utente e finisce per morire per disinteresse.

Detto questo, sul problema generale.
1. Io non credo che ci sia interesse "pratico" eccessivo per un'altro GUI toolkit. I vari Qt, wx, etc *nella pratica* funzionano decentemente. Per "rubare" base di utenza bisogna offrire qualcosa di veramente interessante: e' un mercato vecchio, in contrazione con alcuni player che dominano in modo assoluto. Pensa anche quale sia la base di utenza di vari toolkit alternativi. Per esempio questo e' un coso mediamente interessante: http://www.fltk.org/index.php. Tipo su ubuntu il numero di progetti che usano gtk e' almeno un intero ordine di grandezza maggiore di fltk, possibilmente parliamo anche di 20, 30 o 50 volte di piu'. Affermarsi in questo mercato e' complicato.

2. L'idea dell'interfaccia che si presenta come nativa e' una chimera. Hanno fallito *tutti*. Ci sono vari problemi... in primo luogo, le UI native cambiano leggermente anche fra diverse versioni "native" dei toolkit degli OS *e* spesso  supportano dei "temi" o delle "skin". In pratica per farcela anche solo dal punto di vista della pura grafica (cioe', parliamo solo di che faccia ha un bottone) devi essere in grado di "capire" la configurazione dell'os e fare la cosa giusta. Fare la cosa giusta puo' volere dire da un lato essere in grado di capire i "temi" di tutte le piattaforme la fuori, interpretarne la configurazione ed emularla. Dall'altro probabilmente avere implementato tutti quanti i numerosi controlli che puoi avere. E anche qui... problemi: ci sono cose incompatibili. Per esempio sotto GTK e' assolutamente normale associare un'icona ad ogni voce di menu'. La cosa non e' fatta spessissimo sotto Windows, e non viene fatta *mai* sotto OS X (almeno, da nessuna applicazione nativa). Che fare? Se su OS X fai vedere le icone (per esempio quello che fa GTK sotto OS X) hai bai default qualcosa che non e' conforme allo standard grafico della piattaforma. Se non lo fai, potenzialmente chi ha disegnato l'applicazione potrebbe avere deciso che suddette icone sono parte integrante della user experience e che l'usabilita' in loro assenza e' ridotta. E questo e' solo il "look". Poi c'e' il feel. Sotto i vari OS le UI si comportano in modo leggermente diverso. Spesso i bottoni hanno posizioni diverse. Per esempio su OS X l'OK e' a destra. Se ricordo correttamente su Windows invece e' a sinistra. Similarmente per altre cose che sono considerate il "default" della maschera. Vuoi supportare questa cosa? Si, no? boh... come fai a fornire un API tale per cui la tua libreria fa la cosa giusta? Alcune librerie la fuori lo fanno... ma e' un problema. Ci sono pacchi di problemi di questo tipo. E i menu come li gestisci? Non puoi semplicemente "disegnarli", perche' su OS X i menu sono *fuori* dalla tua finestra. Su Linux dipende... per esempio la UI standard di Ubuntu li mette pure in alto, fuori dalla finestra, ma dipende da come hai configurato certe cose... potresti averli invece dentro la finestra. E a seconda di quello che ha settato l'utente devi capire e fare la cosa giusta.

3. Gestione del testo... certe lingue lavorano in da sinistra a destra, altre viceversa... i tuoi controlli devono fare la cosa giusta in entrambi i casi.

4. Accessibilita': e' un problema non banale da supportare. Eppure non puoi ignorarlo (altrimenti vai a ridurre l'applicabilita' della tua libreria, ovvero chi sviluppa "per lavoro" potenzialmente potrebbe non usarla. Nota: qui molti toolkit sono deboli. Alla fine spesso vengono scelti determinati toolkit solo per il fatto che hanno qualche supporto all'accessibilita'.

5. Device mobili? Li supporti? No? Applicabilita' limitatissima. Li supporti? Stai pestando i piedi a kivvy, che e' arrivato prima e comincia ad avere una user base. E comunque molta gente preferisce non usarlo perche' non e' abbastanza "nativo" e non e' ben integrato con l'OS (non solo per questioni di UI, ma anche perche' molte API degli OS dei device non sono ben mappate in Python).


Anche quello che dici sul fatto che il mercato delle UI sia in espansione... non sono d'accordo. Vorrei vedere i dati. Praticamente tutti i "nuovi" prodotti sono in qualche modo web. L'altro mercato in espansione e' quello mobile (che se vuoi sono "ui desktop"), ma anche li, molte applicazioni che usi in effetti sono poco piu' di una cornice attorno a quello che a tutti gli effetti e' un mini-browser "standard". Vorrei veramente vedere i dati sull'argomento. Poi certo.. c'e' sempre gente che fa shareware per le varie piattaforme et similia... ma quali aziende fanno questo? I nomi tradizionali (che so, Adobe), shareware developers vari -- che spesso sono piu' interessati a dare la miglior user experience possibile e vogliono usare API native per questo motivo: quasi tutto la shareware di qualita' che uso (sotto OS X) e' nativo. Quasi tutte le applicazioni commerciali che uso sono native. Essenzialmente ci sono i browser che tendono ad essere xplatform (ma non so internamente se per caso non usano le librerie dell'OS e semplicemente reimplementano: sono progetti grossi che potrebbero permetterselo). Tipo Chrome nonostante tutto ha un sacco di roba Cocoa e guardando le librerie linkate sembra proprio Cocoa -- sotto OS X --. Poi uso IntelliJ di tanto in tanto... che e' un mondo a parte.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet
« Risposta #12 il: Novembre 12, 2015, 12:42 »
Riassumo... alla fine dei conti, arrivare all'80% di quello che vorresti che il progetto facesse e' fattibile. Solo che... ci sono altri progetti che arrivano all'80%. E non basta per conquistare il mercato. Perche' non fanno il 99%? Perche' e' un marasma di piccoli dettagli che vanno gestiti e potrebbe essere che semplicemente qualche aspetto non e' gestibile.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
Re: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet
« Risposta #13 il: Novembre 12, 2015, 13:49 »
sì, grazie riko, non ho avuto tempo di immergermi nello specifico del problema, anche perché pensavo che fosse più urgente il meta-problema di come impostare un progetto... ma più o meno avrei detto le stesse cose.
Citazione
Sinceramente io faccio fatica a darti consigli: da un lato, da alcuni commenti che fai, dal modo in cui riesci a trovare informazione per guidare le tue decisione, sembra che hai esperienza ed un'idea molto precisa di quello che va fatto e di come farlo; da altri commenti sembra che invece hai una visione relativamente naive di tante cose.
La stessa impressione che ho avuto anch'io. Come minimo, l'OP sa usare google e si informa sulle cose che sta cercando di fare... Parlando chiaro: se è un niubbo, è un niubbo cento volte più avanti di certi niubbi che sporadicamente appaiono per chiedere come fare call of duty in python in una sera. Tanto di cappello.

Citazione
L'idea dell'interfaccia che si presenta come nativa e' una chimera. Hanno fallito *tutti*.
Esatto. Questa idea, in genere si trasforma ben presto in "interfaccia che si presenta _abbastanza_ nativa per un subset di elementi quanto più ampio possibile ma senza pretendere la luna". Ed è quello che fanno le wx. A prezzo di una complessificazione terrificante, e di api incasinatissime.
Per esempio, le wx supportano tutte le cose che riko ha elencato nel suo punto 2, ma per scrivere codice veramente portabile non puoi usare niente di specifico, e devi sapere quali cose ti daranno problemi su quale sistema operativo... risultato, dal punto di vista dello sviluppatore è molto più difficile scrivere codice portabile con le wx che con le qt o un altro toolkit che usa un'interfaccia sua propria.

Citazione
3. Gestione del testo... certe lingue lavorano in da sinistra a destra, altre viceversa... i tuoi controlli devono fare la cosa giusta in entrambi i casi.
Non parliamone neppure. Qui se pyglet non ti offre qualcosa di già pronto, e/o non riesci a incorporare qualche altra libreria, sei panato. Se devi fare tutto da zero, sei morto... e ben prima di arrivare al LTR/RTL.

Offline yoplett

  • python unicellularis
  • *
  • Post: 13
  • Punti reputazione: 0
    • Mostra profilo
Re: Creazione nuovo framework per gui usando python, openGL, Cairo e pyglet
« Risposta #14 il: Novembre 12, 2015, 14:46 »
Non sono qua per chiedere come fare le cose, o come farle in un giorno o in un mese, il mio mezzo preferito di informazione rimangono i libri vecchio stampo... è la prima volta che mi iscrivo ad un forum dopo anni di titubanze per paura di essere considerato un ignorante opportunista, la mia intenzione era solo quella di scambiare qualche parere costruttivo, che per altro mi avete dato e vi ringrazio.