[bzr-gtk] Branch, Checkout, and Push dialog refactoring

[Vincent Ladeuil]

>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:

    aaron> Vincent Ladeuil wrote:
    >>>>>>> "phanatic" == Szilveszter Farkas <szilveszter.farkas at gmail.com> writes:
    phanatic> To build the same interface, I need to write less
    phanatic> lines of code in Python than in Glade. 
    >> 
    >> Urgh, writing xml instead of using glade, I feel your pain...

    aaron> The other thing is that if you're reading diffs, it's
    aaron> probably nicer to read python code than XML.

That is easier to buy... at first glance.

But reading diffs of UI layouts in python or in xml is hard
anyway. 

Unless we spend some energy to define either strong rules on how
the code should be written or define some adequate widgets to
enforce these rules. We will end up with code that will be
marginally better to read than glade xml (and we will reinvent
many things already available in glade in the process, I'm
afraid).

I find it a little (very little) less hard when I only have to
track the widget names inside XML diffs to know that the diffs
represent changes related to these widgets.

But yes, reviewing those diffs have been painful from day
one.

But it's also the main reason why I choose to not embed bindings
in glade: the interface between the glade file and my code is
only the names (and in some rare cases the types) of the widgets.

I don't pay attention to the rest, interpreting the textual
representation of the packing-implied parameters and containers
hierarchy is definitely not my cup of tea ;)

I know that glade is not perfect (and I can build a list of
weakness without effort), it's just that I still find me more
productive with it than without.

But it's also true that I'm in favor of splitting the unique
olive glade file into multiple glade files, so that there is at
least a chance to understand a glade diff on smaller files ;-)

Anyway, I came late in the game, so I don't want to sound like I
think it's such a bad idea to not use glade. If the team feels
it's better suited to write python code, I can adapt to that.

On the other hand, if the team agree to re-think the decision,
pending some demo from my part, I'm ready for that too, as long
as we defined a smaller enough perimeter*.

      Vincent

*: So that I can answer quickly which implies I don't have to
 spend too much time on it. gannotate for example is not that big
 and I'm already familiar with it.