We have a Glade catalog for custom widgets: extras/source/glade/libreoffice-catalog.xml.in The catalog input file is manipulated by extras/source/glade/makewidgetgroup.xslt and the final .xml ends up as instdir/share/glade/libreoffice-catalog.xml The makefile is extras/CustomTarget_glade.mk Glade is not maintained anymore, so we should look into Cambalache as a future tool for UI design. https://gitlab.gnome.org/jpu/cambalache Cambalache supports catalogs since version 0.92: https://blogs.gnome.org/xjuan/2024/09/26/new-cambalache-release-0-92-0/ Example catalogs can be seen in: https://gitlab.gnome.org/jpu/cambalache/-/tree/main/catalogs Cambalache looks for the catalogs in ~/.cambalache/catalogs I assume the catalog has to be created by hand and/or with the help of xslt. Cambalache catalogs are normally expected to be produced automatically by a cmb-catalog-gen program from .gir files generated by g-ir-scanner, but I don't think that workflow applies in our case.
I tend to agree with this request, given that Glade is no longer maintained. However, I feel that there might be some risks migrating to Cambalache. Since Cambalache introduces a lot of Gtk4 widgets, how would it play out with our current weld/builder?
(In reply to Rafael Lima from comment #1) > I tend to agree with this request, given that Glade is no longer maintained. > > However, I feel that there might be some risks migrating to Cambalache. > Since Cambalache introduces a lot of Gtk4 widgets, how would it play out > with our current weld/builder? We will see. If there are issues, hopefully we can work with the Cambalache developer to come up with a solution.
Created attachment 197695 [details] The LibreOffice catalog converted to a Cambalache project file (by Cambalache developer) Juan Pablo Ugarte kindly created this catalog. First attached to https://gitlab.gnome.org/jpu/cambalache/-/issues/248
(In reply to Buovjaga from comment #0) > Glade is not maintained anymore, so we should look into Cambalache as a > future tool for UI design. > > https://gitlab.gnome.org/jpu/cambalache I generally agree. I got some errors when trying to open some "random" LO .ui files in Cambalache in the past, but didn't look into it further. If anybody has the time to investigate/experiment further, I think that would be great. (In reply to Rafael Lima from comment #1) > However, I feel that there might be some risks migrating to Cambalache. > Since Cambalache introduces a lot of Gtk4 widgets, how would it play out > with our current weld/builder? As I understand it, Cambalache's goal is to support both, GTK 3 and GTK 4, in which case we could stick with our GTK 3 .ui files (and widgets) for now. (i.e. we could decouple the question of whether we want to switch to the GTK 4 .ui file format at some stage from the question of whether we use Cambalache.)
FTR, from #libreoffice-dev IRC chat: [09:36] <michaelweghorn> buovjaga: do you know whether cambalache also works on non-linux? (I just noticed some wayland-related dep when building from source recently, didn't check whether it's optional/only needed on linux) [09:45] <buovjaga> michaelweghorn: it definitely looks Linux-only and Wayland-only
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. BTW the file attached by Buovjaga is not a catalog file, its a cambalache project with some libreoffice classes defined in it which should let you import a file using those classes. Cambalache catalog format is not very friendly to edit manually, its basically a dump of sqlite tables. It is created from Gir files and the runtime objects with cmb-catalog-gen script you can see examples at catalogs/Makefile in cambalache source tree. But is should be fairly easy to add an option to load glade catalogs. I created https://gitlab.gnome.org/jpu/cambalache/-/issues/249 to eventually add libreoffice support. BTW with some extra work we can make Cambalache actually use libreoffice toolkit. whats the name of the toolkit? does it support wayland? (I assume it does or that it will soon) are there python bindings for it? thanks Also Cambalache currently is not natively supported on Windows, but it works with WSL2
(In reply to Michael Weghorn from comment #5) > FTR, from #libreoffice-dev IRC chat: > > [09:36] <michaelweghorn> buovjaga: do you know whether cambalache also works > on non-linux? (I just noticed some wayland-related dep when building from > source recently, didn't check whether it's optional/only needed on linux) > [09:45] <buovjaga> michaelweghorn: it definitely looks Linux-only and > Wayland-only Hi, its not wayland only, it uses a custom wayland compositor internally to embed out off process windows but the app itself is a regular Gtk4 app and supports all the backends. It does not work natively on windows yet, because I have not even tried to build it. but I know people are using it with WSL2. The main blocker before was building webkit gtk on windows, but now that is not needed anymore, the blocker now is building wayland+wlroots I have not tried on Macos either but I guess it should easier than windows
(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.
(In reply to Michael Weghorn from comment #8) > 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.) Yeah, we just use the gtk3 .ui file format with normal common gtk widgets nearly everywhere. And on gtk3 we just use gtk to load and generate gtk widgets for us, while on the non-gtk3 platforms we have our own .ui file loader that generates vcl widgets from the .ui file. But, yes, the notebookbar ones, like sw/uiconfig/swriter/ui/notebookbar.ui etc use the gtk .ui format, but with custom widgets like "sfxlo-NotebookbarToolBox" "sfxlo-DropdownBox" "VclOptionalBox" and a whole zoo of other weird and wonderful custom (generally just container?) widgets (that I don't know why exactly exist or what difference they are from some more 'normal' widgets). And for those the bLegacy flag is used on loading to ensure they are created from vcl widgets even for the gtk front end. The glade catalog of those notebookbar widgets is very minimal and just maps them to some pre-existing similar gtk widgets for the purpose of making it easy to move parts of the notebookbar around in glade.
Ahh cool, I did not knew it was using native widgets I was under the impression that all widgets where from VCL I think for now it would be better to keep using it as a gtk 3 project just keep in mind that its possible to support customs toolkits now. We can do a quick call some day if you want to brainstorm the different possibilities. btw is https://github.com/LibreOffice/core/blob/3959d5bddafb61bcd50613d6c6453a2d6fe370b7/extras/source/glade/libreoffice-catalog.xml.in the only catalog you need?
(In reply to Juan Pablo Ugarte from comment #10) > I think for now it would be better to keep using it as a gtk 3 project > just keep in mind that its possible to support customs toolkits now. That sounds good, thanks. > We can do a quick call some day if you want to brainstorm the different > possibilities. I probably can't contribute much besides what I've already mentioned here, and imagine the "special cases" (for which I don't know the details myself) are probably the most interesting to discuss, but I'm happy to join a call if there's going to be one at some point. > btw is > https://github.com/LibreOffice/core/blob/ > 3959d5bddafb61bcd50613d6c6453a2d6fe370b7/extras/source/glade/libreoffice- > catalog.xml.in the only catalog you need? Others might be able to say more, but I also don't see any other catalog and `git grep glade-widget` also doesn't show anything interesting. (In reply to Caolán McNamara from comment #9) > But, yes, the notebookbar ones, like sw/uiconfig/swriter/ui/notebookbar.ui > etc use the gtk .ui format, but with custom widgets like > "sfxlo-NotebookbarToolBox" "sfxlo-DropdownBox" "VclOptionalBox" and a whole > zoo of other weird and wonderful custom (generally just container?) widgets > (that I don't know why exactly exist or what difference they are from some > more 'normal' widgets). And for those the bLegacy flag is used on loading to > ensure they are created from vcl widgets even for the gtk front end. > > The glade catalog of those notebookbar widgets is very minimal and just maps > them to some pre-existing similar gtk widgets for the purpose of making it > easy to move parts of the notebookbar around in glade. After looking into this a little further, the logic indeed seems to be mostly in C++ code, and the preview seen in Glade also doesn't match what you see when actually running LibreOffice. For example, the "sfxlo-NotebookbarTabControl" control in sc/uiconfig/scalc/ui/notebookbar.ui is implemented in a `NotebookbarTabControl` class (sfx2/inc/notebookbar/NotebookbarTabControl.hxx). It seems to be mostly a GtkNotebook with extra widgets left and right to the tabs in the tab bar. IIUC, the GtkNotebook concept of "action widgets" [1] would be comparable, and if I set dummy ones in in Glade, I see extra widgets there. But since the LO .ui file doesn't use them, they're of course not shown in the preview. The VCL version looks quite odd in e.g. gtk4, so I wonder whether welding notebookbar would generally be a desirable goal in the longer run - or whether there's a specific reason for having "our own custom stuff", e.g. to allow Notebookbar customization,...? (The Notebookbar vcl widgets have more interesting special handling, which might need some consideration in case of planning to weld all of these.) Do I understand that that's however a question that's independent of switching to Cambalache and Cambalache would show these special widgets similar to how Glade does when using a corresponding Cambalache catalog? [1] https://docs.gtk.org/gtk3/method.Notebook.set_action_widget.html
(In reply to Michael Weghorn from comment #4) > I got some errors when trying to open some "random" LO .ui files in > Cambalache in the past, but didn't look into it further. If anybody has the > time to investigate/experiment further, I think that would be great. I've now created https://gitlab.gnome.org/jpu/cambalache/-/issues/250 with one sample file that still fails for me with current Cambalache git main.
hi, yes Cambalache should behave similar to Glade with the corresponding Catalog. What is attached here is a Cambalache project with the same types as the glade catalog defined as templates. This lets you use all those widgets inside the project as if there where in a catalog. The only difference from glade catalogs is that all you can do is define a new type, no properties or signals yet. btw thanks for the report, it should be easy to fix