GNOME Bugzilla – Bug 634961
need to have GTK code generation from the UI file
Last modified: 2010-11-16 03:09:56 UTC
I'm not sure what the rationale was for removing this feature, but I really don't think parsing an XML file should be the one and only way to create GUI widgets at runtime. (Well, building the same GUI in code by hand is possible, but much more time-consuming and brittle compared to Glade.) For packages which are not distributed as part of Gnome, it's very nice to be able to build a monolithic self-contained executable, which "just runs" regardless where you install it, without having to put the .ui file in just the right place. If one has built the UI using Glade, then it seems the only option is to embed the XML in a static const char*, and then load it via gtk_builder_add_from_string, right? I have done that, and it works. But XML is so verbose. In fact using upx I was able to reduce the size of my executable to about 21% of the original size, and that's after applying the usual size optimizations (-fno-exceptions -fno-rtti -Os -fomit-frame-pointer, strip the executable). Please consider putting back the code-generation feature in some future version of Glade, or perhaps writing another tool which generates code from the ui file.
a.) It means you have to eventually edit the generated code which means your project is less maintainable and in some case can never again be modified with Glade b.) People eventually like-it-or-not use the generated code as an example to write their own code c.) You can always use gtk_builder_add_from_string() and include the GtkBuilder xml as a string constant in your compiled executable, you dont need to distribute a separate file (just add a build rule to generate the string constant header at build time). d.) Now GtkBuilder uses a sax style xml parser instead of the old libglade dom style... which was slow and pulled in the heavy libxml2 dependency... so this is no longer an optimization issue (which used to be an argument for embedded developers, but not any more). e.) If you really want generated code, which you surely dont, you can always write a glade file parser that generates your code... I dont recommend it and I wont maintain such a thing inside Glade.
a) How come it works so well with Qt then? I don't plan to edit the generated code. I never need to edit the generated code when I use uic either. b) Well they shouldn't. Just put in a comment that says so. c) Did you read the bug? That's exactly what I did. It still sucks. d) whatever. It's still XML, and it bloats the executable size, and it will never be as efficient as binary code regardless what kind of parser you use. e) Well somebody should write such a thing, that's exactly what I'm asking for. It doesn't have to be inside glade, although I think it would be more likely to stay working if it was maintained in parallel.
(In reply to comment #2) > a) How come it works so well with Qt then? I don't plan to edit the generated > code. I never need to edit the generated code when I use uic either. > > b) Well they shouldn't. Just put in a comment that says so. > We have an ugly history of that, it's a bad side effect. just because you hand people an axe and tell them not to slaughter their kittens with it, doesn't mean they wont. > c) Did you read the bug? That's exactly what I did. It still sucks. > > d) whatever. It's still XML, and it bloats the executable size, and it will > never be as efficient as binary code regardless what kind of parser you use. Sure, and your elaborate profiling information that you posted shows that this load time is really non-negligible... as I can see. A better alternative (where speed is really really a showstopper) was developed (but not released) which was a binary libglade format, however that doesnt fit well with GtkBuilder... anyway that was dropped when slow libglade was dropped. > e) Well somebody should write such a thing, that's exactly what I'm asking for. > It doesn't have to be inside glade, although I think it would be more likely > to stay working if it was maintained in parallel. Anyway, thanks for your concern, go ahead and write one if you want it so badly. I have real issues to fix and no time to address them as it is, there's no grounds to add this complexity to Glade (and no real reason to encourage users to use generated code).
BTW another solution would be to use something other than XML. E.g. a binary analog of XML which has the exact same tree structure, or some other custom GUI-building language which is designed to be efficient to parse. A really easy half-assed solution would be to build in support loading the XML in gz-compressed format from a pointer, rather than it having to be full-blown ASCII. gtk_builder_add_from_gz or whatever... it would make time efficiency worse but would at least help with the space efficiency. And maybe the memory could be freed after the parsing is done.
Right, as I mentioned there was such a binary format developed against the libglade format but cant really be done for GtkBuilder (since gtk widgets themselves already do the parsing work themselves). However if disk space is an issue, adding such a feature to GTK+ is possible... maybe more along the lines of loading from some input stream provided by GIO (where a compression filter can be applied).