"We don't generally use glade for new functionality since glade removes some flexibility and are slowly eliminating the last glade files. Any chance you can make these changes without involving glade?" on http://bundlebuggy.vernstok.nl/bzr-gtk/request/[EMAIL PROTECTED]
I also noted the big diff when I tried to change a tiny thing in the olive.glade, so I saw where this intention came from.
And Kevin noted in a reply to me that he likes the move away from glade since it will make the Windows version a little easier to build.
And I was curious how to make a (py)gtk app without glade and now I know :) Jasper Vincent Ladeuil wrote:
"Russle" == Russel Winder <[EMAIL PROTECTED]> writes:Russle> On Thu, 2008-07-17 at 08:15 +0200, Marius Kruger wrote:>> hi, >> Why you guys are dropping glade?Russle> That was the question on my mind as well. I had been led to believe Russle> that using Glade was more or less mandatory for GTK/Gnome GUI Russle> applications. >> (I have no experience or strong feelings about glate, gtk, etc.., I >> would just like to know out of curiosity and for future reference.) Jelmer and Silvester may better comment, but there are historical reasons. Mainly, glade2 produces xml that is not very friendly for merges (nor easily readable in patches). I experiment with glade3 a bit lately and the xml produced is far more friendly in that regard but still, moving a composite widget into a new container, for example, produces a huge and hardly understandable diff, as opposed to the python code involved if you describe the layout explicitly. I, for one, *prefer* the glade approach, but the consensus was against glade. Vincent
signature.asc
Description: OpenPGP digital signature
-- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
