[UI Design] C++, C++ .NET, C++ MFC o C#?

[Pixel452]

Non l’ho citato prima perché non è esattamente comodo come può essere su MFC ma su WPF c’è un pannello che si chiama DockPanel che permette di disporre gli elementi “Dockandoli”. Il limite è che non offre il trascinamento degli elementi(intendo il poter riposizionare col mouse i vari pannelli in realtime), questo lo dovreste implementare voi.

Si discuteva di fare un meta linguaggio interno che descriva la configurazione del progetto e cercare di generare automaticamente parte dell'interfaccia grafica..

In WPF puoi facilmente farlo caricando un file xaml esterno a runtime, senza stare ad inventarti linguaggi proprietari o cose strane che probabilmente sarebbero piene di bug.

In questo video c’è un programma scritto in WPF che tra le altre cose cambia gli stili dell’applicazione in tempo reale, in effetti non è niente di che, si può completamente stravolgere l’applicazione, qui praticamente cambia solo i colori. Nota che come dice nel video cambiando solo i temi si può includere il supporto al multitouch, tanto per darti un idea.

http://www.youtube.com/watch?v=CZQK-B9bTnI

[cionci]

C# e .Net offrono sicuramente barre dockable: http://www.codeguru.com/csharp/cshar...cle.php/c14179
Il tempo che guadagni con MFC nel disegno dell'interfaccia lo perdi nello scrivere il codice per gestire l'interfaccia.
Per Ribbon con WinForms: http://www.codeproject.com/KB/shell/...sribbon01.aspx
Sono una marea di parti: http://www.codeproject.com/script/Ar...px?amid=172641

[Pixel452]

Ma siamo sicuri che WinForm sia sufficiente per il livello di dinamicità che gli serve? Non vorrei che a metà progetto si trovasse in qualche brutta situazione e dovesse perdere una marea di tempo per fare cose che con altre librerie sarebbero banali. La questione sul caricamento dinamico dell'interfaccia tramite linguaggio interno mi sembra propendere per una situazione estrema

[tomminno]

Originariamente inviato da Pixel452

Ma siamo sicuri che WinForm sia sufficiente per il livello di dinamicità che gli serve? Non vorrei che a metà progetto si trovasse in qualche brutta situazione e dovesse perdere una marea di tempo per fare cose che con altre librerie sarebbero banali. La questione sul caricamento dinamico dell'interfaccia tramite linguaggio interno mi sembra propendere per una situazione estrema

Il problema delle WinForm in questo caso è la totale mancanza di layout manager (entità molto misteriose per gli ideatori di tutte le GUI Microsoft) che si sono decisi ad introdurre solo con WPF.

[zakmckraken]

...e in ogni caso MFC e dinamico sono 2 cose non banali da mescolare...a meno di non conoscere molto bene i sorgenti di MFC e sapere come "fregare" l'implementazione standard...per non parlare dell'ipotesi folle di creare toolbars dinamiche (ovvero creare e distruggere toolbars a piacimento) modificare i comportamenti del docking dei componenti (il meccanismo di piazzamento degli elementi nelle dockbars e un po'anti intuitivo), se poi vuoi fare finestre splittate o dialog con contenuto dinamico...
Ho fatto tutto questo, pero'ho avuto quasi un anno a disposizione, e conoscevo gia bene l'MFC standard.
Tolto questo per cose normali adoro MFC che trovo tutto sommato piacevole da programmare (e ad aprile provero'QT...vedremo che accade :P )

[peng]

Originariamente inviato da zakmckraken

....per non parlare dell'ipotesi folle di creare toolbars dinamiche (ovvero creare e distruggere toolbars a piacimento) modificare i comportamenti del docking dei componenti (il meccanismo di piazzamento degli elementi nelle dockbars e un po'anti intuitivo), se poi vuoi fare finestre splittate o dialog con contenuto dinamico...

..non mi sognerei mai di farlo in C#, era un'idea, folle appunto, che era venuta al mio collega ieri, ma la si farebbe solamente in C#. Comunque siamo consapevoli sia una follia e non credo proprio procederemo per questa..

WPF e' una tentazione, ma credo sia piu' sicuro WinForms in quanto posso affidarmi all'esperienza del collega..

[peng]

Originariamente inviato da cionci

C# e .Net offrono sicuramente barre dockable: http://www.codeguru.com/csharp/cshar...cle.php/c14179
Il tempo che guadagni con MFC nel disegno dell'interfaccia lo perdi nello scrivere il codice per gestire l'interfaccia.
Per Ribbon con WinForms: http://www.codeproject.com/KB/shell/...sribbon01.aspx
Sono una marea di parti: http://www.codeproject.com/script/Ar...px?amid=172641

Grazie, ora provo a seguire quanto scritto in questi blog..

[peng]

Originariamente inviato da Pixel452

Ma siamo sicuri che WinForm sia sufficiente per il livello di dinamicità che gli serve? Non vorrei che a metà progetto si trovasse in qualche brutta situazione e dovesse perdere una marea di tempo per fare cose che con altre librerie sarebbero banali. La questione sul caricamento dinamico dell'interfaccia tramite linguaggio interno mi sembra propendere per una situazione estrema

Credo che WinForms sia un buon compromesso.. la questione del caricamento dinamico credo proprio la lasceremo stare :-)

[peng]

Originariamente inviato da peng

Credo che WinForms sia un buon compromesso.. la questione del caricamento dinamico credo proprio la lasceremo stare :-)

C++.. dopo accurate performance analysis abbiamo deciso di abbondonare l'idea di C# :-).. il nostro software richiede intensi calcoli e non vogliamo dare ai nostri clienti un prodotto che runna + lentemente rispetto a quello dei nostri competitori..

[Pixel452]

Ma non potete fare l'interfaccia in C# ed i calcoli in C++? Alla fine si tratta solo di una chiamata ad una dll esterna scritta in C++, l'integrazione è abbastanza buona, potete tenere tutti i tipi di progetti sotto un unica solution. Io ho optato per questa strada per un programma a babbo morto e non mi sembra malaccio. Certo la vostra situazione è un pò diversa...

Quindi adesso userete MFC? Quelle librerie andrebbero dimenticate! Visto che il tuo collega conosceva le WinForms con le MFC siete da capo, a questo punto io voto Qt.

[cionci]

Originariamente inviato da Pixel452

Quindi adesso userete MFC? Quelle librerie andrebbero dimenticate! Visto che il tuo collega conosceva le WinForms con le MFC siete da capo, a questo punto io voto Qt.

Quotone !!! Anche fare la parte di interfaccia in C# e quella di calcolo in C++ è un'ottima idea.
Per Qt il tempo di apprendimento e il tempo di sviluppo sono nettamente inferiori a quelli di MFC.
Certo devi fare un po' di rinunce, come ad esempio l'interfaccia ribbon, ma volendo si possono comunque ottenere interfacce simili: http://qiacat.blogspot.com/2009/04/r...-korat-ui.html
Qui ci sono alcuni esempi di cosa si può ottenere con le Qt: http://doc.trolltech.com/4.6/examples.html

[peng]

qt lo abbiamo escluso sebbene il mio collega vi ha lavorato per 1 anno. Faccio parte di una multinazionale e una sede con cui collaboraiamo strettamente ha sviluppato un software complesso in MFC, quindi la nostra curva di apprendimento e la nostra sinergia con loro sono in favore.

La libreria non va dimenticata secondo me. .NET e MFC sono due concetti diversi.

[Pixel452]

A me MFC fa venire i brividi, cmq il tutto IMHO. Direi che a questo punto la vostra scelta l'avete fatta. Buon lavoro!

[peng]

..si. Abbiamo considerato tutte le alternative possibili:

1 - abbiamo escluso la possibilita' di usare un approccio misto (.dll C++ in codice C#). Il motivo e' che il core del nostro software sono le classi matematiche che verranno sviluppate in puro C++.

Assumendo che queste quindi non vengano scritte in C# la parte restante sarebbe l'interfaccia grafica.

In C#, come si diceva, si possono fare cose fighe come Ribbon e dockable panels e certo e' + veloce da programmare (stiamo facendo i nostri conceptual mock-ups dell'interfaccia grafica usando appunto C#).

Ma in 14 mesi di progetto la proporzione di tempo dedicata all'interfaccia grafica e' relativa.

Riguardo l'apprendimento non sara' un problema, abbiamo fatto un corso la settimana scorsa e ne faremo uno tra due settimane. Ora ci stiamo focalizzando sulle altre fasi tra cui la non banale specifica dei requisiti e use case. Tralascio dettagli ma il software ha degli use case non banali.

Stiamo a vedere .. alla fine cmq abbiamo parlato tanto di MFC.. ma il'60/70% del codice sara' puro C++. il rimanente C++ con MFC..

grazie a tutti!

[cionci]

Originariamente inviato da Pixel452

A me MFC fa venire i brividi, cmq il tutto IMHO. Direi che a questo punto la vostra scelta l'avete fatta. Buon lavoro!

Anche io rabbrividisco...pensando poi che ci ho lavorato per diversi anni