In GTK projects, what is the difference between a '.ui' file and a '.glade' file? - gtk

I'm just starting with development of GTK applications, and took a look at some tutorials along with source code of established projects, and while tutorials designing interfaces use Glade to output '.glade' files, I see source code utilizing '.ui' files.
What is the difference here?

The file extension has no meaning and is best to ignore it but .ui is probably the more reasonable one for you to use though.
Historically Glade used to provide its own format to design UIs and thus .glade was used. Many years ago GTK integrated its own solution called GtkBuilder and Glade was updated to also support this format. No maintained project in 2020 should be using the glade format but many people and old projects likely still use that file extension because the Glade save dialog still defaults to it I believe.

Related

Why does current glade modify the UI generated by a old glade?

I'm trying to modify sligthly the https://gitlab.com/robru/gottengeography/-/blob/master/data/gottengeography.ui file, which was created with (supposedly) glade in 2012, but when I open and save it (without modifications) in my ubuntu 20.04 system (my glade is 3.22.2-1), the UI I get in the python-gtk3 app is quite different from the original one.
I need a way to apply some very little modifications, but glade saves it as a (supposedly) quite different file.
Could the new glade have some incompatibility with the file generated by the 2012 one?
What should I do in order not to loose the UI which is interpreted now?
This is a known bug in Glade (and is the reason why some GNOME developers hold the opinion you should not use it).
Unfortunately, there is at the moment very little to do about it. There are some projects that are in the making to manage UI files for GTK4, but I don't know of any effort to backport it to GTK3.
I'm afraid at this point the best you can do, is to just manually edit the XML files in your IDE to do what you want.

How to put a class-diagram under version control?

I want to upload a class-diagram to a public repository on GitHub.
Is there any tool which is considered to be a convention for this purpose?
Currently, I am using Google Docs, from which I can export a PDF.
Someone has suggested for me to use https://www.draw.io/, from which I can export an XML (which would be a lot more suitable for version control, since it is pure text), but I don't know whether or not this tool is "well accepted" across the community.
All versions control systems work with text files. PDF is not a text file. Forget it. It is the same as putting exe files under version control. VCSs work with source files, don't forget this.
All diagrams editors has inner representations of diagrams in some sort of text file. Eclipse UML editors use XML. So, the versions control systems can easily take these files and work with them.
The problem comes when you have conflicts. You will have to resolve them reading and understanding the inner language of the diagram representation. It could be very difficult.
So, it is possible, but try to minimize the conflicts.

Human editable snippet store in eclipse

I am looking for a easier way to manage my eclipse code snippets. I know and have used Eclipse's template and snippets features. But as far as I have found, they can only be exported and imported as XML files.
Since I use many versions of eclipse and I keep migrating between machines managing the snippets is a hassle. I am looking for a UltiSnips like method to manage these snippets/templates. Is there one?
I also looked at snip2code, but it didn't appeal to me because I sometime work offline. Also, I want to have much greater control over the snippets using version control.
Oh well! I couldn't find anything that matched the set of requirements I had. So, I've ended up creating my own.

Computer-assisted translation for GWT recommendations

We are looking for a suitable solution to translate our GWT application collaboratively. We have a bunch of constants and messages property files that need to be translated by different people. Till now we've emailed the files and manually merged the translated content back which obviously doesn't scale very well.
Is there any tool (preferably an open source project) you can recommend that does play well with the i18n support of GWT and allow for collaboratively translation?
There is a Google Language API for GWT
I hope this doesn't sound like spam, but we built Amanuens, which is a web-based tool designed exactly to solve the problems you're having.
I'm not into GWT, but I assume that you have .properties files. If so, then our solution should work fine (although it's not open source).
It doesn't look like there is a GWT optimized solution for supporting the translation process of .properties files.
We are currently evaluating Pootle. It is easy to use (especially for non-techies), supports the translation process in many ways, supports user management, is open source and lets you import and export property files easily (which is important for integrating with GWT).

In Gtk, when is it better to use Glade/GtkBuilder than native code?

Glade helped me get started on a project quickly, but I've found it harder to maintain in the long run, and I'm thinking about switching it all to native code. In what circumstances would you choose glade, and when would you use native code?
I would personally only use native code for performance reasons. I find it much easier to work with gtkbuilder. Have you used glade or gtkbuilder? With Glade 3, gtkbuilder format is easy to use and easy to layout and design. Also, gtkbuilder is easier to load widgets from than glade was.
if by native code you mean "direct GTK calls to build ui", then i'd switch to it for several reasons:
if widgets are built dynamically depending on user preferences, etc
if i use a lot of custom widgets, esp. contained within each other (for example GDL docking panels)
to maintain backwards compatibility with older version of GTK
upd: also i'm still using glade2.x which has code generation (patched it to compile against latest gtk2). it really helps to get quickstart on "gui build from code", and works with both ancient and newer GTK versions. though i'm afraid i will have some troubles porting to gtk3 :)
and i never choose gtkbuilder over other alternatives, 'cause it is not available in (still widespread) older GTK versions.. dunno if i'll ever switch to it.. maybe when gtk3 comes out.