If you are starting out with GTK development, you may have heard of a tool called Glade. Glade is a UI designer application for GTK projects, that allows you to create, modify, and preview UI files before writing code. In that sense, Glade is a very useful tool for GTK apps.
With that said, I must implore that you do not use Glade.
Why? Glade was built for it’s own format, before the advent of
GtkBuilder. It does not know certain properties, does not know
of certain features, and does not know modern GTK practices.
Instead of ignoring what it does not know, it aggressively “corrects” it. Glade will re-write your UI files to its whims,
including but not limited to:
- Removing property bindings
- Removing unknown properties
- Adding child properties to GtkBox children everywhere
- These are gone in GTK 4, which adds extra work to the porting process
- Adding explicit GtkViewports that cause a double-border
- Forcing minimum width and height on GtkListBoxRows
- Re-arranging objects within the UI file
- Changing the format of all properties in an edited UI file
This makes Glade harmful in different ways. Your UI files will be bloated, due to Glade adding placeholders, child properties,
and extra widgets where they aren’t needed. When you make a
contribution to an app, you may be asked to re-do it by hand
because Glade made unnecessary changes. When porting to GTK 4 you
will need to do more work, as Glade doesn’t know to avoid
deprecated widgets, properties, and child properties.
All of these elements combine to make Glade more harmful than helpful. So please, do not use Glade. If you are working with UI
files write them by hand. An editor with code folding and syntax
highlighting can be very helpful. If you need to mock something
up, you can try sketching on a piece of paper or using our
mockup resources. Whatever you choose, don’t use Glade.
Hey Chris!
It is really frustrating what you are writing about.
How do you expect someone in 2020 to do UI with a text editor using xml?
Instead of “don’t use Glade” because you think it is a piece of shit, how about GTK people do something about Glade not being so shit?
For example.. with every release of a GTK version how about updating Glade to also support everything properly what GTK does?
The GTK developers are focused on making GTK the best it can be, and are not the developers of Glade.
I don’t think Glade is a “piece of shit” – I just do not recommend it for new developers or new code because
it will cause issues.
It cannot be the best it can be if you do not provide people the tools to use your best it can be GTK.
If someone wants to use your best it can be GTK and you say the only way to design a UI is to have your text editor and edit tens of xml files by hand, then people will just say fuck this, and will use something else where they don’t have to fuck round in xml.
It’s easy to shit on Glade instead of – as I said before – helping/cooperating with them.
So either GTK people create a working UI tool or start making patches in Glade so everyone can be happy and use a proper tool to create their UIs.
I understand your frustration – trust me. I think it just requires someone to start feeling motivated to write it. I know Christian Hergert and I’ve spent a lot of time talking about what a interface builder should look like. The current model of how glade works is absolutely the wrong UX experience to begin with.
With man power limited, it’s difficult to find people willing to write something of that nature – writing an interface builder is not exactly something one can do easily.
From here there two ways, if you are frustrated with this situation – you can either start that project or project lead and attract people to write one. It’s not as hard as you think – it just requires someone with organizational experience to get such a project off the ground. I’ve started two initiatives this way and it can happen.
A UI designer is table stakes for a major toolkit. It is required. If the GTK devs aren’t interested in being a major toolkit, they should just admit it instead of expecting others to make GTK viable for them by starting another project that will eventually get the exact same treatment as Glade. Nobody on the outside, much less trying to get involved for the first time, is going to be motivated to get involved in cleaning up this mess, not when the project clearly thinks hand-editing xml (my god) is good enough.
Let me try to clear something up: I am not a GTK developer. I am an app developer who uses GTK, trying to warn other developers who may want to use GTK. Glade is not the right tool for the job, and does more to harm both app developers and library developers than it does to help app development.
I apologize for the confusion but in that case you’re fighting not merely a losing battle, but the wrong one.
The consequence of people following your advice not to use Glade will be to further isolate GNOME/GTK from the rest of the ecosystem and wider industry — a problem it’s already been struggling with for years due to its persistent resistance to feedback, even if it hasn’t admitted it to itself yet.
You should be imploring the GNOME/GTK devs to fix Glade or replace it, quickly, not telling others not to use the only tool apparently available. The former has some chance of fixing the problem. The latter would eventually just kill GTK entirely.
This whole discussion upsets me. But more particularly XML for UI upsets me. This seems more like a web development approach than a programmer approach. GUIs require programming to get intended behaviour. While we may not favour Glade for beginners, using a markup language in a text editor hardly solves that problem. In short, I agree with you and include my own viewpoint.
You make it sound as if using XML is a requirement. It isn’t. If you want to write your GUI by code, then do that. I think Vala is a great language for it. But sometimes, declaring the tree of components can be more useful than implementing it in code. That doens’t _replace_ code, you know. You still code your GUI, just not the instantiation and parenting aspects of it.
This sounds like the XY problem. Problem X is the output of glade. Fixing that will be some measure of effort. But glade exists, has “brand awareness”, and users.
Problem Y is your complaint about how glade functions from a UX point of view. Solving that is a different measure of effort, and I contend, a far larger amount.
Luckily it’s orthogonal entirely to problem X. So please don’t characterise Y as being a blocker to X, when it isn’t.
> How do you expect someone in 2020 to do UI with a text editor using xml?
You just confused literally millions of web developers who write their UI’s in text editors.
IMHO drag and drop UI development is a big no-no
Is this about the Glade format as such or just about the Glade tool?
How about the UI designer in gnome-builder?
Sort-of both. The Glade format is outdated, and the GtkBuilder format should be used instead. The UI designer in gnome-builder is based on Glade and has the same issues.
Then we should work on a UI editor for gnome builder that uses GtkBuilder, right?
PS: Please use the Reply button, otherwise it is hard to follow the thread.
I can’t even find this GtkBuilder format specifications. That is, what I found looks like what glade outputs; but when I asked on the gtkmm mailinglist why it didn’t work (the radio buttons in a popup menu don’t work) they had no clear answer and among others pointed me to this webpage. I’d be happy to NOT use glade and mock up an xml by hand if I knew HOW. You do you have an url that explain exactly what GtkBuilder is supposed to understand when using new_from_file()?
Where would I go to learn how to write .ui files?
I’m pretty unfamiliar with GTK app development and have had a difficult time getting into it for a while now. Everything I’ve learned about .ui files has come from reading the ones generated by glade and then a lot of thoughtful guessing.
I also don’t recommend Glade for GTK development.
But Glade is used also by LibreOffice for example, they have their own catalog of widgets. So I think that with a custom catalog, Glade is fine.
However, as a developer I don’t like GtkBuilder. XML is not a great language to edit by hand, many developers agree with this statement. But even if Glade was great for GtkBuilder, I think that I would still prefer to write code instead of having a separate XML file for the UI. Because with code it’s more powerful: instead of repeating things in the XML file, you can write a function and call that function multiple times, to have re-usable code. Another benefit is that the app loads faster with code only (but this should not be the main reason to choose to write code versus using GtkBuilder XML files).
So, should the points of action be:
– Deprecate glade in favour of Gtk builder
– Address these issues in Gtk builder
I’m a casual user of gnome since year dot and not sure I’d remember to use builder over glade if I decided to build something in Gtk next year.
Glade isn’t developed by the GTK developers, so they can’t “deprecate” anything related to it.
These issues don’t exist within the GtkBuilder format, but the Glade tool and things based on it.
The new version of Glade got even worse, hid all widgets and became more difficult to develop. It should be rewritten and made similar to Qt Designer, intuitive and with auto-complete of member functions and parameters, such as slot and dynamic signal.
Isn’t there AKIRA to replace Glade?
AKIRA is a designer, but not in the sense of a UI designer. The output produced by AKIRA cannot be used to develop a GTK app.
No, Akira doesn’t produce ui files, it’s for creating design files and exporting to formats like PDF
Akira is prototype tool (Like Sketch, Adobe Xd)
Inevitable bit rot?
I’m actually surprised by the fact that people still use WYSIWYG and in this case Glade. Is that really common?
I’ve learned that written code or markup in the native language is more reliable an efficient in long term. The modern usage of Latex or Markdown are incredible examples of parsers/compilers and how to do it. Markdown even for the case of making it easy.
On the other side I see GtkInspector which is integrated and understands the actual Gtk library and it used widgets through introspection. GtkInspector is a wonderful tool. Maybe that is a direction for the future of an possible UI editor? But I don’t know if that has also it drawbacks.
PS: I remember that webbrowser originally should have been HTML Editors and not just Viewers. The integrated inspectors of modern webbrowsers are so far just a shadow.
For me, Glade became really stable over the last years. (Big thanks to the pople that worked on that!) If it wouldn’t have been for Glade, I probably wouldn’t be working on GTK based projects. It’s not only the entry barrier. It’s also because I’m doing this for fun and I enjoy the quick visual feedback.
I also noted minor things like “Forcing minimum width and height on GtkListBoxRows.” It’s a very strange default (that should be easy to remove in Glade code), but it’s not really an issue and not at all enforced.
I’m not sure what you mean with “modern GTK practices,” but I would imagine that an empty XML files also knows very little about moder GTK practices 😉 To some extend it’s even worse, because there are very little resources about the builder format.
I would like to change to GTK4 rather sooner than late. But it’s quite likely that I will wait a while if GTK4 support in Glade is in sight before manually touching a .ui-file. I understand that this is not an option for all projects. But I would appreciate it if you would also consider the option that ‘just write XML’ isn’t the solution that fits all. Even in an opinionated peace.
Hahahahaha, if you weren’t convinced GTK developers don’t love to shoot themselves in the foot. Posts like these don’t encourage anyone to use your toolkit, but then again you’ve been removing useful functionality from it for years so as to make it impractical.
It’s absolutely disturbing that Glade, which is also part of the GNOME project and a great enabler for developers, is not developed alongside Gtk, making sure it works flawlessly.
Really, there should be no reason to do in code anything that is visible on the UI, and, on the contrary, it would make code much more maintainable (do you really think that migrating dozens or hundreds of lines of UI code is more amenable to upgrades with language bindings or Gtk evolution than migrating a .ui
XML file?).
OpenOffice / libreoffice use this kind of tools because they’re complex applications.
I’m afraid that we’re going to throw the baby with the water, again.
You really need to consider of the tone of your words here. “do not use glade” is something people will keep saying for years even if Glade fixes all of the problems listed.
As suggestions for better posts:
– Contact the active developers of Glade (they have been very responsive to my bug report) and discuss it with them.
– Reword this as a call for action, inspiring people to improve Glade, or write an alternative.
An entirely negative post like this does get more attention, but it doesn’t lead anywhere positive.
The GTK ecosystem has a learning curve problem, and a tool like Glade helps a lot with it. It’s probably the least glamorous work as only developers ever get to see it, but it improves the entire ecosystem.
The tone and the message direction… so true!!!
Became more pissed at the writer than the program I love designing GTK UIs. Its’ open source software..! There’s a wide open door to call for potential contributors attention.
Saying Glade’s outdated with reasons, that’s OK.
But “do not use” and code-by-hand? I’m not listening.
Several years ago, when Gitorious was still a thing, I ported RipperX to GTK3 for fun (at the time it was GTK 3.1 or something like that). The original C code was (still is) a big jungle of UI code. I used Glade and it was a great boon. Before the GNOME IDE, Glade represented (to me) a cornerstone tool in development with GNOME technologies. Today the IDE even includes it. To recommend against this graphical UI builder is certainly the wrong direction, and the hand editing of XML an abysmal alternative.
same as your car engine.
The fact that “The GTK developers are focused on making GTK the best it can be, and are not the developers of Glade.” is the problem. Of you develop a Graphical toolkit you MUST develop a graphical builder for that, not to blame other individuals who tried to cover up your mess!