Io uso Vs2005, ma questo è molto interessante... si può avere gratis?
non solo si può avere gratis.. ma si integra in kdevelop e visual studio!

Ed è questo il problema. Per questo motivo sono poco appetibili.

Eh lo so ma del resto la Trolltech campa praticamente solo con queste. Le altre cose sono solo appendici. Anche se pure QTopia sta prendendo piede... :cool:

Non ho capito che vuoi dire.
Ti ho detto che la versione free ci puoi fare solo codice GPL.


Hai detto questo: E' chiaro che con questo non puoi scrivere software proprietario ma solo GPL.


Comunque mi hai risposto, se voglio fare programmi a pagamento e/o chiuso devo comprarlo. :D giusto?

Per curiosità, a quale versione delle DirectX sei rimasto fermo? Sembra quasi che ci voglia la clava di Fred Flintstone per programmarle... :rolleyes:
non me lo ricordo, ma ho specificato che erano vecchie! era per dire che una volta opengl era più semplice di sicuro! ora non lo so!
Cosa intendi con ciò?
che non è affatto difficile programmare in opengl! in più per tornare un pò più in topic.. so dell'esistenza delle librerie QGL che fanno parte delle QT! più facile di così...
D'altra parte se i programmatori di giochi si sono spostati quasi tutte sulle DirectX, forse la situazione è UN TANTINO migliorata, non credi?
l'ho anche scritto!
Anche le DirectX potrebbero esserlo se qualcuno ne rilasciasse un porting.
solo MS può farlo!
Appunto: Windows è la piattaforma più diffusa, e le DirectX sono le librerie più produttive. Binomio perfetto.
le directx sono le librerie più produttive SOLO perchè windows è la piattaforma più diffusa! hai ripetuto lo stesso concetto due volte :D!

No, le DirectX sono più produttive perchè sono più facili da programmare. Almeno a detta delle persone che qui sul forum ci hanno a che fare (come Fek, per esempio). Ti dirò... Mi sono letto le specifiche dell'OpenGL 1.1 a suo tempo nel compilatore Borland C++, poi quelle in Matlab, poi ho scaricato i PDF fino alla 2.0 e me li sono letti (compresi i PDF dei vertex e pixels shaders). Poi sono andato sull'MSDN e mi sono letto tutta la documentazione delle DirectX 9.0c. Su entrambi ho capito quasi tutto. OpenGL ha più un approccio a basso livello ed esecutivo: devi dirgli per filo e per segno cosa fare e come farlo. Per me che preferisco il C al Java è meglio OpenGL. Voglio avere il controllo completo. Ammetto che le DirectX hanno una programmazione più lineare, avendo completamente abbandonato la compatibilità con il passato, a differenza di OpenGL. In questo senso l'OpenGL sembra la MS della situazione!

Inoltre le DirectX sono più orientate agli oggetti. Le OpenGL sono più orientate al procedurale. E' forse per questo che sono viste più facili da programmare: si prestano molto di più a linguaggi OO, che sono più produttivi... (io mi trovo meglio con il funzionale... Ma va beh!)...

No, le DirectX sono più produttive perchè sono più facili da programmare. Almeno a detta delle persone che qui sul forum ci hanno a che fare (come Fek, per esempio). Ti dirò... Mi sono letto le specifiche dell'OpenGL 1.1 a suo tempo nel compilatore Borland C++, poi quelle in Matlab, poi ho scaricato i PDF fino alla 2.0 e me li sono letti (compresi i PDF dei vertex e pixels shaders). Poi sono andato sull'MSDN e mi sono letto tutta la documentazione delle DirectX 9.0c. Su entrambi ho capito quasi tutto. OpenGL ha più un approccio a basso livello ed esecutivo: devi dirgli per filo e per segno cosa fare e come farlo. Per me che preferisco il C al Java è meglio OpenGL. Voglio avere il controllo completo. Ammetto che le DirectX hanno una programmazione più lineare, avendo completamente abbandonato la compatibilità con il passato, a differenza di OpenGL. In questo senso l'OpenGL sembra la MS della situazione!

Inoltre le DirectX sono più orientate agli oggetti. Le OpenGL sono più orientate al procedurale. E' forse per questo che sono viste più facili da programmare: si prestano molto di più a linguaggi OO, che sono più produttivi... (io mi trovo meglio con il funzionale... Ma va beh!)...
non sono completamente daccordo.. prima di tutto ci sono librerie di più alto livello che si appoggiano a opengl! quindi non sei obbligato a stare sul basso livello! queste librerie sono inoltre OO e non procedurali! facevo appunto l'esempio di QGL ma ce ne sono per tutti i gusti! poi OGL è retrocompatibile innanzitutto perchè è stata progettata bene sin dall'inizio, e poi perchè è una qualità essere retrocompatibile se parli di librerie grafiche! in tutto questo bisogna sottolineare che OpenGL è multipiattaforma ! perciò se vuoi fare un gioco o un'applicazione multipiattaforma... vedi che non è più vero che le dx sono più produttive!

solo MS può farlo!
Falso. Altrimenti non esisterebbero né wine né tanto meno Cedega.
le directx sono le librerie più produttive SOLO perchè windows è la piattaforma più diffusa! hai ripetuto lo stesso concetto due volte :D!
No, sono più produttive perché permettono di realizzare un obiettivo in meno tempo e più comodamente. Checché tu ne dica.

x mjordan: perfettamente d'accordo (a parte l'ultima frase :D)

non sono completamente daccordo.. prima di tutto ci sono librerie di più alto livello che si appoggiano a opengl! quindi non sei obbligato a stare sul basso livello! queste librerie sono inoltre OO e non procedurali! facevo appunto l'esempio di QGL ma ce ne sono per tutti i gusti! poi OGL è retrocompatibile innanzitutto perchè è stata progettata bene sin dall'inizio, e poi perchè è una qualità essere retrocompatibile se parli di librerie grafiche! in tutto questo bisogna sottolineare che OpenGL è multipiattaforma ! perciò se vuoi fare un gioco o un'applicazione multipiattaforma... vedi che non è più vero che le dx sono più produttive!
Se sopra le librerie ci costruisce un framework, è ovvio che puoi essere più produttivo. Ma ti sfugge forse che la stessa cosa la si può fare (e la si fa: mica i programmatori DirectX riscrivono tutto da capo ogni volta) anche con le DirectX. E in meno tempo.

Hai detto questo: E' chiaro che con questo non puoi scrivere software proprietario ma solo GPL.


Comunque mi hai risposto, se voglio fare programmi a pagamento e/o chiuso devo comprarlo. :D giusto?

Esatto :D
E se hai intenzione di sviluppare qualcosa da solo, credo che il prezzo non ti possa rendere giustizia. Effettivamente sono un po costosette. Però, che vuoi, in fondo sono considerate il miglior GUI toolkit C++. Il meglio si paga caro, mica vale solo per le schede grafiche :O

EDIT: Aggiungo una cosa. Il supporto di assistenza è senza pari. C'è gente che dice che entro mezz'ora ricevi risposta al tuo quesito. E soprattutto: l'assistenza viene fatta dagli stessi sviluppatori del codice, quindi conoscono le QT non solo a livello di uso ma di internals. Quindi puoi prendere quello che ti dicono come il miglior modo possibile di operare. :O Trolltech fra i suoi clienti ha la NASA, la Adobe e la IBM :O Solo per citarne alcuni...

Se sopra le librerie ci costruisce un framework, è ovvio che puoi essere più produttivo. Ma ti sfugge forse che la stessa cosa la si può fare (e la si fa: mica i programmatori DirectX riscrivono tutto da capo ogni volta) anche con le DirectX. E in meno tempo.
si ma bjt2 ha detto che le dx sono già a un livello più alto in partenza! il che significa un pò di potere in meno.. io sto a quello che dice lui perchè non conosco abbastanza bene le nuove dx! comunque OGL è stato pensato per essere un back-end e lo dimostra il fatto che appunto è più verso il procedurale e il basso livello!
comunque mi devi dare ragione sul fatto della multipiattaforma! lì ti scordi di essere più produttivo con dx!

il discorso wine-cedega non esiste! si tratta di emulazione, che è molto diverso!

(a parte l'ultima frase :D)

Non ne avevo dubbi :D

Esatto :D
E se hai intenzione di sviluppare qualcosa da solo, credo che il prezzo non ti possa rendere giustizia. Effettivamente sono un po costosette. Però, che vuoi, in fondo sono considerate il miglior GUI toolkit C++. Il meglio si paga caro, mica vale solo per le schede grafiche :O

EDIT: Aggiungo una cosa. Il supporto di assistenza è senza pari. C'è gente che dice che entro mezz'ora ricevi risposta al tuo quesito. E soprattutto: l'assistenza viene fatta dagli stessi sviluppatori del codice, quindi conoscono le QT non solo a livello di uso ma di internals. Quindi puoi prendere quello che ti dicono come il miglior modo possibile di operare. :O Trolltech fra i suoi clienti ha la NASA, la Adobe e la IBM :O Solo per citarne alcuni...
concordo! non è un caso che KDE ha avuto una crescita così esponenziale! hanno a disposizione uno dei migliori strumenti (se non il migliore) per programmare qualcosa con un'interfaccia grafica! poi le QT coprono qualsiasi campo, dalla gestione di connessioni con TCP/IP/UDP.. a librerie grafiche.. a gestione files.. a chissà cos'altro! e tutto rigorosamente multipiattaforma!
ecco cosa manca a gnome! un ambiente di sviluppo decente! perchè le gtk sarebbero in grado di competere con qt (non sempre ma ogni tanto)! in KDE kdevelop (con integrato QTDesigner) è sempre stato il miglior ambiente a disposizione su linux! adesso c'è anche eclipse a fare concorrenza! ma credo che servono a cose diverse, poi eclipse non ha ancora un disegnatore di interfaccie all'altezza!

...
bisogna sottolineare che OpenGL è multipiattaforma ! perciò se vuoi fare un gioco o un'applicazione multipiattaforma... vedi che non è più vero che le dx sono più produttive!
appunto, SE si vuole ;)
è qui il punto, spesso lo sviluppo di un gioco su un numero di "piattaforme" elevato è quello che si vorrebbe evitare o quantomeno minimizzare: perchè sostanzialmente equivale a dover frammentare e moltiplicare il lavoro richiesto al team di sviluppo prima e a quelli di test e supporto, dopo.
Anche se molte delle piattaforme del mondo informatico condividono delle API che qualche consorzio ha dichiarato standard apposta per ridurre lo sforzo richiesto al porting di un' applicazione, ognuna mantiene peculiarità e idisincrasie specifiche negli altri comparti:
al di là del fatto che tutti supportino le opengl (o un subset delle api opengl), dubito che uno stesso codice scritto su Linux compili su target Windows, BeOS, Mac OSX e SkyOS senza richidere nessunissimo problema o aggiustamento : se si vuole che un singolo source tree compili su più piattaforme tra loro diverse, molto probabilmente occorrerà integrare segmenti di code path specifici , che quindi richiedono lavoro aggiuntivo

appunto, SE si vuole ;)
è qui il punto, spesso lo sviluppo di un gioco su un numero di "piattaforme" elevato è quello che si vorrebbe evitare o quantomeno minimizzare: perchè sostanzialmente equivale a dover frammentare e moltiplicare il lavoro richiesto al team di sviluppo prima e a quelli di test e supporto, dopo.
Anche se molte delle piattaforme del mondo informatico condividono delle API che qualche consorzio ha dichiarato standard apposta per ridurre lo sforzo richiesto al porting di un' applicazione, ognuna mantiene peculiarità e idisincrasie specifiche negli altri comparti:
al di là del fatto che tutti supportino le opengl (o un subset delle api opengl), dubito che uno stesso codice scritto su Linux compili su target Windows, BeOS, Mac OSX e SkyOS senza richidere nessunissimo problema o aggiustamento : se si vuole che un singolo source tree compili su più piattaforme tra loro diverse, molto probabilmente occorrerà integrare segmenti di code path specifici , che quindi richiedono lavoro aggiuntivo
sulla parte legata al codice OGL non cambia niente! al massimo hai un paio di funzioni specifiche per la piattaforma, ma non è difficile il porting su altre piattaforme! quello che cambia è la gestione della finestra (e annessi e connessi) più che altro... ma direi che ormai è un lavoro quasi banale! se il SW è progettato bene (cioè separando la parte multipiattaforma dal resto) il porting non è per niente dispendioso da fare! il risultato è che con poco lavoro in più hai la possibilità di vedere il tuo SW girare più di una piattaforma!

ps. io l'ho fatto

si ma bjt2 ha detto che le dx sono già a un livello più alto in partenza! il che significa un pò di potere in meno..
No, significa che in partenza non devi reinventarti la ruota per fare delle cose che comunque ti servono.
comunque mi devi dare ragione sul fatto della multipiattaforma! lì ti scordi di essere più produttivo con dx!
Semplicemente perché non esiste un porting delle DirectX per piattaforme diverse da Windows.
il discorso wine-cedega non esiste! si tratta di emulazione, che è molto diverso!
Non so se ci sei o ci fai. :rolleyes:

Il punto è che wine e Cedega permettono già di "convogliare" le chiamate alle API DirectX di applicazioni e giochi, verso le API OpenGL.
In soldoni questo significa che hanno già (e lo usano) il know-how necessario per poter realizzare tranquillamente delle librerie DirectX per Linux: basta prendere il codice già scritto, e metterlo sotto forma di libreria.

No, significa che in partenza non devi reinventarti la ruota per fare delle cose che comunque ti servono.
per questo ci sono i framework! e sono anche fatti bene! se invece vuoi reinventare la ruota a modo tuo usi opengl!
Semplicemente perché non esiste un porting delle DirectX per piattaforme diverse da Windows.
è un difetto delle dx!
Non so se ci sei o ci fai. :rolleyes:

Il punto è che wine e Cedega permettono già di "convogliare" le chiamate alle API DirectX di applicazioni e giochi, verso le API OpenGL.
In soldoni questo significa che hanno già (e lo usano) il know-how necessario per poter realizzare tranquillamente delle librerie DirectX per Linux: basta prendere il codice già scritto, e metterlo sotto forma di libreria.
un'implementazione risultata da un pesante lavoro di reverse engineering richiede moOolto tempo e quasi sempre da risultati un pò inferiori all'implementazione originale! ripeto che la libreria è di MS e sarebbe compito di MS portarla su altre piattaforme (ovvio che non conviene)! renderebbero le loro librerie più appetibili!

In soldoni questo significa che hanno già (e lo usano) il know-how necessario per poter realizzare tranquillamente delle librerie DirectX per Linux: basta prendere il codice già scritto, e metterlo sotto forma di libreria.

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.

@jappilas:
dimenticavo... visto che siamo in tema (a giudicare dal titolo della discussione).. se usi le librerie QGL di QT hai esattamente lo stesso codice che può essere compilato senza il minimo sforzo sulle piattaforme supportate da QT!

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.
si tratta di accordi con i produttori di giochi secondo me! non spiego altrimenti il perchè si sono sempre ostinati a fare giochi in dx anche all'inizio quando erano nettamente inferiori! solo da pochi anni ha senso!

ripeto che la libreria è di MS e sarebbe compito di MS portarla su altre piattaforme (ovvio che non conviene)! renderebbero le loro librerie più appetibili!

Naaaaa... Se hanno reinventato la ruota ci manca pure che perdevano tempo e soldi a renderla multipiattaforma (quando opengl esisteva gia' ed era gia' multipiattafroma).
Secondo me, o usava pure MS Opengl, oppure hanno avuto un altro motivo (non so se tecnico o di opportunita') per creare directX. La mia domanda di prima e' sempre aperta :)

ok una possibile risposba l'ho gia' avuta ;)

si tratta di accordi con i produttori di giochi secondo me! non spiego altrimenti il perchè si sono sempre ostinati a fare giochi in dx anche all'inizio quando erano nettamente inferiori! solo da pochi anni ha senso!

Ma se cosi' fosse, non vedo il vantaggio che MS ne puo' trarre. Parlo di vantaggio dal momento che penso avrebbero fatto prima ad implementare OpenGL per Windows invece che scrivere nuove librerie "from scratch", con tutto quello che comporta (tempo soldi e scarse prestazioni iniziali rispetto ai 'concorrenti').

ok una possibile risposba l'ho gia' avuta ;)
un altro motivo è che su OGL non hanno abbastanza potere! sarebbe stato scomodo dipendere in un certo senso dai nemici! soprattutto in vista di creare un'interfaccia 3d nel proprio sistema operativo!

un altro motivo è che su OGL non hanno abbastanza potere! sarebbe stato scomodo dipendere in un certo senso dai nemici! soprattutto in vista di creare un'interfaccia 3d nel proprio sistema operativo!

Questo mi persuade di piu' ;) Pero' penso, non poteva MS entrare a far parte attivamente dello sviluppo di OpenGL? Perche' guardare sempre tutti come 'nemici'? Stiamo parlando in fondo di librerie gratuite...

Ma se cosi' fosse, non vedo il vantaggio che MS ne puo' trarre. Parlo di vantaggio dal momento che penso avrebbero fatto prima ad implementare OpenGL per Windows invece che scrivere nuove librerie "from scratch", con tutto quello che comporta (tempo soldi e scarse prestazioni iniziali rispetto ai 'concorrenti').
si può fare anche questa domanda allora: che senso aveva introdurre un nuovo formato di dvd quando ce n'era già uno che funzionava benissimo? adesso non mi ricordo se è nato prima dvd- o dvd+.. ma CHE SENSO HA?!!

Questo mi persuade di piu' ;) Pero' penso, non poteva MS entrare a far parte attivamente dello sviluppo di OpenGL? Perche' guardare sempre tutti come 'nemici'? Stiamo parlando in fondo di librerie gratuite...
credo che MS fa parte del gruppo che siede al tavolo OGL... bisogna indagare! comunque tra "fare parte" e "essere a capo" c'è una grande differenza!

Mi quoto da solo :D

Pero' penso, non poteva MS entrare a far parte attivamente dello sviluppo di OpenGL? Perche' guardare sempre tutti come 'nemici'? Stiamo parlando in fondo di librerie gratuite...

In effetti, se si pensa che directx andranno via via a far parte integrante di windows Vista, puo' essere un modo per dire "se vuoi giocare devi usare Windows"...

Non mi sembra proprio fantainformatica... :mbe:

gli attuali membri votanti dell'ARB sono: 3Dlabs, Apple, ATI, Dell Computer, IBM, Intel, NVIDIA, SGI, and Sun Microsystems. eppure mi pareva che una volta c'era MS.. forse mi sbaglio o si è tolta dopo che dx ha preso piede!

riguardo all'ARB: Microsoft, uno dei membri fondatori, se n'è andato nel marzo del 2003

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001
In practice this means for OpenGL under Aeroglass:

OpenGL performance will be significantly reduced - perhaps as much as 50%

OpenGL on Windows will be fixed at a vanilla version of OpenGL 1.4

No extensions will be possible to expose future hardware innovations
se questo è vero l'antitrust deve intervenire!

edit: ps. mi sembra che fek da qualche altra parte aveva parlato di questo! magari lui ne sa qualcosa! però la discussione non lascia scampo! vista+opengl non vanno d'accordissimo!

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

se questo è vero l'antitrust deve intervenire!

Direi... Non per voler sempre sparare a zero su MS, ma se la vanno poroprio a cercare! :Prrr:

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.
il discorso e': se directx c'e' solo per windows e tutti le usano, tutti quelli che giocano devono usare directx e quindi windows e quindi... concludi tu...

il discorso e': se directx c'e' solo per windows e tutti le usano, tutti quelli che giocano devono usare directx e quindi windows e quindi... concludi tu...
ultravero!

il discorso e': se directx c'e' solo per windows e tutti le usano, tutti quelli che giocano devono usare directx e quindi windows e quindi... concludi tu...

Beh e' lo stesso discorso che ho fatto parlando di 'fantainformatica' nel precedente post.
Evdentemente non sono il solo a pensarla cosi'.

Cmq, mi sa che stiamo andando lentamente in OT... :D

Questo mi persuade di piu' ;) Pero' penso, non poteva MS entrare a far parte attivamente dello sviluppo di OpenGL? Perche' guardare sempre tutti come 'nemici'? Stiamo parlando in fondo di librerie gratuite...
ci sono consorzi che sono nati con lo scopo di mantenere librerie/specifiche/software gratuiti e multiplatform, non si fanno corrompere facilmente... o almeno non per pochi soldi :O

Cmq, mi sa che stiamo andando lentamente in OT... :D
si stiamo andando fuori.. ma non troppo, visto che le librerie QGL sono coinvolte in questa cosa e fanno parte delle QT su cui si basano le librerie di KDE! in un certo senso è un ostacolo a usare queste librerie (tra l'altro molto comode) in win! e poi tutti i programmi KDE che lavorano sul 3D sarebbero svantaggiati!

@jappilas:
dimenticavo... visto che siamo in tema (a giudicare dal titolo della discussione).. se usi le librerie QGL di QT hai esattamente lo stesso codice che può essere compilato senza il minimo sforzo sulle piattaforme supportate da QT!
questo perchè QGL si occuperanno proprio di attuare un' astrazione da ciò che sta sotto ;)
comunque, non mi riferivo al fatto che le chiamate Opengl variassero da una piattaforma all' altra (cosa che di solito non sussiste -e meno male- a maggior ragione usando framework multipiattaforma di livello ancora più alto
)
mi riferivo alle peculiarità che di solito ogni piattaforma mantiene negli altri comparti che non siano quello grafico
Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.
qui bisognerebbe tornare indietro nel tempo, all' epoca in cui Microsoft avviava e portava avanti i progetti Talisman, poi defunto, e Farenheit , e pensare perchè nel secondo, MS e SGI abbiano per un perido collaborato per la realizzazione di un nuovo set di librerie e API per grafica 2D e 3D

questo perchè QGL si occuperanno proprio di attuare un' astrazione da ciò che sta sotto ;)
comunque, non mi riferivo al fatto che le chiamate Opengl variassero da una piattaforma all' altra (cosa che di solito non sussiste -e meno male- a maggior ragione usando framework multipiattaforma di livello ancora più alto
)
mi riferivo alle peculiarità che di solito ogni piattaforma mantiene negli altri comparti che non siano quello grafico
senza dubbio è come dici per QGL.. ma dimentichi che OpenGL già astrae la piattaforma a differenza di DX! certo non è un'astrazione completa, ma rende estremamente più facile la costruzione di un framework multipiattaforma completo!
qui bisognerebbe tornare indietro nel tempo, all' epoca in cui Microsoft avviava e portava avanti i progetti Talisman, poi defunto, e Farenheit , e pensare perchè nel secondo, MS e SGI abbiano per un perido collaborato per la realizzazione di un nuovo set di librerie e API per grafica 2D e 3D
il problema è che OGL esisteva già! è stata MS a creare qualcosa di totalmente diverso! poteva sin dall'inizio cercare di facilitare un set di API sopra ogl e dx! penso che il progetto Farenheit sia stato solo un modo per dire: almeno ci abbiamo provato! ma non c'è mai stato un reale tentativo da parte MS! lo dimostra il fatto che dal 2003 non fa più parte dell'ARB!

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

se questo è vero l'antitrust deve intervenire!

se ne è parlato anche qui, in svariati thread , riassumo le conclusioni :
il supporto a opengl che MS offrirà in Vista sarà anche migliore di quello attualmente offerto dalla stessa MS nell' attuale Win XP, in cui opengl di default gira interamente via SW a meno di installare un driver accelerato
di base, opengl in Vista subirà lo stesso trattamento riservato a DirectX 9 e precedenti, cioè esecuzione tramite "wrapper"
per avere accelerazione completa (come estensioni attivabili) e più efficiente si potrà ancora ricorrere a un driver (ICD) di terze parti (produttore dell' HW) come si fa già ora normalmente
quindi, l' antitrust non avrebbe ragione di intervenire

se ne è parlato anche qui, in svariati thread , riassumo le conclusioni :
il supporto a opengl che MS offrirà in Vista sarà anche migliore di quello attualmente offerto dalla stessa MS nell' attuaLE Win XP,
in cui opengl di default gira interamente via SW a meno di installare un driver accelerato
di base, opengl in Vista subirà lo stesso trattamento riservato a DirectX 9 e precedenti, cioè esecuzione tramite ""wrapper"
per avere accelerazione completa (come estensioni attivabili) e più efficiente si potrà ancora ricorrere a un driver (ICD) di terze parti (produttore dell' HW) come si fa già ora normalmente
quindi, l' antitrust non ha ragione di intervenire, anzi
devi leggere http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001
pare che non sia esattamente come dici (sul driver ICD)!
ma poi chi non ha un driver con accelerazione3d per opengl oggigiorno? il problema è che domani non si potrà fare a quanto ho capito! e poi la storia che non supportano ogl2 puzza!

pensate a programmi fatti in QGL, oppure a Maya o anche a OpenOffice (che usa ogl)! le ripercussioni che ha questa cosa sono devastanti! l'antitrust avrà il suo da fare!

pensate a programmi fatti in QGL, oppure a Maya o anche a OpenOffice (che usa ogl)! le ripercussioni che ha questa cosa sono devastanti! l'antitrust avrà il suo da fare!
mi autoquoto perchè leggendo si dice che solo l'intefaccia aero non va con i driver opengl! però se vuoi l'interfaccia aero al momento non puoi avere driver con accelerazione3d per opengl! comunque è una penalizzazione!

il problema è che OGL esisteva già! è stata MS a creare qualcosa di totalmente diverso! poteva sin dall'inizio cercare di facilitare un set di API sopra ogl e dx! penso che il progetto Farenheit sia stato solo un modo per dire: almeno ci abbiamo provato! ma non c'è mai stato un reale tentativo da parte MS! lo dimostra il fatto che dal 2003 non fa più parte dell'ARB!
all' epoca (13 anni fa uno più uno meno) c' era un OS da dotare di funzioni multimediali che affiancassero, le GDI per quanto concerne la grafica, e rimpiazzassero il vetusto wave mapper per la parte sonora, dando accesso "diretto" all' HW di competenza: probabilmente se una o l' altra funzione fosse stata in partenza, più evoluta (concepita in modo più moderno) di quello che era, la sua sostituzione sarebbe stata rinviata...
invece ricordo directX nascere come blocco compatto di librerie... e quando una sw house o un programmatore si trova a dover far uscire un' intera suite di librerie e api, la cosa più logica da fare è renderla consistente al proprio interno e con il sistema operativo (a maggior ragione se componenti di esse dovranno accedere direttamente alle periferiche), tanto più che gli ambiti a cui vanno a offrire supporto (ad es il sonoro o la gestione dell'input da joystick) non è coperto da specifici standard trasversali
ora, ci si rende conto che perchè la suite di librerie sia completa, mancano alcuni componenti: soprattutto manca quello relativa alla grafica tridimensionale, e di non avere sufficiente know how per crearla dal nullla, collaborare con una società rinomata proprio nella visualizzazione 3d e per aver creato la prima implementazione di una API che tutto il mondo (meglio, tutto il mondo della visualizzazione 3d professionale) ha poi preso come standard, era la mossa più logica da fare

Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.

Guarda che Microsoft usava OpenGL prima di DirectX. Le DirectX sono state imposte solo da Windows NT in poi. E, tra le altre cose, non sono state neanche create da Microsoft, ma acquisite da una società che è stata comprata. Microsoft ne ha solo portato avanti lo sviluppo. Dall'introduzione di DirectX sotto Windows, Microsoft ha cessato di supportare (e distribuire) OpenGL sotto Windows.

ora, ci si rende conto che perchè la suite di librerie sia completa, mancano alcuni componenti: soprattutto manca quello relativa alla grafica tridimensionale, e di non avere sufficiente know how per crearla dal nullla, collaborare con una società rinomata proprio nella visualizzazione 3d e per aver creato la prima implementazione di una API che tutto il mondo (meglio, tutto il mondo della visualizzazione 3d professionale) ha poi preso come standard, era la mossa più logica da fare
avrebbero potuto fare questo partendo da opengl! perchè reinventare la ruota? e poi sta cosa di unificare le librerie è stata fatta più o meno recentemente da opengl.. ci sono openml, openal e openil se non sbaglio! perchè distaccarsi così tanto dagli standard già esistenti (parlo di d3d in particolare)?

edit: tra l'altro non è faticoso come dici utilizzare librerie eterogenee per fare cose eterogenee! chi sviluppa in linux lo sa bene! a volte è addirittura meglio poter scegliere la libreria che più si adatta agli scopi!

Comunque se vi interessano le dispute fra OpenGL e DirectX, leggete qui... Guardate che schifo...
http://www.vcnet.com/bms/features/3d.html

Leggete bene mi raccomando.

Comunque se vi interessano le dispute fra OpenGL e DirectX, leggete qui... Guardate che schifo...
http://www.vcnet.com/bms/features/3d.html

Leggete bene mi raccomando.
ho appena letto questo:

GL's interface is procedural: You perform operations by calling gl
functions to pass vertex data and specify primitives.

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

D3D's interface is by execute buffers: You build a structure
containing vertex data and commands, and pass the entire thing with a
single call. On the surface, this appears to be an efficiency
improvement for D3D, because it gets rid of a lot of procedure call
overhead. In reality, it is a gigantic pain-in-the-ass.

(pseudo code, and incomplete)
v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

domanda 1: sono ancora così le d3d?
domanda 2: se sì... dov'è che si risparmia tempo?

Semplicemente perché non esiste un porting delle DirectX per piattaforme diverse da Windows.
"semplicemente"?
Dici poco, tu...
Dentro quel "semplicemente" é racchiuso il core-business di MS... :D



Sarebbe troppo bello pensare se MS avesse potuto usare dall'inizio OpenGl invece di reinventare tutto come al solito e creare directX?
Chiedo: era il solito problema di opportunita' (tecnica "abbraccia ed espandi") oppure un problema tecnico? Escludo un vantaggio economico diretto di MS, visto che le directX (come i corrispondenti tool di sviluppo) sono sempre state closed source ma gratis.
MS poteva benissimo usare OpenGL, e la motivazione per cui hanno imposto le DirectX é proprio di carattere economico: tra l'altro é anche ovvio, visto che MS non é un'associazione di beneficenza ma una società a scopo di lucro.
Il fatto di imporre le DirectX anche regalandole, ha garantito che i videogiochi non fossero facilmente portabili su altre piattaforme, facendo rimanere Windows la piattaforma standard per il PC di casa, che in molti casi, specie quando usato da bambini/adolescenti, é usato per far girare software da ufficio/browsing/email E SOPRATTUTTO videogiochi.
Siccome quei software da ufficio/browsing/email ci sono anche su Mac e Linux, se i videogiochi fossero facilmente portabili su Mac e Linux (quelli OpenGL infatti sono stati portati), quegli utenti casalinghi non sarebbero più costretti a rimanere legati a Windows.
E siccome quella fascia di utenza é *ENORME*, ne va del business di MS.

Infatti se noti adesso che i Mac sono passati a Intel, i Mac-users sono tutti contenti perché finalmente (forse) tra poco potranno installare Windows in dual-boot e USARE I VIDEOGIOCHI, per quanto riguarda tutto il resto sono già a posto con OS-X.

Comunque se vi interessano le dispute fra OpenGL e DirectX, leggete qui... Guardate che schifo...
http://www.vcnet.com/bms/features/3d.html

Leggete bene mi raccomando.
letto tutto or ora ;)

ma hai visto la data ? last revised: 30 August 1998
alcune considerazioni restano valide (e mi chiariscono alcuni dettagli che il mio cervello aveva già eliminato dal buffer) , però in 7 anni e mezzo ne è passata di acqua sotto i ponti...

ho appena letto questo:

GL's interface is procedural: You perform operations by calling gl
functions to pass vertex data and specify primitives.

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

D3D's interface is by execute buffers: You build a structure
containing vertex data and commands, and pass the entire thing with a
single call. On the surface, this appears to be an efficiency
improvement for D3D, because it gets rid of a lot of procedure call
overhead. In reality, it is a gigantic pain-in-the-ass.

(pseudo code, and incomplete)
v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

domanda 1: sono ancora così le d3d?
domanda 2: se sì... dov'è che si risparmia tempo?

Si risparmia molto tempo nelle chiamate. Chiamare le funzioni costa del tempo. Con l'approccio OpenGL che hai visto, usi 3 chiamate a glVertex(). Nell'approccio Direct3D invece riempi i valori dei vertici in un vertex buffer e lanci una sola chiamata di funzione.
Inoltre, proprio perchè i valori vengono messi dentro un'array, ci sono piu' possibilità di ottimizzazione laddove piu' chiamate singole sarebbero piu' generiche.
Per esempio, disegnare un poligono di 20 facce richiede almeno 22 chiamate di funzione. 20 per i vertici e 2 per glBegin() e glEnd(). Inoltre aggiungi che molte volte hai bisogno delle informazioni per il colore (altre 20 chiamate). Aggiungi che magari ti servono le normali alla superficie... Altre chiamate... Come vedi è facile che il numero di chiamate si moltiplica rispetto al numero di vertici...
Tuttavia anche OpenGL adesso implementa dei tipi di array per ottenere la stessa cosa. I vertex arrays, i color arrays, ecc. Ce n'è un tipo per ogni uso. Non solo vertici quindi, ma anche normali alla superficie, o le coordinate per le texture.
Si possono disegnare tutti i vertici dentro un array con una sola funzione. Inoltre le funzioni per dereferenziare un array (per esempio di vertici) non devono essere inserite fra glBegin() e glEnd() (altro risparmio di risorse). Tali array si attivano con la funzione glEnableClientState() passandogli come parametro la costante che identifica il tipo di array da usare, come ad esempio GL_VERTEX_ARRAY oppure GL_NORMAL_ARRAY oppure ancora GL_TEXTURE_COORD_ARRAY.
Non solo!!! OpenGL include anche le Display Lists, che sono piu' o meno la stessa cosa di quello che ho detto adesso, ma garantiscono un controllo ancora piu' potente e ottimizzato. Infatti le display list sono delle vere e proprie "cache di oggetti".

EDIT:

I LOVE:
http://www.opengl.org/images_global/opengl_logo.jpg

:cool:

Si risparmia molto tempo nelle chiamate. Chiamare le funzioni costa del tempo. Con l'approccio OpenGL che hai visto, usi 3 chiamate a glVertex(). Nell'approccio Direct3D invece riempi i valori dei vertici in un vertex buffer e lanci una sola chiamata di funzione.
Inoltre, proprio perchè i valori vengono messi dentro un'array, ci sono piu' possibilità di ottimizzazione laddove piu' chiamate singole sarebbero piu' generiche.
Per esempio, disegnare un poligono di 20 facce richiede almeno 22 chiamate di funzione. 20 per i vertici e 2 per glBegin() e glEnd(). Inoltre aggiungi che molte volte hai bisogno delle informazioni per il colore (altre 20 chiamate). Aggiungi che magari ti servono le normali alla superficie... Altre chiamate... Come vedi è facile che il numero di chiamate si moltiplica rispetto al numero di vertici...
Tuttavia anche OpenGL adesso implementa dei tipi di array per ottenere la stessa cosa. I vertex arrays, i color arrays, ecc. Ce n'è un tipo per ogni uso. Non solo vertici quindi, ma anche normali alla superficie, o le coordinate per le texture.
Si possono disegnare tutti i vertici dentro un array con una sola funzione. Inoltre le funzioni per dereferenziare un array (per esempio di vertici) non devono essere inserite fra glBegin() e glEnd() (altro risparmio di risorse). Tali array si attivano con la funzione glEnableClientState() passandogli come parametro la costante che identifica il tipo di array da usare, come ad esempio GL_VERTEX_ARRAY oppure GL_NORMAL_ARRAY oppure ancora GL_TEXTURE_COORD_ARRAY.
Non solo!!! OpenGL include anche le Display Lists, che sono piu' o meno la stessa cosa di quello che ho detto adesso, ma garantiscono un controllo ancora piu' potente e ottimizzato. Infatti le display list sono delle vere e proprie "cache di oggetti".
beh se é per questo il problema con le directx é facilmente risolvibile: ti scrivi delle macro o delle funzioni che a loro volta chiamano quelle dell'API, lo fai una volta per tutte, e non ci son problemi.

devi leggere http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001
pare che non sia esattamente come dici (sul driver ICD)!
ho presente, e ho constatato il tenore di praticamente tutte le pagine che google restituisce cercando "vista opengl"
e ti chiedo scusa se preferisco dare retta a chi ne sa più di me (persone , anche qui del forum, professionisti nel settore della grafica e dei giochi) e parla con una parvenza di obiettività, piuttosto che ad altri siti, forum, la stessa wikipedia, in cui il FUD, la disinformazione e soprattutto l' avversione per microsoft la fanno da padrone

ho perso tempo a spulciare il forum alla ricerca di alcuni thread di qualche mese fa ma non li ho trovati, devono essere stati rimossi dal database: peccato, c'erano degli interventi interessanti :(
ma poi chi non ha un driver con accelerazione3d per opengl oggigiorno? il problema è che domani non si potrà fare a quanto ho capito! e poi la storia che non supportano ogl2 puzza!
in sostanza sarà la libreria fornita da MS che verrà eseguita come wrapper sulle windows graphics foundation (DX 10) a non supportare opengl >1.5, ma non verrà impedito di installare un ICD di nvidia (per esempio) che supporti le 2.0...
io ricordo questo, poi ci puoi credere o meno

beh se é per questo il problema con le directx é facilmente risolvibile: ti scrivi delle macro o delle funzioni che a loro volta chiamano quelle dell'API, lo fai una volta per tutte, e non ci son problemi.

Vai a complicare solo la leggibilità, la pulizia del codice senza aggiungere niente (se non aggiungere una chiamata di macro in piu).
Sempre 20 chiamate fai, indipendentemente dalla macro o no.
Una macro usata per chiamare funzioni di libreria comunque non risparmia l'overhead di una chiamata di funzione. Inoltre i vertex arrays e tutti gli altri non sono normali array del linguaggio di programmazione. Sono delle complesse strutture dati che consentono di ottimizzare il dereferenziamento e il rendering. A maggior ragione le display list, che semplificano drammaticamente la creazione e la gestione di tali oggetti.
L'espansione in linea delle macro è molto efficiente per operazioni elementari. Si usano in rari casi per migliorare la sintassi di una qualche chiamata di funzione o uniformarla a qualcos'altro. Ma non ti esonera dall'overhead della chiamata.

ho presente, e ho constatato il tenore di praticamente tutte le pagine che google restituisce cercando "vista opengl"
e ti chiedo scusa se preferisco dare retta a chi ne sa più di me (persone , anche qui del forum, professionisti nel settore della grafica e dei giochi) e parla con una parvenza di obiettività, piuttosto che ad altri siti, forum, la stessa wikipedia, in cui il FUD, la disinformazione e soprattutto l' avversione per microsoft regnano sovrani

ho perso tempo a spulciare il forum alla ricerca di alcuni thread di qualche mese fa ma non li ho trovati, devono essere stati rimossi dal database: peccato, c'erano degli interventi interessanti :(

in sostanza sarà la libreria fornita da MS che verrà eseguita come wrapper sulle windows graphics foundation (DX 10) a non supportare opengl >1.5, ma non verrà impedito di installare un ICD di nvidia (per esempio) che supporti le 2.0...
io ricordo questo, poi ci puoi credere o meno
guarda che quello è un forum ufficiale!
This information came from the OpenGL BOF held at Siggraph 2005 in LA this last Wednesday evening. This was confirmed at the BOF by NVIDIA, ATI and us (3Dlabs).

As soon as an ICD is loaded the composited desktop is turned off on Windows Vista. If you want the composited desktop Aeroglass experience, you will need to make your application go through Microsoft's OpenGL implementation, which is layered on top of DirectX. As pointed out earlier, this layering can have performance implications. Their implementation supports OpenGL version 1.4 only, without extension support.

We believe it possible to provide an ICD with full composited desktop support while adhering to the stability and security requirements in Windows Vista. But we need Microsoft's help in doing so.
è tutto nelle mani di MS insomma! io al contrario di te leggo con le pinze i commenti su questo forum! anche perchè oltre agli anti-MS ci sono gli adeptiMS! tutti e due non sono bella gente! io mi limito a cercare di essere oggettivo, e questo negli ultimi anni mi ha portato a pensare che MS sta rovinando la libera concorrenza a danno del progresso! è solo la mia opinione comunque!

Vai a complicare solo la leggibilità, la pulizia del codice senza aggiungere niente (se non aggiungere una chiamata di macro in piu).
Sempre 20 chiamate fai, indipendentemente dalla macro o no.
Una macro usata per chiamare funzioni di libreria comunque non risparmia l'overhead di una chiamata di funzione. Inoltre i vertex arrays e tutti gli altri non sono normali array del linguaggio di programmazione. Sono delle complesse strutture dati che consentono di ottimizzare il dereferenziamento e il rendering. A maggior ragione le display list, che semplificano drammaticamente la creazione e la gestione di tali oggetti.
L'espansione in linea delle macro è molto efficiente per operazioni elementari. Si usano in rari casi per migliorare la sintassi di una qualche chiamata di funzione o uniformarla a qualcos'altro. Ma non ti esonera dall'overhead della chiamata.
a parte tutti questi discorsi sulla carta... nessuno ha mai dimostrato senza ombra di dubbio che a parità di trattamento d3d sia più veloce di ogl!

a parte tutti questi discorsi sulla carta... nessuno ha mai dimostrato senza ombra di dubbio che a parità di trattamento d3d sia più veloce di ogl!

Risparmiarsi n chiamate per m vertici non sono discorsi sulla carta. Sono la base fondamentale di qualsiasi tipo di programmazione. E negli ambiti piu' specifici, da adito a ciò che è la teoria della complessità computazionale. Disciplina che mediante opportuni modelli matematici permettono di descrivere analiticamente i tempi di complessità asintotica computazionale e spaziale.
Non puoi saper fare niente di ottimizzazione se non impari a fare lo stesso riducendo almeno il numero di chiamate. Se non hai capito queste cose, significa che non hai capito niente della programmazione. Il bello che molti si definiscono programmatori senza neanche capire il concetto di complessità computazionale elementare. Non è possibile.

Risparmiarsi n chiamate per m vertici non sono discorsi sulla carta. Sono la base fondamentale di qualsiasi tipo di programmazione. E negli ambiti piu' specifici, da adito a ciò che è la teoria della complessità computazionale. Disciplina che mediante opportuni modelli matematici permettono di descrivere analiticamente i tempi di complessità asintotica computazionale e spaziale.
Non puoi saper fare niente di ottimizzazione se non impari a fare lo stesso riducendo almeno il numero di chiamate. Se non hai capito queste cose, significa che non hai capito niente della programmazione. Il bello che molti si definiscono programmatori senza neanche capire il concetto di complessità computazionale elementare. Non è possibile.
no io conosco il concetto di complessità computazionale! era nel programma di informatica3! il problema è che anche opengl può gestire array e poi ci sono le array list! e poi non ho trovato una dimostrazione pratica del fatto che l'approccio di d3d sia più veloce alla fine! per quel che ne so io l'unica funzione invocata da d3d potrebbe avere una complessità asintotica maggiore di 10 funzioni opengl! insomma senza dati la carta non serve a niente! e non sto dicendo che quello che hai detto è falso! dico solo che non ho i dati per valutarlo!

Le display lists e gli array ti consentono di mettere quei dati direttamente sulla VRAM (se ce n'è), a discrezione del driver, in modo che la chiamata a quella funzione sia quasi istantanea. C'è da dire che le ultime directX consentono un controllo più fine: per i vari array si può specificare dove il driver può o non può allocarli (memoria di sistema, VRAM ecc...), in modo da ottimizzare le risorse (questo vale anche per le texture map ecc...). Non mi ricordo se lo può fare anche OGL...

no io conosco il concetto di complessità computazionale! era nel programma di informatica3! il problema è che anche opengl può gestire array e poi ci sono le array list!


E io che minchia ho detto fino ad adesso? :D Quale dovrebbe essere il problema?


e poi non ho trovato una dimostrazione pratica del fatto che l'approccio di d3d sia più veloce alla fine! per quel che ne so io l'unica funzione invocata da d3d potrebbe avere una complessità asintotica maggiore di 10 funzioni opengl! insomma senza dati la carta non serve a niente! e non sto dicendo che quello che hai detto è falso! dico solo che non ho i dati per valutarlo!

Ma infatti ogni metodo è scorretto valutarlo con l'altra libreria. Ogni libreria ha le sue idiosincrasie, non ha per niente senso confrontare due sistemi su due librerie diverse. Non hai trovato niente perchè non c'è nessun modo se non la sperimentazione empirica. Ma comunque se gli approcci sono differenti, essendo due librerie grafiche diverse, il confronto "diretto" fra funzionalità non ha senso. Nello stesso tuo link sta scritto che quel metodo è un "pain in the ass". Cioè un modo molto elegante di dire che in quella versione di Direct3D è molto inefficiente. Le cose sono sicuramente molto cambiate oggi.

Le display lists e gli array ti consentono di mettere quei dati direttamente sulla VRAM (se ce n'è), a discrezione del driver, in modo che la chiamata a quella funzione sia quasi istantanea. C'è da dire che le ultime directX consentono un controllo più fine: per i vari array si può specificare dove il driver può o non può allocarli (memoria di sistema, VRAM ecc...), in modo da ottimizzare le risorse (questo vale anche per le texture map ecc...). Non mi ricordo se lo può fare anche OGL...

Questo è compito delle OpenGL Extensions, non della libreria in se, perche dipende dalla scheda e dal driver, nell'ottica di OpenGL. OpenGL fornisce solo i contenuti puri per la generazione di grafica.

Ragazzi, oggi al lavoro ho provato a installare KDE 3.4 sulla stessa macchina sulla quale, anni fa, installi KDE 2.x La macchina è un P3 500, 8GB di HD e 128MB di RAM. Con mia grande sorpresa devo dire che KDE funziona bene anche lì... :)
Ormai è passato molto tempo da quando provai KDE 2.x, eppure mi ricordo benissimo che la macchina era molto lenta, mentre quest'oggi ho avuto una macchina adeguata a lavori non troppo pesanti.
C'è da dire però che all'epoca installai KDE su una RedHat 7.2 (distribuzione notoriamente un po' "avara" di risorse), mentre oggi su una Debian Sarge... non so quanto questo possa fare la differenza (entrambe le distribuzioni non sono state molto ottimizzate, dato che all'epoca ero poco pratico).

Sono migliorate tantissimo anche le applicazioni a corredo, in particolare Konqueror si è comportato molto meglio di quello che pensavo.

Rinnovo i complimentoni a tutto lo staff di KDE... anche se il successo di KDE per Windows lo vedo molto difficile da raggiungere! :stordita:

Ciao. :)

Vai a complicare solo la leggibilità, la pulizia del codice senza aggiungere niente (se non aggiungere una chiamata di macro in piu).
Sempre 20 chiamate fai, indipendentemente dalla macro o no.
Una macro usata per chiamare funzioni di libreria comunque non risparmia l'overhead di una chiamata di funzione. Inoltre i vertex arrays e tutti gli altri non sono normali array del linguaggio di programmazione. Sono delle complesse strutture dati che consentono di ottimizzare il dereferenziamento e il rendering. A maggior ragione le display list, che semplificano drammaticamente la creazione e la gestione di tali oggetti.
L'espansione in linea delle macro è molto efficiente per operazioni elementari. Si usano in rari casi per migliorare la sintassi di una qualche chiamata di funzione o uniformarla a qualcos'altro. Ma non ti esonera dall'overhead della chiamata.
Ah certo é vero, avevo capito male io:
pensavo ti riferissi alla pulizia del codice! :D
Però devo dirti che fare delle piccole macro aiuta atenere il codice pulito, se non ne abusi, in particolare aiutano a tenerlo pulito quando devi scrivere più volte una trafila di molte chiamate a funzione che son sempre le stesse, come in questo caso.
La pulizia del codice ne guadagna parecchio!!
Per quanto riguarda il discorso overhead hai ragione a dire che con o senza macro non cambia niente, però devo dire che i giochi DirectX mi sembra abbiano buone prestazioni, paragonabili a quelli OpenGL, quindi complessivamente non mi semba che le DirectX abbiano problemi di "pesantezza"...
:mbe:

Per quanto riguarda il discorso overhead hai ragione a dire che con o senza macro non cambia niente, però devo dire che i giochi DirectX mi sembra abbiano buone prestazioni, paragonabili a quelli OpenGL, quindi complessivamente non mi semba che le DirectX abbiano problemi di "pesantezza"...
:mbe:
forse intendeva dire il contrario! e cioè che ogl sono più lente in teoria perchè chiamano più volte delle funzioni!

forse intendeva dire il contrario! e cioè che ogl sono più lente in teoria perchè chiamano più volte delle funzioni!
:sbonk:

il discorso wine-cedega non esiste! si tratta di emulazione, che è molto diverso!

Permettimi di dissentire..WineIsNotAnEmulator..lo dice anche il nome heeh :D
Comunque avete ragione entrambi..sia te che cdimauro. Lui per il fatto che le chiamate direct x sono conosciute (certo..non si sa come fanno a farlo..ma l'importante è sapere cosa fanno per poi poter fare l'equivalente della chiamata in opengl..è così che funziona cedega ;) )...ma è anche vero che il fatto opengl essendo una libreria più di basso livello consente una resa "migliore" con l'hw..con il contro della minor astrazione (contro per niente trascurabile purtroppo.. :muro: ).

La cosa che non mi va proprio giù è il fatto che opengl è praticamente destinato a morire se la microsoft farà quello che vuol fare..speriamo bene. :cry:

La cosa che non mi va proprio giù è il fatto che opengl è praticamente destinato a morire se la microsoft farà quello che vuol fare..speriamo bene. :cry:

mi autoquoto perchè ho appena letto quello che ha detto jappilas.
Non me ne intendo molto delle ultime vicende di windows..ma voglio sperare che sia come dici tu..non possono uccidere così le opengl.
:muro:

mi autoquoto perchè ho appena letto quello che ha detto jappilas.
Non me ne intendo molto delle ultime vicende di windows..ma voglio sperare che sia come dici tu..non possono uccidere così le opengl.
:muro:
è assolutamente impossibile uccidere OpenGL! è l'unica libreria multipiattaforma! è l'unica utilizzabile con java nei sistemi embedded (almeno la maggior parte dei sistemi embedded)! è l'unica estensibile dai costruttori! è l'unica libera da interessi personali di un solo colosso! è l'unica che si usa su sistemi *nix (compreso MacOS)! va ricordato che d3d domina nei giochi windows! non è affatto vero che è lo standard nell'ambito professionale! dico solo MAYA!
Permettimi di dissentire..WineIsNotAnEmulator..lo dice anche il nome heeh
ok! wine è un layer di traduzione del codice! potrà mai essere più performante del codice stesso? nel 3d sono vitali le performance! non è questa la strada giusta! rendiamocene conto!
ma è anche vero che il fatto opengl essendo una libreria più di basso livello consente una resa "migliore" con l'hw..con il contro della minor astrazione (contro per niente trascurabile purtroppo.. ).
ho già spiegato che OpenGL va inteso come back-end per framework costruiti sopra! è molto meglio così perchè si ha sempre la possibilità di utilizzare il basso livello (cioè ogl)! è solo maggiore potenza! nessun compromesso!

ps. in sostanza è solo un fronte della battaglia MS (e alleati pagati profumatamente) contro tutti! ma credo che dx non può sostituire ogl!

ok! wine è un layer di traduzione del codice! potrà mai essere più performante del codice stesso? nel 3d sono vitali le performance! non è questa la strada giusta! rendiamocene conto!

k0nt3 e' gia' la seconda volta che spari su wine senza conoscerlo bene, ti prego di smetterla.
Wine e' GIA' piu' performante di Windows in certe cose, in altre ancora no, ma pensa che non e' nemmeno in versione stable 1.0, quindi di margini di miglioramento direi che ce sono.

http://wiki.winehq.org/BenchMark-0.9.5

k0nt3 e' gia' la seconda volta che spari su wine senza conoscerlo bene, ti prego di smetterla.
Wine e' GIA' piu' performante di Windows in certe cose, in altre ancora no, ma pensa che non e' nemmeno in versione stable 1.0, quindi di margini di miglioramento direi che ce sono.

http://wiki.winehq.org/BenchMark-0.9.5
scusami adesso cerco dove avevo trovato questa cosa e te lo faccio leggere! c'era uno sviluppatore di wine che diceva che nel 3D wine funziona bene ma non può arrivare alle performance delle dx originali! diciamo che ha detto chiaro e tondo che è solo una pezza in attesa di tempi migliori... adesso googlo

ps. non c'è dubbio che in altri ambiti possa competere! ma prendi con le pinze i bench di parte :D
pps. sono un grande fan di wine e lo aggiorno continuamente compilando i sorgenti (forza wine)

era la discussione che avevo già linkato prima!

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001
I can help, I have a 100% sure fire solution to the problem.

Over the past six months or so I've been writing a DirectX 9 compatibility layer for the WINE project. The layer basically translates DirectX calls into OpenGL calls allowing DirectX games and application to run under Linux and in theory Aeroglass should work too. (DirectX for WINE)

The compatibility layer has already been modified to use WGL instead of GLX and is already capable of running DirectX games and application under Windows replacing Microsoft's DirectX 9 Library.

Extending the idea to Windows Vista you could have good OpenGL drivers and run Aeroglass through the DirectX 9 compatibility layer, loosing a little performance for window effects but gaining 100% performance for OpenGL applications.

If anyone is interested in taking this idea any further then please send me an email. oliver_stieber@yahoo.co.uk
mi sbaglio?

scusami adesso cerco dove avevo trovato questa cosa e te lo faccio leggere! c'era uno sviluppatore di wine che diceva che nel 3D wine funziona bene ma non può arrivare alle performance delle dx originali! diciamo che ha detto chiaro e tondo che è solo una pezza in attesa di tempi migliori... adesso googlo

ps. non c'è dubbio che in altri ambiti possa competere! ma prendi con le pinze i bench di parte :D
pps. sono un grande fan di wine e lo aggiorno continuamente compilando i sorgenti (forza wine)
ok allora quando beccherai il link potremo riparlarne, per ora ci sono solo i bench postati da me che sono di parte, ma mi sembra che non facciano fatica ad ammettere quando Wine e' sotto anche di molto ad XP ;)

era la discussione che avevo già linkato prima!

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001

mi sbaglio?
beh "loosing a little performance" non mi sembra un grosso problema, cmq come puoi ben vedere dal mio link in alcune cose Wine fa gia' meglio di XP, mi aspetto degli altri miglioramenti, soprattutto quando tutta la "traduzione" sara' conclusa.

beh "loosing a little performance" non mi sembra un grosso problema, cmq come puoi ben vedere dal mio link in alcune cose Wine fa gia' meglio di XP, mi aspetto degli altri miglioramenti, soprattutto quando tutta la "traduzione" sara' conclusa.
sarà una mia interpretazione ma "loosing a little performance" detto da uno che sta pubblicizzando il progetto per il quale lavora... lo intendo come approssimato per difetto! comunque a dimostrazione dell'incompletezza dell'implementazione dai un'occhiata al passaggio da 3dmark2000 a 3dmark2001! chissà il 2006 come gira :D! ma i veri test sono quake3 e UT2004, e pur essendo in opengl perdono buone percentuali nelle prestazioni! secondo me wine può fare la pezza e anche bene, ma come soluzione definitiva non ce la vedo...
comunque sia bisogna ricordare che il progetto wine ha assunto dimensioni colossali e quello che agli inizi sembrava un'utopia comincia a dare risultati! io uso tranquillamente svariate applicazioni windows con wine (vi consiglio di provare a emulare picasa di google perchè è davvero stupefacente oppure ie6 solo per sfizio)!

sarà una mia interpretazione ma "loosing a little performance" detto da uno che sta pubblicizzando il progetto per il quale lavora... lo intendo come approssimato per difetto! comunque a dimostrazione dell'incompletezza dell'implementazione dai un'occhiata al passaggio da 3dmark2000 a 3dmark2001! chissà il 2006 come gira :D! ma i veri test sono quake3 e UT2004, e pur essendo in opengl perdono buone percentuali nelle prestazioni! secondo me wine può fare la pezza e anche bene, ma come soluzione definitiva non ce la vedo...

che sia incompleto lo so e l'ho pure scritto e poi il fatto che sia alla versione 0.9.x e' una dimostrazione ulteriore.
Vedremo chi avra' ragione alla versione 1.0 o 1.1 ;)

Paghi tu la versione opengl?

Se tu paghi io mi faccio convincere anche a fare versioni per Commodore64 :)

naaa dai per la mia povera Amiga 600 semmai che sta in un angolino a soffrire :cry:

:asd: :p

l'ho scritto sotto che ovviamente e' una questione di costi che non rientrano, non quotare solo una parte del msg per cambiarne il significato :read:

Giusto per un fatto di precisazione... ma perché OPENGL solamente? Non esiste solo quello...

Esiste anche PowerSDL, che è ben supportato ovunque.

E casomai Sawato Onizuka vuole, si informi che i giochi Amiga PowerPC al giorno d'oggi per buona parte sono conversioni SDL che è una volta che è stato portato anche per la nostra piattaforma è diventato forse il più vasto interstandard per i giochi e regge Linux, Windows, MorphOS Amiga e anche AmigaOS 4.0 (e forse anche Macintosh :rolleyes: ), ma di sicuro è lo standard più ampio accettato per le conversioni dei giochi.

Articolo su AmigaSDL

http://quantum-leap.it/default_frame.asp?id=61&lang=it

Esempio di gioco SDL portato anche per Amiga...

http://www.parallelrealities.co.uk/blobWars.php

Mentre per quanto riguarda il porting di programmi per Amiga esistono le TinyGL su MorphOS e le MiniGL su AmigaOS...

Purtroppo non c'è nessun porting completo di TUTTO OpenGL che è veramente enorme e sarebbe una fatica immane per gruppi di lavoro fatti in Amiga solo da 1 o 2 persone... :cry:

Per le interfacce grafiche tipo KDE non ci possiamo lamentare invece. Abbiamo le nostre: MUI, Reaction, ScalOS, Feelin, quindi siamo ben coperti.

che sia incompleto lo so e l'ho pure scritto e poi il fatto che sia alla versione 0.9.x e' una dimostrazione ulteriore.
Vedremo chi avra' ragione alla versione 1.0 o 1.1 ;)
spero che hai ragione te :D! ma se torniamo con i piedi per terra... in Vista le dx9 (quelle che stanno iniziando a implementare in wine) saranno comunque wrappate su dx10 o come si chiama! quindi per avere un miglioramento delle prestazioni bisognerà attendere l'implementazione di dx10 su wine! non credo sarà così immediato anche perchè mi aspetto un cambiamento radicale rispetto a dx9! ma io ho pazienza e spero che un giorno non troppo lontano sarà possibile farlo!
comunque se sei daccordo con me riguardo opengl credo che la vera soluzione sarebbe tornare alle care vecchie opengl che eravamo tutti felici e contenti! non c'è mai stato nessun motivo tecnico alla sostituzione di OpenGL! in più MS ha sempre spacciato le d3d come librerie nettamente più performanti di ogl senza peraltro che questo sia dimostrato! lo trovo squallido!

http://wiki.winehq.org/BenchMark-0.9.5

Linux: Gentoo

bhe una versione di linux che utilizzano in molti..... :sofico:

ma io ho pazienza e spero che un giorno non troppo lontano sarà possibile farlo!

si si...arriverà godot con stalmann, torwalds e raymond a braccetto..... ;)

Linux: Gentoo

bhe una versione di linux che utilizzano in molti..... :sofico:
non credo che una distro diversa possa fare chissa' quali differenze... poi credo che quello che conti sia anche il kernel usato e la versione dei driver nvidia...

spero che hai ragione te :D! ma se torniamo con i piedi per terra... in Vista le dx9 (quelle che stanno iniziando a implementare in wine) saranno comunque wrappate su dx10 o come si chiama! quindi per avere un miglioramento delle prestazioni bisognerà attendere l'implementazione di dx10 su wine! non credo sarà così immediato anche perchè mi aspetto un cambiamento radicale rispetto a dx9! ma io ho pazienza e spero che un giorno non troppo lontano sarà possibile farlo!
comunque se sei daccordo con me riguardo opengl credo che la vera soluzione sarebbe tornare alle care vecchie opengl che eravamo tutti felici e contenti! non c'è mai stato nessun motivo tecnico alla sostituzione di OpenGL! in più MS ha sempre spacciato le d3d come librerie nettamente più performanti di ogl senza peraltro che questo sia dimostrato! lo trovo squallido!
dai un'occhiata ai bench che ti ho postato e a quelli precedenti raggiungibili dal mio link, guarda i miglioramenti nel giro di 6-8 mesi ;)

non credo che una distro diversa possa fare chissa' quali differenze... poi credo che quello che conti sia anche il kernel usato e la versione dei driver nvidia...
beh se si parla di gentoo.. la distro conta! ciò non toglie che sia un merito di linux avere la possibilità di ottimizzare il SW per il proprio pc in particolare! sembra che su gentoo i giochi (quelli in OGL portati) girano addirittura meglio che su win!
dai un'occhiata ai bench che ti ho postato e a quelli precedenti raggiungibili dal mio link, guarda i miglioramenti nel giro di 6-8 mesi
hai ragione! ma ne va fatta ancora di strada... l'implementazione di dx10 deve ancora iniziare! speriamo che Vista tarda ancora un pò, perchè il supporto a dx8/9 sta andando spedito!

Ah certo é vero, avevo capito male io:
pensavo ti riferissi alla pulizia del codice! :D
Però devo dirti che fare delle piccole macro aiuta atenere il codice pulito, se non ne abusi, in particolare aiutano a tenerlo pulito quando devi scrivere più volte una trafila di molte chiamate a funzione che son sempre le stesse, come in questo caso.
La pulizia del codice ne guadagna parecchio!!


Infatti ti ho scritto:


L'espansione in linea delle macro è molto efficiente per operazioni elementari. Si usano in rari casi per migliorare la sintassi di una qualche chiamata di funzione o uniformarla a qualcos'altro.


Ma li leggete i post? :D


Per quanto riguarda il discorso overhead hai ragione a dire che con o senza macro non cambia niente, però devo dire che i giochi DirectX mi sembra abbiano buone prestazioni, paragonabili a quelli OpenGL, quindi complessivamente non mi semba che le DirectX abbiano problemi di "pesantezza"...
:mbe:

E chi ha detto niente? Ancora, ti riquoto quello che ho scritto. Quà mi sa che non si legge:


Ogni libreria ha le sue idiosincrasie, non ha per niente senso confrontare due sistemi su due librerie diverse. Non hai trovato niente perchè non c'è nessun modo se non la sperimentazione empirica. Ma comunque se gli approcci sono differenti, essendo due librerie grafiche diverse, il confronto "diretto" fra funzionalità non ha senso. Nello stesso tuo link sta scritto che quel metodo è un "pain in the ass". Cioè un modo molto elegante di dire che in quella versione di Direct3D è molto inefficiente. Le cose sono sicuramente molto cambiate oggi.

forse intendeva dire il contrario! e cioè che ogl sono più lente in teoria perchè chiamano più volte delle funzioni!

Non volevo dire neanche quello. Ho detto semplicemente che dei due metodi, dovrebbe essere piu' efficiente quello DX, ma che il metodo DirectX esiste anche in OpenGL, quindi in quell'articolo ci sono confonti che non sussistono piu' ai tempi di oggi.

Inoltre, se si parla delle performance di una feature di una libreria, non ci si deve far ingannare col scambiarle come le performance dell'intera libreria.

Cioè, mettiamo caso i vertex array di OpenGL sono piu' lenti di quelli di Direct3D, non significa che OpenGL sia piu' lenta di Direct3D. Stabilire quale sia piu' veloce delle due librerie non lo si può fare scrivendo 4 righe di codice e tirare due conclusioni. Non funziona proprio cosi.

La cosa che non mi va proprio giù è il fatto che opengl è praticamente destinato a morire se la microsoft farà quello che vuol fare..speriamo bene. :cry:

Non credo che Microsoft faccia una cosa del genere. Dietro OpenGL c'è un mercato troppo importante. Applicazioni come Maya, (3D Studio Max non lo considero perchè ha un layer che consente di usare entrambi), Pixologic ZBrush, Luxology Modo, Messiah Studio, NextLimit RealFlow ... Solo per citarne un frammento microscopico.

DirectX trova impiego per la maggiorparte nei giochi. OpenGL invece è il re per quanto riguarda la grafica professionale. Una simile manovra potrebbe avere un impatto disastroso su determinati tipi di software. Questo non significherebbe la morte di OpenGL, significherebbe che i produttori di simili software comincerebbero a fare un porting di massa verso altri SO. Altri invece soccomberanno proprio.

Io spero vivamente che sia solo un hype ingiustificato e che i fatti alla fine saranno altri. Altrimenti non saprei piu' cosa pensare.

Ma li leggete i post? :D

E chi ha detto niente? Ancora, ti riquoto quello che ho scritto. Quà mi sa che non si legge:
scusa, é che con quei post ho fatto 1 confusione incredibile... ho frainteso... :D

@mjordan: si hai fatto bene a chiarire :D! a un certo punto non capivo più qual'era la tua posizione :D quindi sostanzialmente siamo tutti daccordo!

@mjordan: si hai fatto bene a chiarire :D! a un certo punto non capivo più qual'era la tua posizione :D quindi sostanzialmente siamo tutti daccordo!

Eh già.
http://www.opengl.org/images_global/opengl_logo.jpgRulez!

:rotfl:

ragazzi, non vi è venuto in mente che forse un porting di kde su windows possa sfavorire la diffusione di linux? :confused:

']ragazzi, non vi è venuto in mente che forse un porting di kde su windows possa sfavorire la diffusione di linux? :confused:

No. Perchè per "porting di KDE" si intende "KDE Libs". E poi perchè mai dovrebbe sfavorire la diffusione di Linux?

perchè magari quegli utenti a cui piace linux ma che sono indecisi se passare a esso o cmq a installarlo, potrebbero prendere la "scorciatoia" di installarsi kde su windows e così addio linux.

']perchè magari quegli utenti a cui piace linux ma che sono indecisi se passare a esso o cmq a installarlo, potrebbero prendere la "scorciatoia" di installarsi kde su windows e così addio linux.
è impossibile! al massimo uno che ha paura di installare linux prima prova kde su win e poi installerà linux! non credo che ci sia il pericolo di cui parli! kde è senzaltro meglio integrato in linux, il fatto di portarlo in win può solo portare maggiore visibilità a tutto il mondo linux!

']perchè magari quegli utenti a cui piace linux ma che sono indecisi se passare a esso o cmq a installarlo, potrebbero prendere la "scorciatoia" di installarsi kde su windows e così addio linux.
linux e i software che ci girano sono attraenti perché, se tutto quello che ti serve é disponibile sotto linux, puoi evitare di pagare 100 euro di licenza windows.
Se kde arriva su windows é più facile che anche gli utenti "poco informati" prendano contatto con le applicazioni GRATIS, e che quindi si rendano conto di non aver più bisogno di windows.
Se si rendono conto, poi secondo te l'italiano medio, tra pagare 100 euro inutilmente o invece risparmiarli, cosa sceglie?

']perchè magari quegli utenti a cui piace linux ma che sono indecisi se passare a esso o cmq a installarlo, potrebbero prendere la "scorciatoia" di installarsi kde su windows e così addio linux.

i motivi sensati per cui passare a linux riguardano quello che sta sotto.... ;)....
....l'utente indeciso di cui parli lo disinstalla all'istante dammi retta...

un sistema operativo non deve "piacere"...deve essere uno strumento potente e permetterti di fare ciò che vuoi....

linux e i software che ci girano sono attraenti perché, se tutto quello che ti serve é disponibile sotto linux, puoi evitare di pagare 100 euro di licenza windows.
Se kde arriva su windows é più facile che anche gli utenti "poco informati" prendano contatto con le applicazioni GRATIS, e che quindi si rendano conto di non aver più bisogno di windows.
Se si rendono conto, poi secondo te l'italiano medio, tra pagare 100 euro inutilmente o invece risparmiarli, cosa sceglie?

craccare tutto....... ;)

poi certo nelle attività lavorative dove i controlii "DOVREBBERO" essere maggiormente pervasivi allora la questione cambia e il discorso da te fatto non fa una piega.

craccare tutto....... ;)

poi certo nelle attività lavorative dove i controlii "DOVREBBERO" essere maggiormente pervasivi allora la questione cambia e il discorso da te fatto non fa una piega.
si chiaro che chi cracca non rientra nel discorso...
:D
ad ogni modo, se veramente faranno Palladium in modo che sarà impossibile installare programmi craccati, credo che quella sarà la morte commerciale di Windows (o cmq "l'inizio della fine").

:D

ad ogni modo, se veramente faranno Palladium in modo che sarà impossibile installare programmi craccati, credo che quella sarà la morte commerciale di Windows (o cmq "l'inizio della fine").

:D
:doh: non dovevi dirglielo! dovevi aspettare che usciva palladium prima di svelare questo segreto :D

Ma palladium si può disattivare... :D Solo che con palladium disattivato non si potrà vedere contenuti trusted... Ma niente paura: chi deve disattivare Palladium per poter usare la sua bella copia di windows pirata, non si farà certamente scrupoli a reperire anche la copia pirata del contenuto trusted che non può più vedere... :D

bè io ricordo che la prima versione di word, parlo di una decina di anni fa, aveva un sistema di protezione che di fatto impediva la "diffusione" :D e così la gente stava cominciando a preferire wordperfect, poi tolta la protezione tolto il problema, e microsoft leader del settore :doh:
per cui credo che ci penseranno molto prima di "mettere a punto" palladium...o al massimo faranno in modo che i soliti pirati possano aggirarlo....

']bè io ricordo che la prima versione di word, parlo di una decina di anni fa, aveva un sistema di protezione che di fatto impediva la "diffusione" :D e così la gente stava cominciando a preferire wordperfect, poi tolta la protezione tolto il problema, e microsoft leader del settore :doh:
per cui credo che ci penseranno molto prima di "mettere a punto" palladium...o al massimo faranno in modo che i soliti pirati possano aggirarlo....
infatti se ci fai caso, sono anni che tutti dicono "sulle prossime console (non solo MS) sarà impossibile usare giochi non originali", mettono protezioni di quà, protezioni di là...
fatto sta che sulla XBOX 360 si é scoperto un "bug" che probabilmente permetterà di togliere qualsiasi protezione.
Che CASO, eh?
;)

:doh: non dovevi dirglielo! dovevi aspettare che usciva palladium prima di svelare questo segreto :D

non doveva dirlo a me?... :eek:

pensa che io ho visto la sua risposta prima che dark modificasse il suo post e volevo proprio tirare in ballo questo ormai fantomatico palladium.....

solo che ho evitato daltronde la prima ad avere fatto marcia (sottile.....) indietro è stata proprio la M$ visto che non è solo lei che fa parte del progetto ma + o meno tutti (pure Linux a quanto ne so....)

cmq quando vogliono Proteggere sul serio fanno le cose per benino; ora non ricordo il nome ma ho letto in giro per questo forum di un gioco che era craccabile solo avendo un altro pc via LAN a fare da server per bypassare la protezione.....e chissà quante copie avrà venduto...... :doh:

non doveva dirlo a me?... :eek:

pensa che io ho visto la sua risposta prima che dark modificasse il suo post e volevo proprio tirare in ballo questo ormai fantomatico palladium.....
eh dici che ho fatto male a modificarlo? Prima c'era scritta 1 altro commento su 1 altra questione, ma ho preferito evitare... era 1 discorso 1 po' "sega mentale"...
:D

eh dici che ho fatto male a modificarlo? Prima c'era scritta 1 altro commento su 1 altra questione, ma ho preferito evitare... era 1 discorso 1 po' "sega mentale"...
:D

eh perchè?.....ci mancherebbe questo è il bello della libertà....poi sappiamo che qui si finisce OT ogni 5 minuti.....poi per l'onanismo mentale con me caschi benissimo..... :)

Ma palladium si può disattivare... :D Solo che con palladium disattivato non si potrà vedere contenuti trusted... Ma niente paura: chi deve disattivare Palladium per poter usare la sua bella copia di windows pirata, non si farà certamente scrupoli a reperire anche la copia pirata del contenuto trusted che non può più vedere... :D

Il brutto non è tanto di chi ce lo ha e lo puo' disattivare... Il brutto è per chi non ce lo ha e non lo può attivare... Il che il risultato, da come vedo, non cambia... :asd:

:muro:

Ecco la mia personale lista di shells alternative:
http://www.reactos.org/wiki/index.php/Untested_%28open_source%29_software_list#Shells

Senza ombra di dubbio la migliore è SharpE: www.sharpe-shell.org

Comunque un progetto del genere già esisteva, se non sbaglio: http://kde-cygwin.sourceforge.net/

non doveva dirlo a me?... :eek:
mavvà! era un commento ironico! intendevo a quelli di MS! magari non si erano accorti della loro rovina imminente con questo progetto :D

solo che ho evitato daltronde la prima ad avere fatto marcia (sottile.....) indietro è stata proprio la M$ visto che non è solo lei che fa parte del progetto ma + o meno tutti (pure Linux a quanto ne so....)

è vero che in linux saranno implementati i drivers per permettere palladium.. ma vuoi che non li puoi togliere? su windows niente è sicuro e trasparente.. questa è la differenza tra open e closed in fondo!
cmq quando vogliono Proteggere sul serio fanno le cose per benino; ora non ricordo il nome ma ho letto in giro per questo forum di un gioco che era craccabile solo avendo un altro pc via LAN a fare da server per bypassare la protezione.....e chissà quante copie avrà venduto...... :doh:
6

è vero che in linux saranno implementati i drivers per permettere palladium.. ma vuoi che non li puoi togliere? su windows niente è sicuro e trasparente.. questa è la differenza tra open e closed in fondo!

Sempre che nell'hardware non inseriscano qualche sistema di controllo che non permette di installare software con TCPA disabilitato.

Sempre che nell'hardware non inseriscano qualche sistema di controllo che non permette di installare software con TCPA disabilitato.
sempre che un cinese qualunque non si metta a fare HW senza questo controllo...

ps. c'è un cinese per ogni esigenza :D

Sempre che nell'hardware non inseriscano qualche sistema di controllo che non permette di installare software con TCPA disabilitato.

se fosse così e il procedimento n fosse altresì controllabile dall'utente allora tutte le speculazioni ( apocalittiche spesso) riguardo ad una congiura verso l'OSS ecc. avrebbero + che un fondamento: sarebbero una certezza...

Un hardware così non lo comprerebbe nessuno... Ricordate il casino per il numero seriale del PIII, che era di default attivato, ma comunque disattivabile? Alla fine hanno vinto gli utenti: nei bios successivi era disattivato di default...

Hanno fatto tutto 'sto casino per una cosa che SAREBBE potuta succedere e comunque MOLTO meno grave di palladium... Figuriamoci se si implementasse Palladium e non fosse disabilitabile: boicottaggio più completo... Ed il primo produttore che proponesse HW senza palladium o con palladium disattivabile, venderebbe camionate di roba...

In conclusione: nessun manager sano di mente permetterebbe di mettere in commercio hardware con palladium obbligatorio...

mavvà! era un commento ironico! intendevo a quelli di MS! magari non si erano accorti della loro rovina imminente con questo progetto :D


bhe anch'io ero ironico....mica volevo fare il saccente visto che in materia di informatica qua in mezzo forse sono quello che ne sa meno....

è vero che in linux saranno implementati i drivers per permettere palladium.. ma vuoi che non li puoi togliere? su windows niente è sicuro e trasparente.. questa è la differenza tra open e closed in fondo!

bhe ma se li puoi togliere allora perchè perdere tempo?
forse che tutti i veri colossi che supportano OSS iniziano a farsi pagare per ogni installazione? forse che OSS faceva tanto fico ma ora iniziano sempre + a tirare la cinghia anzi meglio la rete "donando" le loro distro alle community perchè proseguano con lo sviluppo dei samaritani?

sarà ma le community distro derivate dalle commerciali non mi sembrano poi eccezionali....sarà che fedoracore3 non mi è sembrata proprio eccezionale....

altro discorso vale per le distro libere che vogliono rimanerlo che a quanto mi sembra per quanto il ciclo di release non sia velocissimo sembrano essere quelle con un vero futuro di fronte (naturalmente imho)

6

parli dati alla mano o credi che me lo abbia detto mio cuggggino..... :sofico:

bhe ma se li puoi togliere allora perchè perdere tempo?
forse che tutti i veri colossi che supportano OSS iniziano a farsi pagare per ogni installazione? forse che OSS faceva tanto fico ma ora iniziano sempre + a tirare la cinghia anzi meglio la rete "donando" le loro distro alle community perchè proseguano con lo sviluppo dei samaritani?
bisogna ammettere che palladium starebbe bene sul pc di qualche winzozzer.. mi sono stufato di sistemare i pc dei miei amici ogni 2 settimane! :D poi quando imparano glielo togli palladium! è come con la bicicletta, all'inizio hai bisogno le rotelle!

sarà ma le community distro derivate dalle commerciali non mi sembrano poi eccezionali....sarà che fedoracore3 non mi è sembrata proprio eccezionale....

fedora ha fatto schifo anche a me.. non è una tua impressione! ma il mondo linux è vasto, non devi fermarti lì! dico sempre di provare opensuse10 prima di dire che il mondo opensource non si impegna per i niubbi!
altro discorso vale per le distro libere che vogliono rimanerlo che a quanto mi sembra per quanto il ciclo di release non sia velocissimo sembrano essere quelle con un vero futuro di fronte (naturalmente imho)

le distro libere penso che non vanno bene ai niubbi, ma se le sai usare puoi ottenere risultati migliori! ogni distro ha il suo target in fondo..

parli dati alla mano o credi che me lo abbia detto mio cuggggino..... :sofico:
:D mi piacerebbe vedere i dati veri! sarebbe interessante!

le distro libere penso che non vanno bene ai niubbi, ma se le sai usare puoi ottenere risultati migliori! ogni distro ha il suo target in fondo..

kubuntu si!
(ok cdimauro lo sappiamo che a te non si e' installata, mentre la Fedora si' :p )

kubuntu si!
(ok cdimauro lo sappiamo che a te non si e' installata, mentre la Fedora si' :p )
cdimauro... pare sia sparito.. :confused:
comunque kubuntu è la distro che ho sul portatile in questo momento e dal quale sto scrivendo ora! :D ha ancora qualche lacuna sotto il profilo della configurazione, ma è sufficentemente niubba se ci fai la mano.. complimenti alla distro comunque! a differenza di opensuse da quel senso di leggerezza.. ma anche opensuse ha fatto passi da gigante in questo senso! penso che la 10.1 sarà da provare assolutamente :D

eh perchè?.....ci mancherebbe questo è il bello della libertà....poi sappiamo che qui si finisce OT ogni 5 minuti.....poi per l'onanismo mentale con me caschi benissimo..... :)
Ok, allora d'ora in poi cercherò d'impegnarmi di più...
:cool:

bisogna ammettere che palladium starebbe bene sul pc di qualche winzozzer.. mi sono stufato di sistemare i pc dei miei amici ogni 2 settimane! :D poi quando imparano glielo togli palladium! è come con la bicicletta, all'inizio hai bisogno le rotelle!

lol....io ho da quando ho smesso di sistemare i pc altrui aggratis ho molti meno amici...... :) ....certo poi ci sono amici e amici questo è verissimo.

fedora ha fatto schifo anche a me.. non è una tua impressione! ma il mondo linux è vasto, non devi fermarti lì! dico sempre di provare opensuse10 prima di dire che il mondo opensource non si impegna per i niubbi!

io infatti non mi sono fermato li e dopo averne provate alcune (la suse 10 non open, poi mandriva le2005...poi prima fedorac3)....alla fine sono riuscito a tirare su una vectorlinuxsoho5.1 (in rc1) su un laptop celly800 con 128mb di ram con la quale mi trovo a meraviglia e per quello che ci faccio è ok; qualcosa l'ho dovuto fare a manina ma se riesci a risolvere le cose sotto al pinguino hai un senso di soddisfazione diverso dal risolvere un coflitto di irq sotto win...

le distro libere penso che non vanno bene ai niubbi, ma se le sai usare puoi ottenere risultati migliori! ogni distro ha il suo target in fondo..

verissimo ma questo target non mi sembra stabile ossia se è vero che quando uno inizia gli vanno + che bene le easy distro, + va avanti e + sente di voler progredire.....non dico per forza che uno debba arrivare a gentoo....tuttavia + una persona si allontana da win + si avvicina non tanto a linux in se stesso ma proprio alla filosofia di condivisione dietro a GNU

fedora ha fatto schifo anche a me.. non è una tua impressione! ma il mondo linux è vasto, non devi fermarti lì! dico sempre di provare opensuse10 prima di dire che il mondo opensource non si impegna per i niubbi!


Perchè Fedora ti ha fatto schifo?

Perchè Fedora ti ha fatto schifo?
mi ha dato un sacco di problemi (fedora core2)... prima di tutto bisognava ricompilare il kernel per aggiungere il supporto in lettura a ntfd, poi non mi ha riconosciuto ne lo scanner ne la stampante (tutte due dell'hp), poi ancora KDE era impostato da cani ed ho dovuto usare GNOME che era impostato male lo stesso, ma un pò meno! ad esempio era assurda la navigazione spaziale delle cartelle, senza che fosse permesso cambiare l'impostazione facilmente (ho dovuto navigare gconf)! quelli di fedora non sanno cosa sia un tool per configurare (alla yast) :D.. la gestione degli rpm non era un grankè! l'unica cosa positiva è che non ciucciava molte risorse! praticamente non è la mia distro, non voglio dire che fa schifo :D

verissimo ma questo target non mi sembra stabile ossia se è vero che quando uno inizia gli vanno + che bene le easy distro, + va avanti e + sente di voler progredire.....non dico per forza che uno debba arrivare a gentoo....tuttavia + una persona si allontana da win + si avvicina non tanto a linux in se stesso ma proprio alla filosofia di condivisione dietro a GNU
verissimo!! il classico utente win non sa esattamente il perchè di certe cose, ma le fà! linux ti da la possibilità di capire come funziona... si instaura una sorta di amicizia tra utente e SO :sofico: ! io alla fine uso linux da appena 2 anni e mezzo!! lo conosco come le mie tasche ormai (vabbè sono del settore :D)... più di windows che ho usato per 10 anni!

verissimo!! il classico utente win non sa esattamente il perchè di certe cose, ma le fà! linux ti da la possibilità di capire come funziona... si instaura una sorta di amicizia tra utente e SO :sofico: ! io alla fine uso linux da appena 2 anni e mezzo!! lo conosco come le mie tasche ormai (vabbè sono del settore :D)... più di windows che ho usato per 10 anni!

Già.. Capire cosi tanto come funziona da scartare una distribuzione perchè non riconosce uno scanner... :D

Già.. Capire cosi tanto come funziona da scartare una distribuzione perchè non riconosce uno scanner... :D
eddai.. alla fine l'ho fatto funzionare! il problema è che con tutti quei problemi non mi è piaciuta, non fa per me fedora! se volevo smanettarci sopra per farla funzionare avrei installato slackware (l'ho fatto), ma almeno una slack non pretende di essere adatta al desktop :D

eddai.. alla fine l'ho fatto funzionare! il problema è che con tutti quei problemi non mi è piaciuta, non fa per me fedora! se volevo smanettarci sopra per farla funzionare avrei installato slackware (l'ho fatto), ma almeno una slack non pretende di essere adatta al desktop :D

Bhè, Linux è bello perchè è vario :D

lol....io ho da quando ho smesso di sistemare i pc altrui aggratis ho molti meno amici...... :) ....certo poi ci sono amici e amici questo è verissimo.
mmmhh, allora non sono l'unico a cui tocca sistemare PC gratis agli amici?
E' bello scoprire di non essere soli nell'universo... :D

mmmhh, allora non sono l'unico a cui tocca sistemare PC gratis agli amici?
E' bello scoprire di non essere soli nell'universo... :D


Siamo in bella compagnia... mediamente almeno uno-due al mese, senza contare le telefonate del tipo:

"Perchè questo non funziona?"

Siamo in bella compagnia... mediamente almeno uno-due al mese, senza contare le telefonate del tipo:

"Perchè questo non funziona?"

azz.....meno male che quelle le evitano.... :)

azz.....meno male che quelle le evitano.... :)
con me no. Mi chiedono anche quello.


vi racconto un caso estremo, poi mai più verificato...

Una volta uno che non é proprio mio amico, ma amico dei miei (quindi dovevo pure evitare di far fare brutta figura ai miei), ha telefonato xché non riusciva a far funzionare una cosa.
Mi ha tenuto al telefono per 35 minuti. Io ero piccolo, ero giovane, non l'ho mandato al diavolo, ho pensato "vabé ormai sono in ballo..."

Qualche giorno dopo ha telefonato la seconda volta, dopo 5 minuti che andava avanti a parlare ho troncato la sua frase con "si però io devo studiare, facciamo un'altra volta".
E lui: "ah scusa vabé ciao".
E si é offeso.
Ma ci rendiamo conto? Cioé uno ti telefona quando gli pare e tu devi dargli ore di supporto telefonico gratis senò si offende?

E' proprio vero il detto "chi si offende é fetente"... :D

E' proprio vero il detto "chi si offende é fetente"... :D

e che certe persone è meglio perderle che trovarle...... ;)

vi prego!! fatemi raccontare questa finchè siamo in OT!
un tizio mi ha chiamato perchè la sua stampante non andava... e... era in pausa!!! ahahah! ok basta!

con me no. Mi chiedono anche quello.


vi racconto un caso estremo, poi mai più verificato...

Una volta uno che non é proprio mio amico, ma amico dei miei (quindi dovevo pure evitare di far fare brutta figura ai miei), ha telefonato xché non riusciva a far funzionare una cosa.
Mi ha tenuto al telefono per 35 minuti. Io ero piccolo, ero giovane, non l'ho mandato al diavolo, ho pensato "vabé ormai sono in ballo..."

Qualche giorno dopo ha telefonato la seconda volta, dopo 5 minuti che andava avanti a parlare ho troncato la sua frase con "si però io devo studiare, facciamo un'altra volta".
E lui: "ah scusa vabé ciao".
E si é offeso.
Ma ci rendiamo conto? Cioé uno ti telefona quando gli pare e tu devi dargli ore di supporto telefonico gratis senò si offende?

E' proprio vero il detto "chi si offende é fetente"... :D

:rolleyes: Pensa tu ... Il bello è che certa gente poi se la mette pure a pretesa di essere aiutato... Uno fa un favore una volta, come se significasse che è disponibile a vita.
Io infatti sono anni che non so fare piu' niente... Ho la nausa... Anche solo il fatto di dover aggiustare un mio computer mi deprime... Anche se sono casi sporadici.

']bè io ricordo che la prima versione di word, parlo di una decina di anni fa, aveva un sistema di protezione che di fatto impediva la "diffusione" :D e così la gente stava cominciando a preferire wordperfect, poi tolta la protezione tolto il problema, e microsoft leader del settore :doh:
per cui credo che ci penseranno molto prima di "mettere a punto" palladium...o al massimo faranno in modo che i soliti pirati possano aggirarlo....

Ma che stai addì che la gente INCOMINCIAVA a preferire Wordperfect a Word...

Wordperfect era leader EONI prima che la Microzozz si mettesse a fare illecita concorrenza alle software house scopiazzandole e usando nei suoi applicativi metodi di rendirizzamento e recupero informazioni (dati, campi, voci) all'interno dei file, più veloci degli algoritmi standard della concorrenza perché sfruttavano peculiarità del sistema operativo non rilasciate e mai documentate agli sviluppatori esterni.

Successe nel famoso caso dBase contro Access.


Oppure basti pensare ai bassi trucchi pubblicitari di Microsoft:

Wordperfect 6-7-8 Vs Word 1

Wordperfect 9 Vs Word 2

Whoops MAGIA! M$ cambia nome di versione

Wordperfect 9 Vs Word 9

E così fra la versione 9 di WP e la versione taroccata "9" di Word, i poveri utonti PC incominciarono a dirsi:

«A parità di versione prendo il prodotto Microsoft!»

sarà una mia interpretazione ma "loosing a little performance" detto da uno che sta pubblicizzando il progetto per il quale lavora... lo intendo come approssimato per difetto!
mi era sfuggito sto link, leggiti il primo :D
http://www.winehq.com/site/myths

Ma che stai addì che la gente INCOMINCIAVA a preferire Wordperfect a Word...

Wordperfect era leader EONI prima che la Microzozz si mettesse a fare illecita concorrenza alle software house scopiazzandole e usando nei suoi applicativi metodi di rendirizzamento e recupero informazioni (dati, campi, voci) all'interno dei file, più veloci degli algoritmi standard della concorrenza perché sfruttavano peculiarità del sistema operativo non rilasciate e mai documentate agli sviluppatori esterni.

Successe nel famoso caso dBase contro Access.


Oppure basti pensare ai bassi trucchi pubblicitari di Microsoft:

Wordperfect 6-7-8 Vs Word 1

Wordperfect 9 Vs Word 2

Whoops MAGIA! M$ cambia nome di versione

Wordperfect 9 Vs Word 9

E così fra la versione 9 di WP e la versione taroccata "9" di Word, i poveri utonti PC incominciarono a dirsi:

«A parità di versione prendo il prodotto Microsoft!»

Quindi alla Microsoft sono coglioni, gente meschiana, buon commerciali o cosa secondo te?

Quindi alla Microsoft sono coglioni, gente meschiana, buon commerciali o cosa secondo te?
eheh mi viene da dire un mix dei 3! ma non lo dico :D

mi era sfuggito sto link, leggiti il primo
http://www.winehq.com/site/myths
letto! praticamente la parte che mi coinvolge è:
Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.
in effetti non hanno negato che due layers sono meno performanti (in teoria) di uno, però dicono che non influisce un granchè nelle prestazioni di un programma! però prima di parlare di confronti aspettiamo che sia completo (tanto non ho fretta :D)

eheh mi viene da dire un mix dei 3! ma non lo dico :D


letto! praticamente la parte che mi coinvolge è:

in effetti non hanno negato che due layers sono meno performanti (in teoria) di uno, però dicono che non influisce un granchè nelle prestazioni di un programma! però prima di parlare di confronti aspettiamo che sia completo (tanto non ho fretta :D)

Posso dire la mia che wine l'ho usato un po' :) (ovviamente posso fare solo considerazioni a pelle)

Le prestazioni del programma in se non sono abbassate molto, ho provato anche "Terragen" (che è un programma che succhia abbastanza CPU in calcoli) e la velocità di rendering, anche se sicuramente sarà stata inferiore a quella sotto windows, era comunque più che soddisfacente in ogni caso .

L'unica "pecca", se così vogliamo chiamarla, di wine oltre alla non completa compatibilità con Windows NT (almeno una non così buona compatibilità come impostando Win9x per il sistema da emulare nella configurazione) è che la GUI rimane in single thread :)

Questo provoca quell' effetto , ad alcuni fastidioso, di ridisegnamento dell' interfaccia grafica pezzo per pezzo tanto comune ai programmi scritti in Java .

Ciao

Quindi alla Microsoft sono coglioni, gente meschiana, buon commerciali o cosa secondo te?

bhe questa è storia.....non si tratta di essere coglioni (...anzi) ma di usare a proprio vantaggio la conoscenza interna (a livello di sorgenti) della piattaforma su cui un determinato appicativo dovrà girare.

Questo meccanismo falsa la "concorrenza" ed è inoltre difficile riuscire ad accertare se ciò sia vero visto che per fare una analisi dei sorgenti di win ci vorrebbero mesi e non è detto che si otterrebero giudizi unanimi.

Secondo me...
sarebbe utile potendo espiantare l'interfaccia utente di windows per sostituirla con il kde. Il problema è che non penso che si possa fare, quindi rimarrebbe un'interfaccia come tante già viste in precedenza: la "dock" di mac, le miriadi di interfacce per il lancio veloce dei programmi etc etc etc. Scusate ma una fine così meschina, a mio parere, KDE non se la merita proprio.

Per quanto riguarda le applicazioni open source che diverrebbero accessibili a windows ce ne sono tante che già funzionano sia da una parte, sia dall'altra. E non è l'interfaccia utente del desktop a "portarle" in windows, bensì la compilazione dei loro sorgenti per renderle adatte a windows.

Alla fin fine, meglio se quei benefattori (gli sviluppatori di kde) si impegnano al meglio sul fronte "linux".

Ultime due cose.
Qualcuno su questo 3d ha scritto che kde è più lento di winxp. Non è vero: il computer dal quale sto scrivendo è un portatile pentium 3 700Mhz del '99 con sopra Kubuntu 7.10; è funziona alla grande. Non potrei neppure immaginare di installare winxp.

Altra cosa: ma siamo sicuri che quelli che si ostinano ad usare dei windows xp "cracckati", giusto per il solo scopo di navigare in internnella parte linux.et, piuttosto che passare a linux si meritino proprio una figata come il kde... :)

solo a me KDE crasha per colpa dell'adept con ogni distro e config hardware differente (avendo provato su VM e nn solo ma cmq su pc diversi) ? :sbonk:

Secondo me...
sarebbe utile potendo espiantare l'interfaccia utente di windows per sostituirla con il kde. Il problema è che non penso che si possa fare, quindi rimarrebbe un'interfaccia come tante già viste in precedenza: la "dock" di mac, le miriadi di interfacce per il lancio veloce dei programmi etc etc etc. Scusate ma una fine così meschina, a mio parere, KDE non se la merita proprio.


Guarda che le interfacce mica si cambiano come mettersi un paio di pantaloni. E' semplicemente infattibile.


Per quanto riguarda le applicazioni open source che diverrebbero accessibili a windows ce ne sono tante che già funzionano sia da una parte, sia dall'altra. E non è l'interfaccia utente del desktop a "portarle" in windows, bensì la compilazione dei loro sorgenti per renderle adatte a windows.


Mai scritta una riga di codice GUI in vita tua eh? :stordita:


Alla fin fine, meglio se quei benefattori (gli sviluppatori di kde) si impegnano al meglio sul fronte "linux".


Fronte Unix.


Ultime due cose.
Qualcuno su questo 3d ha scritto che kde è più lento di winxp. Non è vero: il computer dal quale sto scrivendo è un portatile pentium 3 700Mhz del '99 con sopra Kubuntu 7.10; è funziona alla grande. Non potrei neppure immaginare di installare winxp.


E quanto ha di disco?

Secondo me...
sarebbe utile potendo espiantare l'interfaccia utente di windows per sostituirla con il kde. Il problema è che non penso che si possa fare, quindi rimarrebbe un'interfaccia come tante già viste in precedenza: la "dock" di mac, le miriadi di interfacce per il lancio veloce dei programmi etc etc etc. Scusate ma una fine così meschina, a mio parere, KDE non se la merita proprio.

Per quanto riguarda le applicazioni open source che diverrebbero accessibili a windows ce ne sono tante che già funzionano sia da una parte, sia dall'altra. E non è l'interfaccia utente del desktop a "portarle" in windows, bensì la compilazione dei loro sorgenti per renderle adatte a windows.

Alla fin fine, meglio se quei benefattori (gli sviluppatori di kde) si impegnano al meglio sul fronte "linux".

Ultime due cose.
Qualcuno su questo 3d ha scritto che kde è più lento di winxp. Non è vero: il computer dal quale sto scrivendo è un portatile pentium 3 700Mhz del '99 con sopra Kubuntu 7.10; è funziona alla grande. Non potrei neppure immaginare di installare winxp.

Altra cosa: ma siamo sicuri che quelli che si ostinano ad usare dei windows xp "cracckati", giusto per il solo scopo di navigare in internnella parte linux.et, piuttosto che passare a linux si meritino proprio una figata come il kde... :)
in realtà l'interfaccia è quella di windows.. semplicemente si potranno eseguire alcune applicazioni di kde su windows. penso a K3B, amarok o ktorrent per dirne un paio

in realtà l'interfaccia è quella di windows.. semplicemente si potranno eseguire alcune applicazioni di kde su windows. penso a K3B, amarok o ktorrent per dirne un paio

k3b lo attendo con ansia

Esattamente.... Il porting di KDE è inteso come porting delle kdelibs, non dell'ambiente desktop... Poi che ci siano dei modi per eseguirlo non lo metto in dubbio, ma di certo non ci si riferiva alla sostituzione dell'interfaccia di Windows.

Esattamente.... Il porting di KDE è inteso come porting delle kdelibs, non dell'ambiente desktop... Poi che ci siano dei modi per eseguirlo non lo metto in dubbio, ma di certo non ci si riferiva alla sostituzione dell'interfaccia di Windows.
Ciao!
L'interfaccia Plasma è già funzionante in Windows.
Mi spiego meglio: parte e gira a malapena, ma è già in grado di sovrapporsi pienamente a quella di Windows. Ha la sua barra, il suo desktop, tutto come essere in Linux, solo che sotto c'è Windows. È in fase di scrittura la barra delle applicazioni e tutt'ora manca completamente la systray.
Perché cominci a funzionare decentemente ci vorrà quantomeno un anno e mezzo, ma l'obiettivo è raggiungibile.

EDIT: qui c'è un filmato vecchiotto ancora senza barra, ma per far capire che è possibile:
http://www.youtube.com/watch?v=OZt4TaRmLEY&fmt=18

Ciao!
L'interfaccia Plasma è già funzionante in Windows.
Mi spiego meglio: parte e gira a malapena, ma è già in grado di sovrapporsi pienamente a quella di Windows. Ha la sua barra, il suo desktop, tutto come essere in Linux, solo che sotto c'è Windows. È in fase di scrittura la barra delle applicazioni e tutt'ora manca completamente la systray.
Perché cominci a funzionare decentemente ci vorrà quantomeno un anno e mezzo, ma l'obiettivo è raggiungibile.

EDIT: qui c'è un filmato vecchiotto ancora senza barra, ma per far capire che è possibile:
http://www.youtube.com/watch?v=OZt4TaRmLEY&fmt=18

Questo lo so, ciò non toglie che l'obiettivo principale del progetto è quello di avere delle kdelibs perfettamente funzionanti sotto Windows. Francamente trovo realmente un lavoro sprecato quello di voler portare l'intero desktop sotto Windows, nonchè di utilità davvero limitata.

Questo lo so, ciò non toglie che l'obiettivo principale del progetto è quello di avere delle kdelibs perfettamente funzionanti sotto Windows. Francamente trovo realmente un lavoro sprecato quello di voler portare l'intero desktop sotto Windows, nonchè di utilità davvero limitata.

Ma infatti, se dopo 2/3 anni di lavoro l'intefaccia grafica parte *a malapena*, è davvero lavoro sprecato...
Trovo decisamente più utile fare il porting delle kde libs per usare le applicazioni KDE...

Ciao. :)

Ma infatti, se dopo 2/3 anni di lavoro l'intefaccia grafica parte *a malapena*, è davvero lavoro sprecato...
Trovo decisamente più utile fare il porting delle kde libs per usare le applicazioni KDE...

Ciao. :)

Dunque gli sviluppatori costantemente attivi che si occupano del porting di KDE per Windows sono tra i 3 e i 5, e il lavoro fatto per far funzionare Plasma inteso come desktop sotto Windows è stato veramente pochissimo, per quello non funziona.
La maggior parte del lavoro visto che ci sono poche persone che ci spendono del tempo, come è logico e come avete scritto anche voi, è ancora sulle librerie. Tenete conto anche che, se non vado errato, plasma fa parte di kdelibs dalla versione 4.2.
Da quello che mi è parso di vedere l'ordine di priorità che stanno seguendo è questo:
- lavorare sulle librerie e sull'installer;
- fare in modo che le applicazioni quantomeno partano (ad esempio ci sono varie applicazioni inutilizzabili, che però partono, e grazie a questo sforzo iniziale hanno trovato uno sviluppatore disposto a lavorarci su. Uno di questi casi è Kile, e potrebbe succedere così anche per K3B, il programma di masterizzazione);
- risolvere i vari bug delle applicazioni più importanti (Kate, Dolphin, Kopete, Amarok).

Ciao ciao,
Diego

Dunque gli sviluppatori costantemente attivi che si occupano del porting di KDE per Windows sono tra i 3 e i 5, e il lavoro fatto per far funzionare Plasma inteso come desktop sotto Windows è stato veramente pochissimo, per quello non funziona.
La maggior parte del lavoro visto che ci sono poche persone che ci spendono del tempo, come è logico e come avete scritto anche voi, è ancora sulle librerie. Tenete conto anche che, se non vado errato, plasma fa parte di kdelibs dalla versione 4.2.
Da quello che mi è parso di vedere l'ordine di priorità che stanno seguendo è questo:
- lavorare sulle librerie e sull'installer;
- fare in modo che le applicazioni quantomeno partano (ad esempio ci sono varie applicazioni inutilizzabili, che però partono, e grazie a questo sforzo iniziale hanno trovato uno sviluppatore disposto a lavorarci su. Uno di questi casi è Kile, e potrebbe succedere così anche per K3B, il programma di masterizzazione);
- risolvere i vari bug delle applicazioni più importanti (Kate, Dolphin, Kopete, Amarok).

Ciao ciao,
Diego

Ciao Diego,
grazie per gli aggiornamenti ;)

Ciao. :)