2014-10-02 17 views
7

QT dường như là bộ công cụ GUI đa nền tảng tốt nhất hiện có. Thật không may, nó là trong C + +, và ràng buộc cho nó với nhiều ngôn ngữ thú vị (như D, Rust, Julia, và Mono trên * nix) hoặc là không có sẵn hoặc không được duy trì. GTK bindings thường có sẵn, nhưng GTK trông xấu xí trên Windows và (đặc biệt) OS X. wxWidgets bindings cũng sẽ được tốt đẹp, nhưng không có sẵn hoặc là bỏ dở cho D, Rust, và Julia (Đối với Julia, tôi có thể đi qua Python cho cả hai bộ công cụ, nhưng đó là chậm và vụng về).Làm cách nào tôi có thể tham gia giao diện QT GUI vào chương trình chính không phải C++?

Làm cách nào để gắn giao diện C++ vào chương trình chính không phải C++?

+2

Quấn thói quen Qt của bạn dưới dạng hàm C; hầu hết các triển khai ngôn ngữ chấp nhận các hàm bên ngoài C. Bạn nghĩ đến ngôn ngữ chính xác nào? –

Trả lời

9

Bạn có một số ít các tùy chọn ở đây.

Trước hết, bạn có thể ràng buộc GUI và ứng dụng chính của mình thông qua API C. GUI thường được thực hiện thông qua callbacks được gọi thông qua một vòng lặp sự kiện, vì vậy bạn sẽ phải trưng ra các hàm trong ngôn ngữ cấp cao của bạn dưới dạng gọi lại C để chúng được gọi từ vòng lặp sự kiện. Sau đó, bạn sẽ cần phải bắt đầu vòng lặp sự kiện Qt. Có nhiều cách để làm điều đó tùy thuộc vào ngôn ngữ bạn sử dụng. Ví dụ, nếu bạn sử dụng Rust, bạn có thể tạo một thư viện tĩnh hoặc động và liên kết chương trình C++ GUI của bạn với nó. Trong trường hợp này, "điểm vào" của chương trình của bạn sẽ là phần C++. Nếu bạn sử dụng một cái gì đó như Julia, có thể bạn sẽ muốn biên dịch phần C++ như một thư viện mà cũng sẽ trưng ra một hàm gọi vòng lặp sự kiện Qt. Vì vậy, trong trường hợp này, "điểm vào" sẽ là phần cấp cao hơn của bạn mà vẫn cần phải gọi lại vào thư viện C++.

Cách tiếp cận thứ hai gần với giao diện người dùng web hơn. Bạn có thể làm cho GUI của bạn trở thành ứng dụng khách cho ứng dụng chính được viết bằng ngôn ngữ khác. Họ có thể trao đổi tin nhắn thông qua một số giao thức hiện có, như HTTP, hoặc bạn có thể thực hiện giao thức riêng của bạn trên một TCP ở mức độ thấp hoặc kết nối UDP, hoặc bạn có thể sử dụng "trung cấp" Thư viện thông điệp như ZeroMQ hoặc nanomsg. Bạn cũng có thể cân nhắc việc xóa Qt hoàn toàn và chỉ cần viết một ứng dụng web, với chương trình của bạn như một máy chủ web. Đây là cách đa nền tảng nhất để viết GUI bây giờ, tôi đoán :)

+0

Cách tiếp cận thứ hai có phải là tốt nhất nếu tôi muốn xem xét giao diện người dùng như một thành phần mô-đun có thể được viết lại sau này (chẳng hạn như giao diện và cảm giác tự nhiên)? – Demi

+0

@Demetri, tôi tin là có, vì nó sẽ được tách rời hơn so với các ràng buộc C trực tiếp. –

+0

Vì vậy, với tất cả các tùy chọn này, sự khác biệt về tốc độ (trong điều kiện truyền dữ liệu từ GUI đến phần phụ trợ, xử lý phụ trợ để chuyển kết quả trở lại GUI để hiển thị) là gì: 1. GUI và Backend trong cùng ngôn ngữ và C++) 2. GUI và Backend bằng ngôn ngữ khác (nói C++ Qt/Julia) 3. Webapp nơi GUI được hiển thị trong trình duyệt, với chương trình là máy chủ Điều gì sẽ là cách tốt để cấu hình các tùy chọn này? – Asy

Các vấn đề liên quan