2014-10-02 10 views
7

QT sembra essere il miglior toolkit dell'interfaccia grafica multipiattaforma disponibile. Sfortunatamente, è in C++ e le associazioni per esso a molte lingue interessanti (come D, Rust, Julia e Mono su * nix) non sono disponibili o non sono mantenute. I binding GTK sono solitamente disponibili, ma GTK sembra brutto su Windows e (soprattutto) OS X. I binding wxWidgets sarebbero anche carini, ma non sono disponibili o non sono mantenuti per D, Rust e Julia (Per Julia, potrei passare attraverso Python per entrambi i toolkit, ma questo è lento e goffo).Come posso unire una GUI QT a un programma principale non C++?

Come posso associare la mia GUI C++ a un programma principale non C++?

+2

Avvolgere le routine Qt come funzioni C; la maggior parte delle implementazioni linguistiche accettano le funzioni esterne C. A che lingua stai pensando? –

risposta

9

Hai una manciata di opzioni qui.

Prima di tutto, è possibile collegare la GUI e l'app principale tramite l'API C. Le GUI vengono solitamente eseguite tramite callback che vengono richiamate attraverso un loop di eventi, quindi sarà necessario esporre le funzioni nella lingua di alto livello come callback C per poter essere richiamate dal ciclo degli eventi. Quindi sarà necessario avviare il ciclo di eventi Qt. Ci sono molti modi per farlo in base alla lingua che usi. Ad esempio, se si utilizza Rust, è possibile creare una libreria statica o dinamica e collegarvi il programma C++ GUI. In questo caso il "punto di ingresso" del tuo programma sarà la parte C++. Se usi qualcosa come Julia, probabilmente vorrai compilare la parte C++ come una libreria che esporrà anche una funzione che chiama il loop di eventi Qt. Quindi in questo caso il "punto di ingresso" sarà la tua parte di livello superiore che dovrebbe comunque richiamare nella libreria C++.

Il secondo approccio è più vicino alle UI web. Puoi rendere la tua GUI un client per la tua app principale scritta in un'altra lingua. Possono scambiare messaggi attraverso un protocollo esistente, come HTTP, oppure implementare il proprio protocollo su una connessione TCP o UDP di basso livello, oppure è possibile utilizzare la libreria di messaggistica "di livello medio" come ZeroMQ o nanomsg. Puoi anche considerare di eliminare completamente Qt e di scrivere semplicemente un'app Web, con il tuo programma come server web. Questo è il modo più multipiattaforma per scrivere una GUI ora, suppongo :)

+0

Il secondo approccio sarebbe il migliore se volessi considerare l'interfaccia utente come un componente modulare che potrebbe essere riscritto in seguito (ad esempio per aspetto e aspetto nativi)? – Demi

+0

@Demetri, credo di sì, dal momento che sarà più disaccoppiato rispetto agli attacchi C diretti. –

+0

Quindi, con tutte queste opzioni, quali sono le differenze di velocità (in termini di passaggio dei dati dalla GUI al backend, elaborazione backend alla restituzione dei risultati alla GUI per il rendering) quando: 1. GUI e backend nella stessa lingua (ad esempio Qt e C++) 2. GUI e backend in lingua diversa (ad esempio C++ Qt/Julia) 3. Webapp in cui la GUI è stata resa nel browser, con il programma come server Quale sarebbe un buon modo per profilare queste opzioni? – Asy