https://bugs.documentfoundation.org/show_bug.cgi?id=163947
Michael Weghorn <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om, [email protected] --- Comment #8 from Michael Weghorn <[email protected]> --- (In reply to Juan Pablo Ugarte from comment #6) > Hi, Cambalache author here. > > So, I do support Gtk3 so you should be able to edit all the UI files. > > Now gtk 3 support has lower priority so you will find issues for sure, > please file bugs. Thanks a lot for all help! > BTW with some extra work we can make Cambalache actually use libreoffice > toolkit. > > whats the name of the toolkit? LibreOffice's own widget toolkit is called VCL ("Visual Class Library"). As I understand it, with the so-called "weld" approach, the idea is generally that UI files use the GTK 3 (GtkBuilder) UI file format and those cannot only be turned into VCL widgets, but also native widgets of other toolkits. The weld API (include/vcl/weld.hxx) provides an abstraction over the actual toolkit in use. For example, LibreOffice's gtk3 variant ("gtk3 VCL plugin") on Linux uses GTK's GtkBuilder to create native GTK widgets from UI files for most of the UI. On the other hand, VCL widgets (which are created by VclBuilder which parses the .ui file itself) are used for everything on Windows. (LibreOffice has different platform integrations/plugins depending on the operating system/desktop environment.) With that in mind, I'm wondering if there's actually a need to add specific support for the VCL toolkit in Cambalache, or the "standard" GTK 3 support would generally be sufficient as long as LO uses the GTK 3 GtkBuilder file format? What's might be of interest is that while native GTK widgets are used for *most* of the UI with GTK, there are cases where they are not (yet?). I'm neither familiar with those, nor with the custom widgets which this ticket mentions. Maybe others can provide more input/background here? [CC'ing Caolán and Hossein who may have more insights] I've e.g. seen that the VclBuilder ctor takes a `bLegacy` flag, and that the `NotebookBar` ctor unconditionally creates a VclBuilder instance with `bLegacy=true`. So that use case doesn't seem to support the weld approach. Don't know whether that's "just not implemented yet" or not meant to support welding at all. (I could imagine that *if* this "legacy" path uses non-standard UI files that GtkBuilder could not handle, that might require special handling.) > does it support wayland? (I assume it does or that it will soon) AFAICT, that's somewhat decoupled from the widgets defined in UI files, because other toolkits are also involved in the process of rendering and for platform integration. The gtk3/gtk4/qt5/qt6 VCL plugins support Wayland thanks to the underlying toolkits (GTK/Qt); IIUC, the top-level windows there are always GTK/Qt ones, even in the case where widgets inside of the top-level window are VCL widgets and drawn "manually". (There's also a "gen"/"x11" VCL plugin using X11 calls directly, that one doesn't support Wayland.) > are there python bindings for it? While there are Python bindings for the LibreOffice UNO API, these are not really bindings for the VCL toolkit or weld API. -- You are receiving this mail because: You are the assignee for the bug.
