View Full Version : Consigli per GUI dinamiche in Java
F@lkland§
30-06-2008, 09:28
Ciao ragazzi!
Dovrei creare dei form di inserimento, di visualizzazione e di modifica che variano a seconda del contesto dell'applicazione!
Questi form dinamici come consigliate di realizzarli?
Io avrei in mente due soluzioni: la prima è creare più costruttori che poi dovranno essere chiamati a seconda dell'utilità, la seconda è allocare dinamicamente le JButton, JLabel, JTextField e così via andando a leggere da un file xml.
Il programma non è un'applicazione web.
Avete consigli da dispensarmi?
Come dovrei realizzarlo sommariamente?
Grazie a tutti! :)
io banalmente creerei tot form diverse che visualizzerei a seconda della situazione :D
il vero problema di questo problema (scusate) è che creare una form in Swing è un tantino difficile.
banryu79
30-06-2008, 10:05
...è che creare una form in Swing è un tantino difficile
Perchè dici questo?
Cioè, in cosa consiste secondo te la difficoltà specifica?
Nel fatto di dover utilizzare JPanel annidati e diversi LayoutManager se le form che devi realizzare sono complesse?
Comunque, se le form in oggetto servono a rappresentare viste di dati in un DB si potrebbe utilizzare la libreria OpenSwing (http://www.google.it/search?q=OpenSwing&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:it:official&client=firefox-a)(vantaggi: free, attivamente supportata e in continuo corso di aggiornamento; svantaggi: richiede un certo tempo di apprendimento, si basa sul pattern MVC, quindi presenta qualche complessità, la documentazione free non chiarisce proprio tutto [esiste infatti la versione a pagamento]).
Invece "per alleviare" le difficoltà intrinseche nell'operare con i diversi LayoutManager si potrebbe usare la libreria MIG Layout (http://www.miglayout.com/) (presenta una sorta di interfaccia unificata per il layouting dei componenti in Swing e SWT completamente via codice, molto chiaro, e immagino semplice da utilizzare anche se non l'ho ancora provato [perchè per ora mi trovo bene a gestire l'interfaccia con Matisse & custom code]).
Perchè dici questo?
Cioè, in cosa consiste secondo te la difficoltà specifica?
Nel fatto di dover utilizzare JPanel annidati e diversi LayoutManager se le form che devi realizzare sono complesse? te la faccio breve: con Windows Forms è più facile :fagiano:
banryu79
30-06-2008, 10:55
te la faccio breve: con Windows Forms è più facile :fagiano:
Posso immaginarlo però mi sembra, così "a pelle", un confronto un po' forzato: qui siamo in ambiente Java, e sappiamo che Java non è legato a doppio nodo ad un particolare os, con tutto quello che ne deriva per il discorso interfacce grafiche.
Posso immaginarlo però mi sembra, così "a pelle", un confronto un po' forzato: qui siamo in ambiente Java, e sappiamo che Java non è legato a doppio nodo ad un particolare os, con tutto quello che ne deriva per il discorso interfacce grafiche. le Windows Forms non hanno assolutamente nulla a che vedere con le GUI di Win32, si tratta completamente di un altro sistema grafico la cui logica è costruita da zero; i componenti .NET non sono componenti nativi, e le forms sono un concetto che in Win32 neanche esiste: in Win32 hai solo la main window (SDI o MDI) e le dialogs, modal o modeless.
ma indipendentemente da questo discorso, sta di fatto una cosa soltanto: il tipico editor RAD per Windows Forms mi permette di creare interfacce grafiche molto più produttivamente che scrivendo manualmente il codice Java per Swing. come mai allora non usare un ambiente RAD anche per Swing? per due motivi:
1) fanno cagare :asd:
2) generano codice a dir poco vergognoso con cui poi tu devi avere a che fare, cosa che in C# ad esempio viene brillantemente evitata grazie alle partial classes.
banryu79
30-06-2008, 15:29
ma indipendentemente da questo discorso, sta di fatto una cosa soltanto: il tipico editor RAD per Windows Forms mi permette di creare interfacce grafiche molto più produttivamente che scrivendo manualmente il codice Java per Swing. come mai allora non usare un ambiente RAD anche per Swing? per due motivi:
1) fanno cagare :asd:
Può essere, ma se vuoi scrivere interfacce grafiche in Java che opzioni migliori hai?
2) generano codice a dir poco vergognoso con cui poi tu devi avere a che fare, cosa che in C# ad esempio viene brillantemente evitata grazie alle partial classes.
Interessante, in due parole che sarebbero?
tomminno
01-07-2008, 12:25
2) generano codice a dir poco vergognoso con cui poi tu devi avere a che fare, cosa che in C# ad esempio viene brillantemente evitata grazie alle partial classes.
Solo perchè il sudicio viene nascosto sotto il tappeto non significa che non ci sia.
Inoltre ti è mai capitato che si impallasse la parte nascosta della classe e che per risistemare devi cancellare l'intero file, farlo ricreare da VS e poi ripristinare la vecchia versione?
tomminno
01-07-2008, 12:29
Interessante, in due parole che sarebbero?
Sono una feature necessaria per l'editor automatico, dopo gli enormi problemi causati dalla precendente versione di editor/C#.
In sostanza puoi spezzare una classe su più file, nella pratica viene usata solo dall'editor per generare tutte le sue schifezze in un file nascosto così che tutto appare pulitissimo e ordinato.
Ogni tanto si impalla e non avendo accesso al file nascosto devi cancellare il tuo file, farlo rigenerare dall'editor e ripristinare quello vecchio.
Solo perchè il sudicio viene nascosto sotto il tappeto non significa che non ci sia. significa che non devi averci a che fare. tu hai soluzioni migliori (ugualmente produttive s'intende, per evitare che tu mi risponda di scrivere il codice a mano)?
Inoltre ti è mai capitato che si impallasse la parte nascosta della classe e che per risistemare devi cancellare l'intero file, farlo ricreare da VS e poi ripristinare la vecchia versione? no, motivo percui vorrei che tu mi illuminassi circa i bug introdotti dall'editor nel codice "nascosto" come lo chiami tu (che poi nascosto non è, si può visualizzare senza problemi anche nell'IDE) con un esempio riproducibile su Visual C# Express 2005 o 2008, grazie.
aggiungo che vorrei anche capire cos'è st'idiozia che dopo aver fatto ricostruire il file dall'IDE devi ripristinare quello malfunzionante :asd:
tomminno
01-07-2008, 13:02
significa che non devi averci a che fare. tu hai soluzioni migliori (ugualmente produttive s'intende, per evitare che tu mi risponda di scrivere il codice a mano)?
Finchè non introdurranno dei gestori di layout automatici (e non quelle stupide ancore) l'editor del VS è adatto solo per interfacce poco più che banali. Essere produttivi è molto dura, se ci fosse modo di scriversi il codice a mano a volte sarebbe meglio. Oltretutto sei obbligato a schiaffare tutto in una stessa classe, che tende sempre a diventare caotica per via dei tanti controlli presenti e degli eventi associati.
no, motivo percui vorrei che tu mi illuminassi circa i bug introdotti dall'editor nel codice "nascosto" come lo chiami tu (che poi nascosto non è, si può visualizzare senza problemi anche nell'IDE) con un esempio riproducibile su Visual C# Express 2005 o 2008, grazie.
Esempi riproducibili non saprei fornirteli visto che capitano sia su pagine ASP.NET che su interfacce desktop anche dopo parecchio tempo che ci lavori su, ma non certo in maniera deterministica.
Ad un certo punto capita che compilando viene fuori l'errore che una classe non esiste, nonostante che esista e venga correttamente identificata dall'intellisense, andando in modalità design risulta impossibile aggiungere oggetti all'interfaccia. Cancellando il file e facendolo ricreare nuovo al VS e sovrascrivendolo con quello precedente tutto torna a funzionare, segno che è la classe parziale nascosta ad essersi danneggiata in modo irreparabile.
aggiungo che vorrei anche capire cos'è st'idiozia che dopo aver fatto ricostruire il file dall'IDE devi ripristinare quello malfunzionante :asd:
Perchè evidentemente non è il file visibile ad essere mal funzionante, ma la classe parziale nascosta generata dall'editor.
E siccome quella viene generata dinamicamente se ricrei una classe nuova l'editor cancella e rigenera anche la classe parziale nascosta. Quanto ripristini il vecchio codice "utente" l'editor rigenera anche la classe parziale nascosta correttamente.
Ah si questo metodo funziona solo con pagine ASP.NET, in caso di WinForm devi rigenerarti da 0 l'interfaccia e quando capita sono bestemmie perchè non ti salva nemmeno SVN.
banryu79
01-07-2008, 13:14
Sì, nel frattempo ho attinto alle sempre disponibili risorse del web per capire cosa sono queste partial class: ad una prima lettura come approccio non mi sembra malvagio, francamente.
Comunque in ambiente Java per distinguere la business logic dalla UI logic (quando serve, cioè per interfacce più complesse della media) si adotta il sempiterno MVC pattern e morta là: o implementato "a mano" o sfruttando delle librerie jar disponibili (tipo la OpenSwing citata, ma ne esistono tante altre a seconda dei casi).
Che lo sviluppatore non sia mai sollevato al 100% dalla responsabilità di gestire il problema comunque mi sembra normale; alla fine, imho, la questione rimane sempre quella di imparare a conoscere un po' più affondo gli strumenti che si utilizzano; quando le possibilità/gli strumenti a disposizione per affrontare il problema sono molteplici e/o versatili una soluzione la si trova.
In effetti le difficoltà maggiori che ho incontrato fin'ora sono sempre state causate, nel 95% dei casi, dalla mia ignoranza delle possibilità/strumenti già disponibili, piuttosto che di una loro "inadeguatezza".
Per ora io mi trovo bene con l'editor messo a disposizione da NetBeans unito all'integrazione di codice "a mano" per gestire determinate situazioni.
Non ho mai dovuto, fin'ora, scriverne troppo o di troppo complesso.
da quando esiste qtjambi con annesso plugin per eclipse direi che è più facile creare GUI in java che in .NET :D
comunque a parte gli scherzi.. mi pare che netbeans ha un buon disegnatore di interfacce per SWING, mentre su eclipse consiglierei SWT.
non vedo assolutamente la superiorità di Windows Forms, anzi secondo me sono il punto debole del framework .NET
tomminno
01-07-2008, 14:48
Sì, nel frattempo ho attinto alle sempre disponibili risorse del web per capire cosa sono queste partial class: ad una prima lettura come approccio non mi sembra malvagio, francamente.
Si per nascondere la monnezza dell'editor sotto il tappeto sono l'ideale ;)
Comunque in ambiente Java per distinguere la business logic dalla UI logic (quando serve, cioè per interfacce più complesse della media) si adotta il sempiterno MVC pattern e morta là: o implementato "a mano" o sfruttando delle librerie jar disponibili (tipo la OpenSwing citata, ma ne esistono tante altre a seconda dei casi).
Questo è ovvio (in qualunque linguaggio). Solo che con gli editor automatici non puoi spezzettare un'interfaccia con decine di controlli su più file (sarebbe bello poter creare ulteriori partial class quando c'è di mezzo il rad), mentre a mano per fare un esempio posso creare una classe per ogni tab di un controllo notebook, cosa che con il RAD non è possibile.
Poi ogni controllo avrà i suoi bravi eventi associati, il che comporta ritrovarsi con classi da centinaia di metodi...
Che lo sviluppatore non sia mai sollevato al 100% dalla responsabilità di gestire il problema comunque mi sembra normale; alla fine, imho, la questione rimane sempre quella di imparare a conoscere un po' più affondo gli strumenti che si utilizzano; quando le possibilità/gli strumenti a disposizione per affrontare il problema sono molteplici e/o versatili una soluzione la si trova.
Per esperienza personale ho verificato che quando uno si abitua troppo alla pappa pronta dei framework, il giorno che devi fare qualcosa di non contemplato (o meglio di non facilitato) dagli stessi, sei fregato.
Recentemente ho riscontrato questo quando un collega ha dovuto realizzare un post multipart, ci è impazzito
In effetti le difficoltà maggiori che ho incontrato fin'ora sono sempre state causate, nel 95% dei casi, dalla mia ignoranza delle possibilità/strumenti già disponibili, piuttosto che di una loro "inadeguatezza".
Non ti dico quanto ho imprecato il giorno che ho dovuto fare un'interfaccia ad espansione radiale dei controlli in C#.
Le ancore non servivano a niente, sono dovuto ricorrere al solito calcolo manuale del posizionamento dei controlli tipico delle MFC.
Per ora io mi trovo bene con l'editor messo a disposizione da NetBeans unito all'integrazione di codice "a mano" per gestire determinate situazioni.
Non ho mai dovuto, fin'ora, scriverne troppo o di troppo complesso.
Tutte le volte che ho dovuto scrivere interfacce un pò più complicate del solito gli IDE sono sempre risultati un intralcio più che un vantaggio.
Certo, se devo mettere 2 controlli in croce uso il RAD senza pensarci 2 volte.
Finchè non introdurranno dei gestori di layout automatici (e non quelle stupide ancore) l'editor del VS è adatto solo per interfacce poco più che banali. le tue opinioni non interessano a nessuno.
Essere produttivi è molto dura, se ci fosse modo di scriversi il codice a mano a volte sarebbe meglio. nessuno ti obbliga ad usare l'editor RAD in Visual C# Express: puoi anche scrivere manualmente il codice che genera le forms e i controlli. tuttavia mi sfugge decisamente uno scenario in cui un tale approccio sarebbe preferibile.
Oltretutto sei obbligato a schiaffare tutto in una stessa classe, che tende sempre a diventare caotica per via dei tanti controlli presenti e degli eventi associati. non reiteriamo sullo stesso problema: a meno che tu non stia progettando una GUI veramente complessa (tanto da confondere persino l'utente, motivo percui si tratta di una situazione di certo non comune) il caos non è un problema grazie alle partial classes.
Esempi riproducibili non saprei fornirteli visto che capitano sia su pagine ASP.NET che su interfacce desktop anche dopo parecchio tempo che ci lavori su, ma non certo in maniera deterministica. i computers sono macchine deterministiche, e gli esseri umani possono emulare comportamenti deterministici. se non mi proponi un esempio riproducibile io assumo che tu scriva cazzate.
almeno, se proprio non riesci a vincere la pigrizia, abbi la decenza di darmi un link alla KB dove la Microsoft mi spieghi al posto tuo come riprodurre un bug; ma altrimenti non scrivere per nulla.
Ad un certo punto capita che compilando viene fuori l'errore che una classe non esiste, nonostante che esista e venga correttamente identificata dall'intellisense, andando in modalità design risulta impossibile aggiungere oggetti all'interfaccia. Cancellando il file e facendolo ricreare nuovo al VS e sovrascrivendolo con quello precedente tutto torna a funzionare, segno che è la classe parziale nascosta ad essersi danneggiata in modo irreparabile. :blah: :blah: :blah:
Perchè evidentemente non è il file visibile ad essere mal funzionante, ma la classe parziale nascosta generata dall'editor. ma tralasciando un attimo il fatto che tu continui a parlare della classe parziale autogenerata come se fosse inaccessibile da dentro l'IDE...
Ah si questo metodo funziona solo con pagine ASP.NET, in caso di WinForm devi rigenerarti da 0 l'interfaccia e quando capita sono bestemmie perchè non ti salva nemmeno SVN. ... questo è il colmo :asd:
in pratica un malfunzionamento nell'editor delle Windows Forms può corrompere un database (remoto) di versioning? :D
senti, io al limite posso anche capire (nonostante tu non sia in grado di fornirmi degli esempi riproducibili) che l'editor RAD delle Windows Forms sia buggato: nessun software è perfetto. ma l'approccio RAD è evidentemente l'approccio migliore in termini di produttività per la creazione di interfacce grafiche, intricate e non. non è che se al tuo specifico martello si stacca il manico allora i chiodi li devi piantare a manate :rolleyes:
e soprattutto finché non sei in grado di dimostrare e di farci riprodurre qualcosa il discorso non si pone neanche, perché come ho scritto sopra le tue opinioni non interessano a nessuno (per quanto siano poste con ironia).
non vedo assolutamente la superiorità di Windows Forms, anzi secondo me sono il punto debole del framework .NET questa discussione sta assumendo toni di forte inutilità :stordita:
sembrate tutti molto bravi a sparare cazzat... pardon, a dire le vostre opinioni :asd:
ma almeno abbiate la decenza di schiaffarci pure un "IMVVVVHO" ogni tanto :rolleyes:
sembrate tutti molto bravi a sparare cazzat... pardon, a dire le vostre opinioni :asd:
ma almeno abbiate la decenza di schiaffarci pure un "IMVVVVHO" ogni tanto :rolleyes:
"secondo me" cosa vorrebbe dire secondo te (scusate il gioco di parole)? :fagiano:
ho usato per progetti non banali sia Windows Forms che SWT che QT che SWING quindi posso dire di essermene fatto un'idea. SWING non è un granchè e non lo nascondo, ma nemmeno le Windows Forms sono perfette, se appena cerchi di fare qualcosa che non è stato previsto è un bagno di sangue :p
banryu79
01-07-2008, 15:28
...
Solo che con gli editor automatici non puoi spezzettare un'interfaccia con decine di controlli su più file (sarebbe bello poter creare ulteriori partial class quando c'è di mezzo il rad), mentre a mano per fare un esempio posso creare una classe per ogni tab di un controllo notebook, cosa che con il RAD non è possibile.
Poi ogni controllo avrà i suoi bravi eventi associati, il che comporta ritrovarsi con classi da centinaia di metodi...
Beh, forse non lo puoi fare con l'editor specifico a cui stai facendo riferimento nel tuo post, però io le interfacce un attimo più complesse di solito le ho divise in 3-4 file .java (e quindi 3-4 classi principali che al loro interno possono includere classi annidate, oppure 1 o 2 classi minori utility della principale presenti dunque nello stesso file .java[questo però è più raro] ).
Di solito ho una classe per il "Frame" principale che al suo interno può essere diviso in più "aree logiche" o di "visualizzazione" (ognuna è una classe che si riferisce alla principale e gestisce solo alcuni aspetti ben precisi che rappresenta: per esempio una classe che estende JPanel per eseguire un rendering grafico di un oggetto-modello dell'applicazione; un'altra per gestire delle operazioni su quell'oggetto-modello dell'applicazione).
Se dovessi gestire qualcosa di più complesso invece che l'implementazione diretta di classi proverei a definire delle classi astratte implementate poi dalla classe concreta del caso.
Per ora a livello di GUI non mi è ancora servito.
D'altronde non ho un'esperienza significativa a livello di "casistica" per cui mi è difficile giudicare.
Come si suol dire: just my 2 cents.
Come si suol dire: just my 2 cents. se potessi raccogliere tutti i 2 cents che ho letto in questo e altri thread sarei ricco.
banryu79
01-07-2008, 16:16
se potessi raccogliere tutti i 2 cents che ho letto in questo e altri thread sarei ricco.
Certamente,
volevo solo capire, da ignorante, perchè tu (che da altri post in cui ti ho letto mi sembri possedere una certa esperienza) ritieni le Swing "non valide" (hai scritto che fanno cagare) per codificare interfacce grafiche in Java.
Se non ho capito male quello che hai scritto, tu affermi che le Swing non sono valide per come sono strutturate ad essere utilizzate per la costruzione di GUI da parte di editor visuali.
Sostieni che le Windows Form siano migliori.
Ma questo è un'altro discorso: nel contesto di questo thread l'utente che l'ha aperto sta utilizzando Java, percui, per tornare a bomba, la questione rimane: se le Swing (e gli editor visuali che le utilizzano) non sono adatte, che altre opzioni rimangono?
Io sostengo che alcune facilitazioni potrebbero esserci appoggiandosi a librerie Java che affiancano Swing in questo o quell'aspetto, a patto di poter investire un certo lasso di tempo nell'apprendimento di quegli strumenti.
Tutto qua.
Certamente,
volevo solo capire, da ignorante, perchè tu (che da altri post in cui ti ho letto mi sembri possedere una certa esperienza) ritieni le Swing "non valide" (hai scritto che fanno cagare) per codificare interfacce grafiche in Java. AAAAARGH, mai detto questo!!
Swing è uno dei migliori toolkit grafici al mondo! :D
ma il toolkit da solo potrebbe non bastare: spesso anche io preferisco scrivere manualmente il codice Swing delle mie interfacce grafiche Java, ma come puoi ben immaginare riesco ad essere 1000 volte più produttivo in Visual C# grazie all'editor visuale. Swing è "programmaticamente" ottimo, ma i due editor visuali che ho provato (Visual Editor e un altro affare, Jigloo :D) non mi piacciono per niente: erano quelli che ho scritto che fanno cagare, e scusate ma a sto punto un'opinione personale ce l'ho messa pure io :asd:
Se non ho capito male quello che hai scritto, tu affermi che le Swing non sono valide per come sono strutturate ad essere utilizzate per la costruzione di GUI da parte di editor visuali. .....
stravolgimento completo :muro:
Sostieni che le Windows Form siano migliori. sostengo di essere più produttivo quando creo una GUI che usa le Windows Forms, ma non per merito delle Windows Forms in se'.
^TiGeRShArK^
01-07-2008, 17:04
Invece per la gestione di un'interfaccia grafica ad oggi la soluzione migliore è COCOA.
In futuro, quando prenderanno piede le WPF che stanno oggi muovendo i primi timidi passi, allora si vedrà.
Comunque la mia personale scala di preferenza è:
1) Cocoa
2) Windows Forms alla pari con WPF
3) Swing
4) SWT
Questo dando un giudizio completo sia sulla pulizia dell'interfaccia grafica e del frameowrk, che sulla usabilità degli editor predefiniti e la diffusione relativa.
WPF ha ottime potenzialità ma è ancora troppo poco supportato.
Cocoa imho dal punto di vista della pulizia non ha eguali (ricordo che era anche uscito un articolo un bel pò di tempo fa sul sito della sun dove proponevano in java l'utilizzo di un design pattern simile a quello di cocoa).
Le windows Forms sono molto supportate e l'editor non è affatto male, anche se si incontrano diverse "sbavature" in certi componenti base (uno su tutti il famigerato DataGridView).
Swing con matisse è l'ideale per applicazioni che necessittano la massima portabilità, ma scrivere interfacce grafiche in java richiede uno sforzo maggiore a parita di complessità rispetto alle windows forms.
Swt con il visual editor, l'ultima volta che l'ho usato era da :Puke:
Dimenticavo: Fuoco alle polveri! :O
:asd:
banryu79
02-07-2008, 08:58
...cut...
Grazie dei chiarimenti, ora ho capito cosa intendevi.
in ogni caso qtdesigner rulez :O
non sono OT perchè c'è anche per java :O
in ogni caso qtdesigner rulez :O
non sono OT perchè c'è anche per java :O
scusa ma utilizzando Qt da Java (ho capito bene?) non perdi in portabilità? devi portarti appresso un mattone di libreria di cui esiste una versione per ogni piattaforma, e quindi sei costretto a distribuire un binario per ogni piattaforma; perché farsi del male?
la via del codice Swing scritto manualmente non è poi così malaccio, anche perché i vari tipi di layout aiutano.
NOTA BENE: ora con quest'ultima frase potrebbe sembrare che io stia precisamente contraddicendo tutto quello che ho scritto fino all'altro ieri :D quindi faccio due precisazioni:
1) scrivere codice Swing manualmente non è malaccio, ma trascinare bottoni e controlli vari per Windows Forms è certo meglio :Prrr: questo QtDesigner riesce ad essere addirittura all'altezza di un RAD fortemente ispirato a quelli Borland, di fama i migliori di sempre?
2) i vari tipi di layout aiutano, certo, ma a scrivere codice manuale; non saprei proprio che farmene in un ambiente RAD (anzi quando usavo Jigloo impostavo sempre il layout "assoluto", cioè quello nullo che permette di posizionare i controlli in posizioni arbitrarie).
DanieleC88
02-07-2008, 23:26
questo QtDesigner riesce ad essere addirittura all'altezza di un RAD fortemente ispirato a quelli Borland, di fama i migliori di sempre?
Le Qt dovresti provarle, sono molto comode anche da usare via codice. :O
non saprei proprio che farmene in un ambiente RAD
Questo, detto da te, mi suona strano... :Prrr:
Questo, detto da te, mi suona strano... :Prrr: ah guarda quando sto nell'ambiente RAD che intendi tu per quanto mi riguarda le Qt potrebbero anche andare a farsi f***ere con tutto il designer :D :D :D
scusa ma utilizzando Qt da Java (ho capito bene?) non perdi in portabilità? devi portarti appresso un mattone di libreria di cui esiste una versione per ogni piattaforma, e quindi sei costretto a distribuire un binario per ogni piattaforma; perché farsi del male?
perchè dovresti perdere in portabilità? le QT esistono su tutte le piattaforme in cui esiste java se non di più. Java stesso è un mattone di cui esiste una versione per ogni piattaforma, quindi il problema di cui parli è totalmente assente.
ps. lo ammetto qtjambi non c'è per tutte le piattaforme.. però QT sì! :sofico:
la via del codice Swing scritto manualmente non è poi così malaccio, anche perché i vari tipi di layout aiutano.
invece il mio modesto parere è che Swing è inferiore soprattutto quando ci devi lavorare manualmente. i layout sono fatti malissimo confronto a SWT e QT :p
SWT però pecca nel designer.. invece QT no :D
NOTA BENE: ora con quest'ultima frase potrebbe sembrare che io stia precisamente contraddicendo tutto quello che ho scritto fino all'altro ieri :D quindi faccio due precisazioni:
1) scrivere codice Swing manualmente non è malaccio, ma trascinare bottoni e controlli vari per Windows Forms è certo meglio :Prrr: questo QtDesigner riesce ad essere addirittura all'altezza di un RAD fortemente ispirato a quelli Borland, di fama i migliori di sempre?
2) i vari tipi di layout aiutano, certo, ma a scrivere codice manuale; non saprei proprio che farmene in un ambiente RAD (anzi quando usavo Jigloo impostavo sempre il layout "assoluto", cioè quello nullo che permette di posizionare i controlli in posizioni arbitrarie).
c'è sto demo che ormai l'ho messo nei segnalibri perchè lo posto una volta su due :P
http://dist.trolltech.com/video/browser.html
i layout servono eccome sia per scrivere codice manuale sia per un ambiente RAD.
permettono di rendere la disposizione dei controlli ottima anche con risoluzioni molto diverse di quella che abbiamo usato nel disegnare l'interfaccia (cosa che ovviamente non avviene con le posizioni assolute, che quindi sono da evitare)
permettono di rendere la disposizione dei controlli ottima anche con risoluzioni molto diverse di quella che abbiamo usato nel disegnare l'interfaccia (cosa che ovviamente non avviene con le posizioni assolute, che quindi sono da evitare) OT: in Win32 questo problema viene risolto dalle dialog units: le posizioni dei controlli sono espresse in unità di misura che non corrispondono al pixel e che variano a seconda della risoluzione dello schermo.
IT: in .NET invece il problema sussiste :sofico:
questa discussione che partiva dall'inutilità totale ora viene annoverata come una delle poche che mi abbia insegnato qualcosa, non perché la mia cultura sia grande (o magari si :asd: ) ma per il livello che si tiene mediamente su questo forum: "problema urgentissimo puntatori", "[C] aiuto", "esercizio programmazione 1 aiuto non mi viene", ecc. ecc. :rolleyes:
ciò che questa discussione mi ha insegnato è che quando si programma un'interfaccia grafica da visualizzare con risoluzioni diverse, Visual C++ 2008 & Resource Editor è meglio di Visual C# 2008 Express :sofico: :sofico:
bene: stracolmo di soddisfazione intellettuale, posso premere Ctrl+D :asd:
:asd: ovviamente le soluzioni che non iniziano per "visual studio" non ti interessano..
perchè non provi il plugin QT per visual studio? :fuck: :asd:
:asd: ovviamente le soluzioni che non iniziano per "visual studio" non ti interessano..
perchè non provi il plugin QT per visual studio? :fuck: :asd:
perché guarda, spesso e volentieri sono le soluzioni che non iniziano per Microsoft che non mi interessano :ciapet:
naa, in realtà non è vero: lungi da me il negare la qualità tecnica di un prodotto software senza prima aver letto più del 50% della documentazione; il fatto è che al 90% io leggo documentazione Microsoft* :Prrr:
*aò, è scritta bene... :O
perchè non provi il plugin QT per visual studio? :fuck: :asd: ok, ignora il mio precedente post :D
risposta seria: la stragrande totalità (concetto di mia invenzione :asd: ) dei programmi che scrivo per hobby, cioè quasi tutti quelli che scrivo, non devono girare su sistemi diversi da Windows; di conseguenza non ho la minima necessità di introdurre un layer di astrazione per la GUI che oltre a darmi una cosa che non mi serve (la portabilità) introduce potenziali problemi concettuali, e posso immaginare che ne introduca molti perché Qt e User32/GDI32 hanno un design necessariamente diverso. in sostanza: pesa, complica, e serve a poco; il danno, lo svantaggio, e nessun vantaggio :Prrr:
una scelta molto più ragionevole per me è invece MFC, che aderisce perfettamente alle API sottostanti ed introduce irrinunciabili semplificazioni nel mio codice Win32 pur mantenendo una relativa leggerezza, anche grazie al fatto che non devo ridistribuirlo perché è già distribuito con Windows.
di tutto il resto chi se ne frega.
DanieleC88
04-07-2008, 14:32
OT: in Win32 questo problema viene risolto dalle dialog units: le posizioni dei controlli sono espresse in unità di misura che non corrispondono al pixel e che variano a seconda della risoluzione dello schermo.
Non si tratta necessariamente di ridimensionare controlli però, è un layout flessibile quello che Qt e GTK+ ti permettono di usare: per fare un'analogia, è un po' come un layout liquido di un sito web. :O
^TiGeRShArK^
04-07-2008, 19:46
OT: in Win32 questo problema viene risolto dalle dialog units: le posizioni dei controlli sono espresse in unità di misura che non corrispondono al pixel e che variano a seconda della risoluzione dello schermo.
IT: in .NET invece il problema sussiste :sofico:
questa discussione che partiva dall'inutilità totale ora viene annoverata come una delle poche che mi abbia insegnato qualcosa, non perché la mia cultura sia grande (o magari si :asd: ) ma per il livello che si tiene mediamente su questo forum: "problema urgentissimo puntatori", "[C] aiuto", "esercizio programmazione 1 aiuto non mi viene", ecc. ecc. :rolleyes:
ciò che questa discussione mi ha insegnato è che quando si programma un'interfaccia grafica da visualizzare con risoluzioni diverse, Visual C++ 2008 & Resource Editor è meglio di Visual C# 2008 Express :sofico: :sofico:
bene: stracolmo di soddisfazione intellettuale, posso premere Ctrl+D :asd:
In .Net hai WPF che cappotta letteralmente il sistema precedente :O
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.