Python. Sto creando una gui.

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
In questi giorni in cui è altamente consigliabile non uscire di casa se non per necessità ho cercato un passatempo stimolante. Dopo aver creato qualche programmino in python per uso personale (usando sia le gtk3 che tkinter che le qt5) mi è venuto in mente di esplorare il funzionamento di una gui. Io non sono un programmatore, è solo un hobby, e so che il sito è frequentato da programmatori di professione. Però a qualcuno dovevo dirlo :) .
Se poi il post non è pertinente alla sezione potete anche cancellarlo.

All'inizio è stato un po' difficile partire col progetto dato che, sebbene conosca le basi basi della programmazione, non so tutto il resto. Poi ho deciso di usare OpenGL per la parte grafica. Perchè OpenGL: ho visto un po' in giro ed è l'unica libreria che non ne richiede altre (sebbene poi abbia usato PIL per le immagini, e poi userò freetype le i font).
Questo è il codice che crea la finestra (allego l'immagine):
Python:
from widgets.application import App


####### CODE

class main():
    def __init__(self, app):
        self.app = app
    
        #### the label widget
        label1 = {"widget":"olabel", "x":0, "y":0, "text":"1cjao", "fontsize":30, "BR":1, "BG":1, "BB":1}
        ## the label is added to the program
        self.app.addWidget(label1)
    
        #### button
        button1 = {"widget":"obutton", "x":100, "y":350, "w":250, "h":60, "text":"2cjao", "fontsize":30, "image":"folder.png", "imagepad":3}
        self.app.addWidget(button1)
    
        #### button
        button2 = {"widget":"obutton", "x":100, "y":300, "w":250, "h":50, "text":"3cjao", "fontsize":30}
        self.app.addWidget(button2)
        # etablish a connection
        id = self.app.connect(button2, lambda:self.fbutton("hi", 5))
        # remove a connection
        #self.app.disconnect(button2, id)
    
        #### image
        image1 = {"widget":"oimage", "x":0, "y":550, "w":50, "state":0, "image":"folder.png"}
        self.app.addWidget(image1)

    #
    def fbutton(self, t, x):
        print("**fbutton**", t, x)

####
app = App(width=600,height=600,title="Prova")
main(app)

app.run()

#######################
screenshot2.png

Ho creato solo tre widget per il momento:
- label
- immagine
- pulsante.
Ognuno di questi ha delle opzioni, come scelta dei colori, e la possibilità di essere collegati a eventi (per ora solo usando il pulsante sinistro del mouse). Esiste anche un altro widget chiamato application, ma è più che altro un contenitore che gestisce sia i widget che il loro posizionamento. Infatti ho pensato di gestire il posizionamento dei widget non tramite i soliti contenitori, chiamati generalmente box, ma tramite proprietà dei widget.

Il codice una volta eseguito fa apparire la finestra visibile nello screenshot. In sottofondo qualche messaggio generato quando ho premuto (e tenuto premuto) il pulsante superiore.
In alto abbiamo un label con background bianco. Sto usando il font che OpenGL possiede.
In basso viene visualizzata una immagine in formato rgba.
Poi al centro abbiamo due pulsanti, uno senza icona. Il widget pulsante utilizza gli stessi widget label e immagine, è in definitiva composito.
Il pulsante premuto ora di colore viola è collegato a una funzione che stampa la stringa ' **fbutton** hi 5 ' come si vede nel terminale. Commentata è invece la procedura per disconnettere il widget dall'evento.
Nel programma principale i widget vengono definiti con delle proprietà ma solo nel modulo application vengono creati e gestiti.
Per il momento i widget sono in posizione fissa, e lì rimangono quando ridimensiono la finestra.
Per concludere, molte proprietà dei widget hanno dei valori predefiniti ed è per questo che non vengono inizializzate.

Aggiornamento:
Termino il mio esperimento con python+opengl mentre stavo codificando i box (che non erano nel mio programma una entità differente in quando ogni widget possedeva una opzione su come comportarsi quando la finestra del programma cambiava di dimensione). Il motivo è che in certi punti del programma se indento ulteriormente con spazi o tab il programma non se ne accorge ma noto degli errori visivi. Pazienza, comunque ho ottenuto ciò che volevo anche se parzialmente. Non ho usato thread.
 
Ultima modifica:

pabloski

Utente Èlite
2,707
782
(usando sia le gtk3 che tkinter che le qt5) mi è venuto in mente di esplorare il funzionamento di una gui

Da come lo dici, sembra che gtk3, qt5 e tkinter non siano GUI frameworks :D

Perchè OpenGL: ho visto un po' in giro ed è l'unica libreria che non ne richiede altre (sebbene poi abbia usato PIL per le immagini, e poi userò freetype le i font).

E' vero. Però OpenGL non ti dà niente di tutto quello che i normali GUI frameworks ti danno. Diamine, per gestire gli eventi di mouse/tastiera/joystick, bisogna usare il polling. Il minimo sindacale è SDL ( in genere ).

Comunque mi sfugge la libreria che stai usando. Non è OpenGL liscio. Ma allora cos'è?
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Da come lo dici, sembra che gtk3, qt5 e tkinter non siano GUI frameworks :D

E' vero. Però OpenGL non ti dà niente di tutto quello che i normali GUI frameworks ti danno. Diamine, per gestire gli eventi di mouse/tastiera/joystick, bisogna usare il polling. Il minimo sindacale è SDL ( in genere ).

Comunque mi sfugge la libreria che stai usando. Non è OpenGL liscio. Ma allora cos'è?
Il mio intento, non troppo serio, è appunto creare un framework. E sto usando solo OpenGL. Non trovi le relative chiamate e i codici di inizializzazione nello script che ho allegato in quanto sono tutte nel modulo application. Di fatto nello script principale ci sarà solo la riga
from widgets.application import App .
Per importare le immagini sto usando PIL, e cercerò di usare freetype per gestire i caratteri truetype.

Queste sono le prime righe del modulo application:

Python:
"""
This module must be called first and manages all the other widgets
"""

from OpenGL.GL import *
from OpenGL.GLUT import *
from OpenGL.GLU import *

from widgets.label import olabel
from widgets.image import oimage
from widgets.button import obutton


# x - y - width - height 
# - background colour (default gray 85): RGB
class App():
    def __init__(self, x=0, y=0, width=10, height=10, BR=0.85, BG=0.85, BB=0.85, title=""):
        self.x = x # left
        self.y = y # bottom
 

BrutPitt

Utente Attivo
443
408
Dal codice vedo che stai usando GLUT e GLU, che appartengono ormai alla "storia" delle OpenGL: non sono piu' aggiornate e supportate da anni e fanno riferimento al "vecchio corso" OpenGL pre-2.0.
E' vero, GLUT, attraverso freeGLUT ha subito una ri-scrittura, per supportare la nuova "programmable pipline" e abbandonare la "fixed pipeline" fatta dalle obsolete e deprecate chiamate (come "glVetex3f") all'interno del glBegin/glEnd. (che spero tu non stia usando)

Attualmente, e da diversi anni, sarebbe piu' corretto (e consigiato) usare SDL (come citato da @pabloski) o GLFW (che e' ancora piu' minimal).


Bada bene, non voglio scoraggiarti... ma solo indirizzarti verso un corretto approccio.
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
bisogna usare il polling
Finora non ho la necessità di aggiungere altro codice per questo. Però ho limitato gli fps del programma, e a riposo non consuma nulla di CPU (controllo con top).
Post automatically merged:

Attualmente, e da diversi anni, sarebbe piu' corretto (e consigiato) usare SDL (come citato da @pabloski) o GLFW (che e' ancora piu' minimal).
Non essendo un programmatore dovevo inziare da qualche parte. GLFW sembra interessante, ma tutto dipende da come gestisce i font.
 
Ultima modifica:

BrutPitt

Utente Attivo
443
408
Finora non ho la necessità di aggiungere altro codice per questo. Però ho limitato gli fps del programma, e a riposo non consuma nulla di CPU (controllo con top).
In questo momento il polling di tastiera e mouse lo stai facendo attraverso GLUT, appunto... per questo @pabloski chiedeva se/come lo stessi facendo ;)


Non essendo un programmatore dovevo inziare da qualche parte. GLFW sembra interessante, ma tutto dipende da come gestisce i font.

Aggiungo dicendo...
OpenGL e' una libreria grafica atta a sfruttare la GPU, i font che stai usando appartengono a GLUT (che non fa parte di OpenGL, ma e' una "libreria" a parte).
La politica OpenGL, a partire dalla 2.0 (2004... ma gia' introdotta precedentemente nella 1.5), e' stata quella di rimanere SOLO libreria grafica: si lascia all'utente il totale e libero utilizzo. (maggiore flessibilita' di programmazione diretta per gli shaders)
Non esistono piu' (non nelle moderne OpenGL) le chiamate preimpostate gluLookAt/gluOrtho/gluPerspective perche' non esistono piu' le matrici interne Model/View/Project (che appartengono alla fixed pipeline)... quindi non si usa piu' GLU (il cui ultimo aggiornamento risale al '98)
Quindi anche chiamate glTranslate/glScale/glRotate... che facevano riferimento ad esse, non esistono piu'.
E' l'utente che gestisce tutte le trasformazioni 2D/3D personalmenete, dichiarando le proprie matrici e gestendo le trasformazioni in prorpio.
Ovviamente sono nate librerie che suppliscono a questo deficit, come GLM (pyGLM), che ha mantenuto un analogo metodo di chiamata (sebbene abbia tolto il suffisso "gl"/"glu", ovviamente), ma bisonga comunque poi occuparsi della trasformazione del vertice.

Certo, il codice con le chiamate alla "fixed pipeline" funziona tranquillamente, ma con due grosse limitazioni.
La prima e' che la "fixed pipeline" aveva/ha un massiccio overhead, dovuto alle cointinue chiamate e reimpostazioni interne "fisse" (quindi poco efficiente).
La seconda e' che un'applicazione non puo' usare, nello stesso context, funzionalita' OpenGL superiori alla 2.1.

Per cio' che riguarda i fonts...
Bisogna utilizzare una libreria esterna... o ingegnarsi da se'.
Come usare stb_truetype per "rasterizzare" i font truetype
 
Ultima modifica:
  • Like
Reactions: clessidra

pabloski

Utente Èlite
2,707
782
GLFW sembra interessante, ma tutto dipende da come gestisce i font.

Non lo fa, così come non la fa OpenGL. GLUT implementa glutBitmapCharacter, che ti consente di renderizzare i font. Ma OpenGL no. Nel caso si usi GLFW, è normale usare FreeType, che poi è usata come backend pure da tante altre librerie, tipo SDL e Pango.

GLFW, a sua volta, è un'ottima astrazione per OpenGL, Vulkan e OpenGL ES. E infatti, non a caso, la usano progetti come il port di Flutter su desktop. E tanti altri. Quindi penso che la direzione giusta, visto che miri a realizzare un framework per GUI, è proprio quella di usare GLFW.

E questo soprattutto perchè ti scontrerai con la necessità di usare GLUT, che non è più mantenuto e nemmeno implementa i meccanismi moderni per la gestione dei contesti, del windowing e soprattutto dell'input!!

Ovviamente questa è la strada del 3D. Ma nessuno t'impedisce di usare una libreria 2D di basso livello, tipo Skia, Cairo.

Però mi pare di capire che tu veda queste librerie come troppo di alto livello e che quindi non ti consentono di realizzare il tuo obiettivo. Però considera che non contengono niente di prefabbricato per implementare e gestire una GUI.
 
  • Like
Reactions: clessidra

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Non lo fa, così come non la fa OpenGL.
Sì, per opengl posso usare il binding per python di freetype. Ed è quello che ho fatto fino a poco fa usando l'esempio contenuto in freetype-py. Con alcune limitazioni: il testo è visualizzato correttamente se uso un font mono (per ora sto usando VeraMono) ed più lento nel refresh. Credo che dovrò rivedere parzialmente il codice. Allegherò uno screenshot della stessa finestra ma usando il font ttf.
Ovviamente questa è la strada del 3D. Ma nessuno t'impedisce di usare una libreria 2D di basso livello, tipo Skia, Cairo.
Però mi pare di capire che tu veda queste librerie come troppo di alto livello...
Non ho la pretesa di diventare un programmatore professionista, python e le qt5 per ora mi sono bastate. E ti sono grato per il consiglio che mi hai dato sulle GLFW, le ho già dato un'occhiata e approfondirò ulteriormente.
Potrei anche usare cairo con python, ma dovrei usare un contesto a parte, come per esempio le xlib, per visualizzare le sue superfici.
Post automatically merged:

Uno screenshot della stessa finestra del primo post ma con il testo che usa un font truetype:
screenshot3.png
 

pabloski

Utente Èlite
2,707
782
Non ho la pretesa di diventare un programmatore professionista, python e le qt5 per ora mi sono bastate. E ti sono grato per il consiglio che mi hai dato sulle GLFW, le ho già dato un'occhiata e approfondirò ulteriormente.

GLFW è stata tirata in ballo sia da me che da BrutPitt, per la semplice ragione che sei capitato proprio in un momento di rapidi cambiamenti nel mondo del 3D. Cioè, per puro divertimento, ovviamente non c'è nessuna controindicazione nell'usare OpenGL + GLUT. Nessuno ti vieta nemmeno di installare RiscOS e usare quello per programmare. C'è tanta gente che lo fa. Su Raspberry PI ovviamente!

In un'ottica più generale, il problema è che OpenGL è di fatto deprecato a favore di Vulkan. GLUT è vecchio come il cucco. Su Unix, Xorg sta morendo e cedendo il posto a Wayland. Cioè sei incappato nel bel mezzo di un terremoto.

Chiaro che non devi correre dietro ai cambiamenti. E anzi ti conviene continuare su questa strada. Dopo di che, migrerai alle nuove tecnologie. E ti sarà, a quel punto, chiaro cos'è cambiato e perchè. In un certo senso, ti trovi nell'invidiabile posizione di poter osservare il perchè di una rivoluzione e i miglioramenti apportati. E credo che sarà molto stimolante.

Del resto è la stessa cosa che hanno provato e vissuto i programmatori 3D quando si è passati dalla pipeline fissa a quella programmabile. E scoprire che la pipeline programmabile poteva essere estesa per implementare quella cosa che oggi, diamo per scontata, e che si chiama GPGPU ( CUDA e similari, con l'accelerazione di reti neurali e quant'altro ). Beh, direi che sono cose che ti fanno dire WOW!!
 
  • Like
Reactions: clessidra

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
GLFW è stata tirata in ballo sia da me che da BrutPitt, ...
Uso Linux da secoli e so non solo cosa sta accadendo adesso ma anche cosa è accaduto in passato. In ambito 3d vulkan è sempre più popolare per la sua efficienza.
Per quanto riguarda wayland, credo che si basi sulle opengl es. E mi fermo qui perchè non voglio fare nessun discorso su xorg e wayland.

Per me opengl è la soluzione migliore, è una tecnologia nata tanti anni fa di cui ci sono guide dovunque. Io prima di questo progetto non sapevo nulla di opengl, figuriamoci se so qualcosa di vulkan o delle directx.

Comunque, tornando al progetto, dopo aver implementato le freetype mi sono reso conto che l'esempio preso da freetype-py è alquanto, come dire, sovrabbondante (e forse nemmeno completamente corretto), e sto cercando di ricodificare quella parte. Alla fine quello che si fa con questa libreria è renderizzare un testo in una texture da visualizzare in opengl. Potrei benissimo usare PIL per la stessa operazione, o lo stesso cairo che hai già nominato, che è anche più completo :) .
 

pabloski

Utente Èlite
2,707
782
Per quanto riguarda wayland, credo che si basi sulle opengl es.

Magari fosse così semplice. Wayland si occupa di gestire il windowing, gli eventi d'input e i buffer su cui disegnare. E pertanto sfrutta EGL, a cui affianco l'API GBM ( o EGLStreams nel caso dei driver proprietari NVidia ). GBM è supportata da Mesa, che implementa sia OpenGL che Vulkan.

I client possono disegnare usando quello che gli pare, compreso Vulkan. Ovviamente nelle specs di Wayland, che è un progetto abbastanza vecchio, figura OpenGL/ES, perchè all'epoca Vulkan non esisteva. In ogni caso, Wayland è abbastanza agnostico da questo punto di vista.

Per me opengl è la soluzione migliore, è una tecnologia nata tanti anni fa di cui ci sono guide dovunque. Io prima di questo progetto non sapevo nulla di opengl, figuriamoci se so qualcosa di vulkan o delle directx.

Ovviamente la maturità ha i suoi vantaggi. Poi non è che OpenGL non sia stata modernizzata nel corso degli anni. Cioè, fino a qualche anno fa, era l'unica API 3D open e diffusa.

Alla fine quello che si fa con questa libreria è renderizzare un testo in una texture da visualizzare in opengl. Potrei benissimo usare PIL per la stessa operazione, o lo stesso cairo che hai già nominato, che è anche più completo :) .

In genere Freetype si lascia che venga usato come backend dai vari Cairo, PIL, SDL, ecc... Che poi ha senso non reinventare la ruota, su un tema che è spinoso. Perchè non dimentichiamo che ci sono brevetti sotto le implementazioni dei font renderer, specialmente i truetype.

Quello che potresti trovarti di fronte procedendo oltre, è l'evidenza che SDL è forse la migliore scelta. Questo perchè ti consente di creare contesti OpenGL, dove poi operare come già stai facendo. E in più fornisce wrapper per FreeType, librerie d'input, sostituisce GLUT. Oltre ad alcune funzioni che non ti servono, tipo l'audio, l'identificazione delle feature della CPU, il threading.
 

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Quello che potresti trovarti di fronte procedendo oltre, è l'evidenza che SDL è forse la migliore scelta. Questo perchè ti consente di creare contesti OpenGL, dove poi operare come già stai facendo. E in più fornisce wrapper per FreeType, librerie d'input, sostituisce GLUT. Oltre ad alcune funzioni che non ti servono, tipo l'audio, l'identificazione delle feature della CPU, il threading.
Non saprei su SDL. Ho fatto delle prove un paio di volte con degli esempi credo ufficiali e o non venivano eseguiti o usava tutta la cpu o comunque mostravano un suo utilizzo anomalo.

Tornando a wayland, non è che poi viene usato da tutti. Ci sono quelli che vogliono rimanere meravigliati osservando il proprio desktop e allora lo usano, e molti non sanno che da questo punto di vista non è che sia molto diverso dai compositori separati. Compiz è stato un grande software ai suoi tempi, e può essere ancora installato se si vuole. Ma tantissimi usano ancora Xorg che è ha una impostazione server/client. La maggior parte degli utenti linux non sa di questa separazione e quindi non sa che possono anche risiedere su due macchine differenti. Un aspetto da non sottovalutare ora che internet è diffuso ovunque.
 

pabloski

Utente Èlite
2,707
782
Non saprei su SDL. Ho fatto delle prove un paio di volte con degli esempi credo ufficiali e o non venivano eseguiti o usava tutta la cpu o comunque mostravano un suo utilizzo anomalo.

Attenzione ai tutorial, perchè si trovano ancora quelli per SDL v1. Usarli con SDL v2, produce spesso programmi buggati o non compilabili.

Tornando a wayland, non è che poi viene usato da tutti.

Ma il futuro prossimo è quello. Fedora ce l'ha di default. Ubuntu pure. Xorg è usato come modalità di ripiego, in caso Wayland non funzioni correttamente. Sway sostituisce i3. Quasi tutti i tiling wm maggiori stanno vedendo lo sviluppo di cloni che usano Wayland.

KDE e Gnome sono Wayland-first.

Ci sono quelli che vogliono rimanere meravigliati osservando il proprio desktop e allora lo usano, e molti non sanno che da questo punto di vista non è che sia molto diverso dai compositori separati.

Il problema è che l'architettura di Xorg non consente l'implementazione di meccanismi di sicurezza adeguati. Flatpak, che nasce per il sandboxing ( tra le altre funzionalità ) delle applicazioni, è costretto ad aprire un buco gigantesco per le applicazioni grafiche. La possibilità che Xorg offre, di accedere al framebuffer da parte di qualsiasi applicazioni, rende facile "rubare" le schermate delle altre applicazioni.

Insomma, Xorg ha le sue criticità, figlie della sua età. All'epoca andava bene, oggi no. Wayland non è solo un esercizio di stile, giusto per fare i bastion contrari.

Ma tantissimi usano ancora Xorg che è ha una impostazione server/client. La maggior parte degli utenti linux non sa di questa separazione e quindi non sa che possono anche risiedere su due macchine differenti. Un aspetto da non sottovalutare ora che internet è diffuso ovunque.

Appunto. Nessuno di fatto sfrutta questa caratteristica di Xorg, appoggiandosi a programmi esterni per il remoting. Senza contare che viviamo in un mondo 3D, e la trasparenza di rete di Xorg non supporta il 3D ( ci sarebbe VirtualGL, ma poi manca tutto quanto riguarda la trasmissione del contenuto del framebuffer in maniera efficiente, compressa, con bassa latenza...in pratica si preferisce usare soluzioni tipo Parsec ).
 

BrutPitt

Utente Attivo
443
408
Uso Linux da secoli e so non solo cosa sta accadendo adesso ma anche cosa è accaduto in passato. In ambito 3d vulkan è sempre più popolare per la sua efficienza.
Prendo spunto dal tuo commento per riferirmi @clessidra:
Vero, pero' con Vulkan l'utente ha il compito di gestire da se' tutta la pipeline grafica pedissequamente e a un piu' basso livello, che OpenGL in un certo qual modo auto-imposta in base a cio' che devi fare.
Ovviamente cio porta a maggiori performance e flessibilita', a discapito di un codice piu' prolisso, e a un apprendimento iniziale decisamente piu' lungo.
OpenGL dal canto suo ha fatto molti passi avanti dalla fixed pipeline, fino ad arrivare ad introdurre nella 4.5 la modalita' AZDO (Approaching Zero Driver Overhead) in cui si accede direttamente all'oggetto (come avviene in vulkan), senza passare per quel "contorto" meccanismo di (per es.):
  • Attiva texture
  • Bind texture
  • Usa texture
(detto in modo "molto" semplicistico)

Detto questo pero', non era mia intenzione farti passare a tutti i costi a GLFW, cosi' come non volevo "istigarti" a lasciare immediatamente la fixed pipeline... c'era solo l'intento di "avvertirti" che stavi proseguendo per una strada che non e' piu' battuta.

Chiaro che non devi correre dietro ai cambiamenti. E anzi ti conviene continuare su questa strada. Dopo di che, migrerai alle nuove tecnologie. E ti sarà, a quel punto, chiaro cos'è cambiato e perchè. In un certo senso, ti trovi nell'invidiabile posizione di poter osservare il perchè di una rivoluzione e i miglioramenti apportati. E credo che sarà molto stimolante.

Del resto è la stessa cosa che hanno provato e vissuto i programmatori 3D quando si è passati dalla pipeline fissa a quella programmabile. E scoprire che la pipeline programmabile poteva essere estesa per implementare quella cosa che oggi, diamo per scontata, e che si chiama GPGPU ( CUDA e similari, con l'accelerazione di reti neurali e quant'altro ). Beh, direi che sono cose che ti fanno dire WOW!!
Vero, proprio vissuto sulla mia pelle :) ... pero' mentre per "noi", quella di usare la fixed pipeline, era una scelta obbligata, tu se lo ritenessi opportuno potresti gia' adesso cambiare strada.
Per questo mi sembrava corretto avvertirti.

Quello che potresti trovarti di fronte procedendo oltre, è l'evidenza che SDL è forse la migliore scelta. Questo perchè ti consente di creare contesti OpenGL, dove poi operare come già stai facendo. E in più fornisce wrapper per FreeType, librerie d'input, sostituisce GLUT. Oltre ad alcune funzioni che non ti servono, tipo l'audio, l'identificazione delle feature della CPU, il threading.
Concordo con te sul fatto che SDL possa essere la scelta migliore per i suoi obbiettivi, ed aggiungo anche ha il porting Android e la gestione del TouchScreen.
GLFW, come avevo scritto, e' minimalista: oltre a gestire mouse/tastiera/display su PC, fa poco altro.

Non saprei su SDL. Ho fatto delle prove un paio di volte con degli esempi credo ufficiali e o non venivano eseguiti o usava tutta la cpu o comunque mostravano un suo utilizzo anomalo.
Quello dell'abnorme utilizzo della CPU era un bug conosciuto di SDL , che e' stato risolto (dovrebbe) con la versione 2.0.10.0
Avveniva se si utilizzava SDL_INIT_GAMECONTROLLER in SDL_Init(), ed avveniva solo con alcuni drivers mouse, anche senza avere un gamecontroller presente: una anomla generazione di eventi che riempiva la "coda" fino anche a saturarla come in questa discussione (non solo su Windows 10):
(il fatto e' che il "tipico" esempio di inizializzazione SDL, utilizzato sul sito, dice di inizializzare l'engine con:
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER | SDL_INIT_GAMECONTROLLER);
per cui alcuni avevano questo problema, nonostante non avessero un GameController, perche' di fatto lo inizializzavano seguendo pedissequamente l'esempio.)
 
Ultima modifica:
  • Like
Reactions: clessidra

clessidra

Utente Attivo
766
272
CPU
VIA C3
GPU
Ati Rage
OS
linux - Red Hat 1.1
Attenzione ai tutorial, perchè si trovano ancora quelli per SDL v1. Usarli con SDL v2, produce spesso programmi buggati o non compilabili.

Ma il futuro prossimo è quello. Fedora ce l'ha di default. Ubuntu pure. Xorg è usato come modalità di ripiego, in caso Wayland non funzioni correttamente. Sway sostituisce i3. Quasi tutti i tiling wm maggiori stanno vedendo lo sviluppo di cloni che usano Wayland.

KDE e Gnome sono Wayland-first.

Il problema è che l'architettura di Xorg non consente l'implementazione di meccanismi di sicurezza adeguati. Flatpak, che nasce per il sandboxing ( tra le altre funzionalità ) delle applicazioni, è costretto ad aprire un buco gigantesco per le applicazioni grafiche. La possibilità che Xorg offre, di accedere al framebuffer da parte di qualsiasi applicazioni, rende facile "rubare" le schermate delle altre applicazioni.

Insomma, Xorg ha le sue criticità, figlie della sua età. All'epoca andava bene, oggi no. Wayland non è solo un esercizio di stile, giusto per fare i bastion contrari.

Appunto. Nessuno di fatto sfrutta questa caratteristica di Xorg, appoggiandosi a programmi esterni per il remoting. Senza contare che viviamo in un mondo 3D, e la trasparenza di rete di Xorg non supporta il 3D ( ci sarebbe VirtualGL, ma poi manca tutto quanto riguarda la trasmissione del contenuto del framebuffer in maniera efficiente, compressa, con bassa latenza...in pratica si preferisce usare soluzioni tipo Parsec ).
Io cerco prima gli esempi ufficiali e li provo. Lo stesso ho fatto per sdl2, tempo fa, ma non moltissimo.

Certo, Red Hat sta spingendo al massimo wayland, e si può anche dire che Gnome è un altro suo prodotto, e io mi permetto di dire che i programmatori di Gnome non è più gente libera... di programmare. Poi c'è Canonical che da anni sta cercando di introdurre un suo server grafico al posto di Xorg, e ora vanta di essere compatibile con wayland.
Sway è un'ottima cosa se parliamo di wayland dato che rende disponibile un window manager svincolato sia da Gnome che da Kde, giusto per mantenere un certo grado di libertà, ciò che ha consentito a Linux di crescere.

Non voglio parlare di sicurezza, oramai ti bucano dappertutto, anche se ce l'hai spento il pc, ti arriva spam per posta ordinaria dicendoti che non potevano farlo tramite computer perchè è spento. Basta vedere i processori. Le schede grafiche sono per ora salve, forse nessuno si è messo d'impegno su quelle.

Io non sono contro wayland, ma non è completo nè ottimizzato. Insomma, lo stanno ancora sviluppando, da più di dieci anni.

Spero che tutti quelli che ci fanno i soldi con Linux capiscano che Linux non è un sistema operativo commerciale ed è meglio per tutti che non lo diventi, mica Microsoft e Google campano d'aria.
Post automatically merged:

Detto questo pero', non era mia intenzione farti passare a tutti i costi a GLFW, cosi' come non volevo "istigarti" a lasciare immediatamente la fixed pipeline... c'era solo l'intento di "avvertirti" che stavi proseguendo per una strada che non e' piu' battuta.
Io in questo momento sto imparando, e devo dire che opengl si sta dimostrando idoneo per quello che devo fare. Ho letto tutto quello che avete scritto, sia tu che pabloski, ma non è che ho tante scelte :) . Sdl2 l'ho trovato sin da subito interessante, e so può essere utilizzato su varie piattaforme.

Per ora mi sto divertendo nella gestione dei box. Una volta risolto questo, e trovato il modo per selezionare il testo in un widget di tipo lineedit potrò dire di aver raggiunto il primo traguardo.
Beh, ci sarebbe anche la questione dei font da sistemare.
 
Ultima modifica:

Entra

oppure Accedi utilizzando

Hot: E3 2021, chi ti è piaciuto di più?

  • Ubisoft

    Voti: 4 19.0%
  • Gearbox

    Voti: 0 0.0%
  • Xbox & Bethesda

    Voti: 17 81.0%
  • Square Enix

    Voti: 0 0.0%
  • Capcom

    Voti: 0 0.0%
  • Nintendo

    Voti: 3 14.3%
  • Altro (Specificare)

    Voti: 0 0.0%