2014-10-02 24 views
7

QT wydaje się być najlepszym wieloplatformowym zestawem narzędzi GUI. Niestety jest w języku C++, a jego powiązania z wieloma interesującymi językami (takimi jak D, Rust, Julia i Mono on * nix) są niedostępne lub nie są obsługiwane. Wiązania GTK są zwykle dostępne, ale GTK wygląda paskudnie na Windowsie i (szczególnie) OS X. Wiązania wxWidgets również byłyby miłe, ale nie są dostępne lub nie są przeznaczone dla D, Rust i Julia (dla Julii, mógłbym przejść przez Python dla oba zestawy narzędzi, ale jest to powolne i niezdarne).Jak mogę dołączyć do GUI QT do programu głównego innego niż C++?

Jak mogę powiązać mój GUI C++ z programem głównym innym niż C++?

+2

Owiń swoje procedury Qt jako funkcje C; większość implementacji językowych akceptuje funkcje zewnętrzne C. O jakim języku myślisz? –

Odpowiedz

9

Masz tu kilka opcji.

Przede wszystkim możesz powiązać swój GUI i główną aplikację za pomocą C API. Graficzne interfejsy użytkownika są zwykle wykonywane za pośrednictwem wywołań zwrotnych wywoływanych przez pętlę zdarzeń, więc będziesz musiał odsłonić funkcje w języku wysokiego poziomu jako wywołania zwrotne C w celu ich wywołania z pętli zdarzeń. Następnie musisz uruchomić pętlę zdarzeń Qt. Istnieje wiele sposobów, aby to zrobić w zależności od używanego języka. Na przykład, jeśli używasz Rust, możesz utworzyć statyczną lub dynamiczną bibliotekę i połączyć z nią swój program w języku C++. W tym przypadku "punktem wejścia" twojego programu będzie część C++. Jeśli użyjesz czegoś takiego jak Julia, prawdopodobnie będziesz chciał skompilować część C++ jako bibliotekę, która również eksponuje funkcję, która wywołuje pętlę zdarzeń Qt. Tak więc w tym przypadku "punkt wejścia" będzie twoją partycją wyższego poziomu, która nadal będzie musiała oddzwonić do biblioteki C++.

Drugie podejście jest bliżej interfejsów WWW. Możesz ustawić GUI jako klienta dla głównej aplikacji napisanej w innym języku. Mogą wymieniać wiadomości za pośrednictwem niektórych istniejących protokołów, takich jak HTTP, lub możesz zaimplementować własny protokół przez połączenie TCP lub UDP niskiego poziomu lub możesz użyć biblioteki komunikatów "średniego poziomu", takiej jak ZeroMQ lub nanomsg. Możesz także rozważyć całkowite zrzucenie Qt i napisanie aplikacji internetowej z programem jako serwerem WWW. To jest najbardziej wieloplatformowy sposób pisania GUI teraz, tak myślę :)

+0

Czy drugie podejście byłoby najlepsze, gdybym chciał wziąć pod uwagę interfejs użytkownika jako modułowy komponent, który może zostać przepisany później (np. Dla wyglądu i stylu natywnego)? – Demi

+0

@Demetri, uważam, że tak, ponieważ będzie bardziej oddzielony od połączenia niż bezpośrednie wiązanie C. –

+0

Więc z tymi wszystkimi opcjami, jakie są różnice prędkości (w zakresie przekazywania danych z GUI do zaplecza, przetwarzania backendu do przekazywania wyników z powrotem do GUI do renderowania), gdy: 1. GUI i Backend w tym samym języku (na przykład Qt i C++) 2. GUI i Backend w innym języku (powiedzmy C++ Qt/Julia) 3. Webapp, w którym GUI jest renderowane w przeglądarce, z programem jako serwerem Jaki byłby dobry sposób na profilowanie tych opcji? – Asy