What do you suggest me to do in order to use wxWidgets instead of Qt?

[raphael10-collab]

What do you suggest me to do in order to use wxWidgets instead of Qt?
What's the smoothest way to proceed?

[morganava]

So there are some dependencies and problems to deal with. Ricochet-Refresh is internally organised into two separate frontend and backend components, but the back-end still depends on Qt types and Qt event loop. (which lives in the frontend layer) to run despite the C API library in libtego. (see: #154 ).

So, we will need a re-implementation of libtego (i.e. a Qt-less implementation of the existing Ricochet-Refresh V3 protocol). Long-term, the plan is to switch to a gosling-based implementation for the Ricochet-Refresh V4 protocol. To ensure backward compatibility between v3 and v4-based Ricochet-Refresh, we should re-implement the v3 Ricochet-Refresh protocol using our tor-interface crate. This re-implementation should exposed similarly as a C static library for integration in a new WxWidgets frontend.

However, if none of this background work interests you, I think a viable path forward would be (presuming you have prior wxWidgets experience) to begin implementing the prototype (wip) designs (using wxWidgets) found here:

• https://github.com/blueprint-freespeech/ricochet-refresh/tree/main/design

Alternatively (if using wxWidgets will be a learning experience), you may aim to start with a wxWidgets-based re-implementation of the current Ricochet-Refresh v3 interface before starting on the new stuff while a Rust-reimplementation of the V3 protocol is developed in parallel.

So to summarise the major (mostly) independent components we need (ignoring new V4 protocol considerations):

• tor-interface-based re-implementation of the V3 Ricochet-Refresh chat protocol using a sans-io style
• C-FFI static-lib wrapper around aforementioned V3 Ricochet-Refresh re-implementation with a similar interface as the existing libtego
• A new C++/wxWidgets re-implementation of the frontend based on the new v4 designs