Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a Mak73 [quote=Mak73] In risposta a VagaPPC [quote=VagaPPC] Scusami se ti contraddico, ma ti sbagli, è possibile importare le funzioni che ti servono senza dover incorporare tutto il framework. In python si fa con il from [classe] import [funzione/funzioni], sotto della documentazione: [url=https://www.geeksforgeeks.org/import-module-python/]https://www.geeksforgeeks.org/import-module-python/[/url] Non so come si fa in C/C++ ma penso ci sia un metodo. [/quote] Non ci capiamo, cerco di rendere l'idea con un esempio: in C quando importi "stdio.h", non è che hai importato solo una classe per fare una singola cosa, bensì un gruppo di comandi con vari scopi, magari potrebbero non interessarti tutte quelle cose però le hai caricate. Stessa cosa fai col framework, un esempio lo hai [url=https://doc.qt.io/qtforpython-6/quickstart.html]qui[/url]. Per richiamare le varie classi QT deve far riferimento all'intero framework, nell'esempio il PySide6. In quest'altro [url=https://doc.qt.io/qtforpython-6/tutorials/basictutorial/clickablebutton.html]esempio[/url] puoi vedere che fa sempre riferimento a quello. Quindi lui apre il framework, va a prendere le classi che gli dici e le usa, negli esempi è piuttosto evidente. Niente di male in ciò, funzionano tutti così grosso modo. [quote] Non so come fanno su win, haiku e mac, ma su questi sistemi le QT hanno un aspetto apparentemente nativo. Forse perché il porting è stato fatto con maggiore attenzione ai dettagli. In questo modo i programmi oltre a essere esteticamente più allineati al resto del sistema, sarebbero anche più veloci. Quello che dici sarebbe bellissimo, ci sarebbe però da aggiornare pesantemente MUI, penso solo alla classe text, quella delle QT è mostruosamente più avanti, per non parlare della classe HTML di MUI che non implementa ancora l'HTML4 completamente. [/quote] Sulle altre piattaforme hanno molti più sviluppatori, se unisci questo al fatto che l'OS stesso è decisamente più evoluto, capisci che fare un porting di un certo livello diventa più facile, qui come dicevi tu nell'altro topic c'è nè uno che fa tutto il porting lui! Il fatto che un framework abbia incorporato un motore di rendering HTML a me pare una boiata... in un sistema moderno se voglio visualizzare un file di quel tipo dovrebbe aprirmi il motore del browser che uso come predefinito, non andare a prenderne un'altro, sempre per il discorso che rende il tutto più omogeneo oltre che alleggerire il sistema. Si perchè se anche le GTK fanno così mi ritrovo installati ben tre motori per visualizzare file HTML, uno nelle QT, uno nelle GTK e uno nel browser predefinito... stupendo!!! Alla faccia dei sistemi leggeri. [quote] Per farlo ci vorrebbero sicuramente più sviluppatori e una forte collaborazione tra i vari team, che dovrebbe coinvolgere chi produce il kernel e chi sviluppa MUI, con le attuali risorse, dovrebbero impegnarsi a fare quello. Con il senno di poi, mi verrebbe da dire che se avessero finanziato un progetto simile, anni fa anziché sprecare risorse per progetti titanici come OpenOffice (che poi divenne LibreOffice) e Thimberwolf, a quest'ora avremmo finito, con tanto di browser internet. [/quote] Guarda che MUI è parte integrante di MorphOS da anni, lo sviluppo di MUI da anni va avanti grazie al Team MorphOS. [quote] Fondamentalmente la community chiede cose semplici come browser e office, e loro si sono buttati a capofitto per realizzarli. Sarebbe stato più saggio concentrarsi sulle fondamenta, il resto sarebbe stata una conseguenza. [/quote] Un browser è 'semplice' per chi lo usa solamente, ma internamente è una cosa piuttosto complessa, non per niente è piuttosto difficile avere dei porting, stessa cosa per le suite Office. I vari AmigaOS sono così proprio perchè era sbagliata l'idea di partenza, cioè reimplementare il vecchio AOS, che però appunto era già vecchio di suo. Occorreva pensare ad un OS nuovo un po' come ha fatto Apple con MacOS X [quote] Da quello che leggo sui forum esteri, Hyperion ha una forte emorragia di sviluppatori, a causa del fatto che non li paga, mentre AmiKit sembra aperta al dialogo anche con singoli sviluppatori, anche appartenenti al mondo morphos. E tendono a rilasciare aggiornamenti regolari. Raggiungere un simile risultato, sarebbe un tocca sana, AmigaNG tornerebbe a essere un OS utilizzabile per tutte le attività quotidiane. [/quote] Vedremo [/quote] formattazione A sinistra Giustificata Nessuna

10 Ottobre 2022 Postato da: VagaPPC QT e divagazioni

In risposta a Mak73 per evitare OT Mak73 In risposta a VagaPPC VagaPPC In risposta a Mak73 300mb per l'intero desktop enviroment, parlo di KDE non di QT. Le QT hanno funzioni che vanno oltre ai toolkit grafici, includono anche webkit, gestione dei database SQL (Oracle, postgress, mysql, maira db), pagamenti con paypal, e un sacco di altra roba. Sono migliaia di funzioni si ha l'impressione che hanno tutto ciò che pensi. Solo con le versioni free puoi mettere in piedi un intero sistema operativo e applicazioni senza aver bisogno di altro. Sei sicuro di quello che scrivi, i database che citi sono tutti su server, quindi in linea di massima vengono interrogati da linguaggio quali PHP, Ruby o ASP, che sono linguaggi lato server appunto. Perché le QT dovrebbero implementare funzioni simili visto che si occupano di un'ambito completamente diverso, cioè roba residente su un computer locale? Pagamenti con PayPal ci pensa Javascript, perché sempre di roba online stiamo parlando. Trovo strana l'implementazione di webkit poiché ormai i programmi moderni per aprire documenti HTML si appoggiano direttamente sul motore del browser predefinito, per far sentire l'utente più a suo agio. Da codice devi poter accedere ai server, per questo ti servono delle istruzioni. Qui c'è un esempio: https://doc.qt.io/qt-6/sql-connecting.html Modificato il 19/10/2022 alle ore 17:54:48

Commenti: 25  Aggiungi - Pagine: 1-2

Il Webmaster Post inviati: 4739	Commento Mak73 19 Ottobre 2022    22:34:26
	In risposta a VagaPPC VagaPPC Scusami se ti contraddico, ma ti sbagli, è possibile importare le funzioni che ti servono senza dover incorporare tutto il framework. In python si fa con il from [classe] import [funzione/funzioni] , sotto della documentazione: https://www.geeksforgeeks.org/import-module-python / Non so come si fa in C/C++ ma penso ci sia un metodo. Non ci capiamo, cerco di rendere l'idea con un esempio: in C quando importi "stdio.h", non è che hai importato solo una classe per fare una singola cosa, bensì un gruppo di comandi con vari scopi, magari potrebbero non interessarti tutte quelle cose però le hai caricate. Stessa cosa fai col framework, un esempio lo hai qui . Per richiamare le varie classi QT deve far riferimento all'intero framework, nell'esempio il PySide6. In quest'altro esempio puoi vedere che fa sempre riferimento a quello. Quindi lui apre il framework, va a prendere le classi che gli dici e le usa, negli esempi è piuttosto evidente. Niente di male in ciò, funzionano tutti così grosso modo. Citazione Non so come fanno su win, haiku e mac, ma su questi sistemi le QT hanno un aspetto apparentemente nativo. Forse perché il porting è stato fatto con maggiore attenzione ai dettagli. In questo modo i programmi oltre a essere esteticamente più allineati al resto del sistema, sarebbero anche più veloci. Quello che dici sarebbe bellissimo, ci sarebbe però da aggiornare pesantemente MUI, penso solo alla classe text, quella delle QT è mostruosamente più avanti, per non parlare della classe HTML di MUI che non implementa ancora l'HTML4 completamente. Sulle altre piattaforme hanno molti più sviluppatori, se unisci questo al fatto che l'OS stesso è decisamente più evoluto, capisci che fare un porting di un certo livello diventa più facile, qui come dicevi tu nell'altro topic c'è nè uno che fa tutto il porting lui! Il fatto che un framework abbia incorporato un motore di rendering HTML a me pare una boiata... in un sistema moderno se voglio visualizzare un file di quel tipo dovrebbe aprirmi il motore del browser che uso come predefinito, non andare a prenderne un'altro, sempre per il discorso che rende il tutto più omogeneo oltre che alleggerire il sistema. Si perchè se anche le GTK fanno così mi ritrovo installati ben tre motori per visualizzare file HTML, uno nelle QT, uno nelle GTK e uno nel browser predefinito... stupendo!!! Alla faccia dei sistemi leggeri. Citazione Per farlo ci vorrebbero sicuramente più sviluppatori e una forte collaborazione tra i vari team, che dovrebbe coinvolgere chi produce il kernel e chi sviluppa MUI, con le attuali risorse, dovrebbero impegnarsi a fare quello. Con il senno di poi, mi verrebbe da dire che se avessero finanziato un progetto simile, anni fa anziché sprecare risorse per progetti titanici come OpenOffice (che poi divenne LibreOffice) e Thimberwolf, a quest'ora avremmo finito, con tanto di browser internet. Guarda che MUI è parte integrante di MorphOS da anni, lo sviluppo di MUI da anni va avanti grazie al Team MorphOS. Citazione Fondamentalmente la community chiede cose semplici come browser e office, e loro si sono buttati a capofitto per realizzarli. Sarebbe stato più saggio concentrarsi sulle fondamenta, il resto sarebbe stata una conseguenza. Un browser è 'semplice' per chi lo usa solamente, ma internamente è una cosa piuttosto complessa, non per niente è piuttosto difficile avere dei porting, stessa cosa per le suite Office. I vari AmigaOS sono così proprio perchè era sbagliata l'idea di partenza, cioè reimplementare il vecchio AOS, che però appunto era già vecchio di suo. Occorreva pensare ad un OS nuovo un po' come ha fatto Apple con MacOS X Citazione Da quello che leggo sui forum esteri, Hyperion ha una forte emorragia di sviluppatori, a causa del fatto che non li paga, mentre AmiKit sembra aperta al dialogo anche con singoli sviluppatori, anche appartenenti al mondo morphos. E tendono a rilasciare aggiornamenti regolari. Raggiungere un simile risultato, sarebbe un tocca sana, AmigaNG tornerebbe a essere un OS utilizzabile per tutte le attività quotidiane. Vedremo
	Pace e bene a tutti.