Cambalache is a new RAD tool that enables the creation of user interfaces for Gtk and the GNOME desktop environment, it’s main focus is on the newly released Gtk 4 library but it has been designed from the ground up to support other versions.
It started as a proof of concept data model for Glade meant to try out all the crazy ideas I had during the years about how a clean model should be.
A few months later I had a pretty good data model that matched GObject type system quite well and did not depend on GtkBuilder nor GObject.
The model could:
- Import and export multiple UI at once
- Support plain (no custom tags) GtkBuilder features
- Packing/layout properties
- Undo / Redo stack
- History command compression and grouping
With that in mind one late night while holding my newborn daughter in one hand, I decided it was time to put it to test so I fired up Glade with the other hand and started a GUI prototype which quickly evolved into Cambalache, as my few dozen Twitter followers can assess. @XjuanAr
At this point the GUI supported most of the data model features.
One big difference with Glade is that Cambalache supports multiple UI in the same project so you need to ‘export all’ in order to create them as you can see at the end of the screencast bellow.
At this point I had a very specialized XML editor but… there is always a but, what about the workspace? the place where the UI is shown, rearranged, edited…
For the workspace my requirements are:
- It should look and feel as close to the real UI as possible
- Support multiple toolkits (Gtk 3, 4, 2 if really needed, libreoffice?)
- Out of process to avoid loosing data on an eventual crash
- It should look and feel as close to the real UI as possible, really!
Obviously adding the widgets directly like we did in Glade would not work if we want to support more than one version of Gtk since you can not mix them in the same process.
So we need a way to render widgets in a different process and show them somehow in the workspace… GtkPlug/GtkSocket would only work on X11.
Merengue enters the picture!
Fortunately this was not the first time I had to deal with such problem (See Maxwell) this reminded me of Alexander Larsson’s excellent project called Broadway a Gdk backend for the web. Ideally I would use an embedded Wayland compositor widget instead of a webview and broadway, but unfortunately there is only an old non working prototype called Wakefield and finishing it is a project on its own. In any case replacing the webview with a wayland compositor widget would be trivial.
Merengue is the name of the process Cambalache uses to render the UI while the user creates it, it is a regular Gtk 3 or Gtk 4 application depending on the version your project is targeting that just connects to Broadway and talks to the main application in JSON trough stdout/stdin pipes.
I will be talking more about Cambalache and the rationale behind starting a new project instead of porting Glade at GUADEC
See you there!
UPDATE: Cambalache source code released under the LGPL 2.1, get it here!
24 thoughts on “Merengue: Cambalache’s workspace”
Hi Juan Pablo!
Compliments ! That’s an astounding improvement toward Glade (which I found wonderful BTW).
I’m looking forward to test Cambalache on a real project ASAP!
Thanks for all
Thanks, I think it will be but only time will tell.
Looks great ! Is there a public repository available ?
Not yet, Its unreleased, I have to decide on a license first
Just wondering, would it be possible to drop xml in favor of json?
That is a question for Gtk developers but if GtkBuilder is going to be replaced it has to be with something with a clear advantage over XML.
Why do you think JSON would be so much better?
Being easier to write is not a valid reason IMO because nobody should be writing UI files by hand anyways, not code not xml not even json.
I would prefer a binary format that does not require parsing.
It’s unlikely we’ll ever switch GtkBuilder to JSON. UI definition files are still human writable, which means they should allow comments—something that JSON does not have.
I tried using JSON for UI definition files in Clutter, and in the end it did not offer any real advantage over XML. The same applies to YAML, by the way.
That reminds me I need to save comments when importing files.
The only thing I can think of it would be nice to have is a binary format you can use in gresource to avoid parsing each time you instantiate an object but it is probably a micro optimization in most cases
still a nice thing to have
The main cost is definitely *not* in parsing the XML, but in the object creation. It doesn’t really matter what kind of format you use.
What about Qml derivative?
Qml goes in the direction of a full DSL, which means adding a parser *and* an execution environment for that language. That’s usually a bigger can of worms than a simple serialisation format.
At this point, I’d rather do what Android and Microsoft do: an XML dialect (like XAML) that you can edit without going completely mad, and a GUI tool that manipulates it.
The problem is not XML vs JSON (extended JSON that allows comments).
The problem is the way XML is used in Gtk, it’s insanely verbose,
In a GUI editor, we should always allow textual modifications, but it shouldn’t be neither of them.
The UI should use a specialized widget description language that gets loaded and saved into normal XML.
Some kind of indentation style YAML with an easy way to specify the properties. This language need to be developed first as there is none yet. And than the text editor component must get the same convenience functionality that code editors have with intellisense.
There is a lot of ideas possible if people finally start to think out of the box. Way too few people do.
GtkBuilder format comes from the first Glade (Gtk 1) file format, it was never intended to be written or read by a human, the fact you can “easily” edit it is just a nice side effect of using XML.
Making yet another description language to save as XML does not make too much sense, in that case you can always load the new language directly.
Anyways like you said lots of ideas are possible, but saying is easier than doing…
How about compatibility with Glade?
Can it open .glade files properly?
Is there any “upgrader” or gtk4-builder-tool is preferred?
You can import glade files into Gtk3 projects, but currently the main focus is Gtk4 support.
So it will take some time before it has feature parity with Glade.
There is not upgrade logic, so people should use the tools provided by gtk
I do not know how smart the update tool so I have no idea if Cambalache can make a better job but at least I will add the option to run the tool for you
When will it be released!?
I will make a development release around GUADEC
Thanks for your work!
Looking forward to giving this a go, looks promising
Hi, any chance to see this program on Flathub.org?
Yes, I just did not had the time to do it.
I think I will try to add it in the beta channel for the moment
There is nothing on the Layout section, after creating GtkWindow, GtkGrid.
I want to organize the positions of labels, buttons, … with GtkGrid
ops, yeah that is a regression.
Fixed in main branch
FYI you can file bugs at https://gitlab.gnome.org/jpu/cambalache