Hi,
I would like to propose that we have a policy where any commits that touches the Glade file, must either contain the file's contents after saving it through the Glade's UI or include a commit that follows it with the noisy diff produced by Glade. The problem is, we all keep hand-editing to avoid crappy diffs, but it gets more and more out of sync with Glade and makes it even worse for the next guy.
Even right now it's impossible to make a change using Glade without breaking our custom icons that were added by hand[1] and Glade doesn't support writing their icon-names[2]. If the person making the changes is also the one to save the noisy Glade XML diff - even if as a separate commit after the clean hand-edit - then at least it's their own problem right away when something breaks and not left for the next sucker down the road who has non-trivial changes to make using Glade GUI :)
Or do we just want to abandon Glade and stick to hand-editing the 10,000 line GtkBuilder XML file?
P.S. Are we all still agreed to using old 3.8.1 version of Glade? I think this idea of using same version sounds good, at least we won't be causing additional noise in diffs due to different versions writing stuff out in different ways.
Thoughts?
Cheers, Matthew Brush
[1] https://github.com/geany/geany/commit/dabae1f94f13a85b672746aa0a177d3534048d... [2] https://bugzilla.gnome.org/show_bug.cgi?id=700652
On 12/09/2013 01:38, Matthew Brush wrote:
P.S. Are we all still agreed to using old 3.8.1 version of Glade? I think this idea of using same version sounds good, at least we won't be causing additional noise in diffs due to different versions writing stuff out in different ways.
One might hope so, but 3.8.1 causes massive noise, see: http://lists.geany.org/pipermail/devel/2012-January/006418.html
I've just seen 3.14.2 is available for windows though.
On 13-09-18 09:07 AM, Nick Treleaven wrote:
On 12/09/2013 01:38, Matthew Brush wrote:
P.S. Are we all still agreed to using old 3.8.1 version of Glade? I think this idea of using same version sounds good, at least we won't be causing additional noise in diffs due to different versions writing stuff out in different ways.
One might hope so, but 3.8.1 causes massive noise, see: http://lists.geany.org/pipermail/devel/2012-January/006418.html
Yeah, that's why I was saying maybe we should do like we (ideally) do with the geany.txt file; make the changes and commit the text changes, and then as a separate commit, generate the HTML and commit the noisy one. If we did this, at least we could be sure that it won't be the next person who edits the file's job to figure out if saving the file will break it (like it will at present if anyone tries to edit it with any version of Glade).
I've just seen 3.14.2 is available for windows though.
In my experience, after Glade 3.8(.X) it got *much* worse; very very much slower with big files like geany.glade, and crashing so much I had to get into the habit of saving after every single action. I think I only tested up to 3.10 though, so it might've stabilized since the massive GTK3 disruptions in its code base.
Cheers, Matthew Brush
On 18/09/2013 21:36, Matthew Brush wrote:
P.S. Are we all still agreed to using old 3.8.1 version of Glade? I think this idea of using same version sounds good, at least we won't be causing additional noise in diffs due to different versions writing stuff out in different ways.
One might hope so, but 3.8.1 causes massive noise, see: http://lists.geany.org/pipermail/devel/2012-January/006418.html
Yeah, that's why I was saying maybe we should do like we (ideally) do with the geany.txt file; make the changes and commit the text changes, and then as a separate commit, generate the HTML and commit the noisy one. If we did this, at least we could be sure that it won't be the next person who edits the file's job to figure out if saving the file will break it (like it will at present if anyone tries to edit it with any version of Glade).
OK, that'd be a good practice. But that won't help get small diffs ;-) Glade 3.8.1 likes to rearrange things randomly IME.
On Wed, 11 Sep 2013 17:38:58 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
P.S. Are we all still agreed to using old 3.8.1 version of Glade?
After 2.x, I'm using Glade only to generate object templates in a test file, and edit the real glade files with Geany. It's much easier.
Thoughts?
3.6.7 does not generate noise in the form of default properties and attributes. It does reorder the size gropus, but Geany uses none. So, this version can possibly be used to cleanup geany.glade. A diff -uw is ~8k lines, 90% of which are removed default properties/attributes.
It's not good for visual editing, though, since sometimes the hbox and vbox display is swapped, :) and "Add widget here" is disabled quite often, for reasons unknown.
No 3.x version is any good IMHO, so we may just mark geany.glade with the first version that supports all objects we are using, and _change our policy_ to "edit with Geany". That's what we do anyway.
Am 12.09.2013 02:38, schrieb Matthew Brush:
Hi,
I (as a unregular contributor) would love to be able to use glade.
To sum the problem up: - As long as we're still on GTK+ 2.x we won't be able to use upstream Glade (Geany on GTK+3 is fine, btw, thanks for that work). - Worse, only a few older versions work. - And even more worse, you can't practically interchange glade versions because the generated .xml tends to be ordered differently (I, myself, don't care about that but I understand it makes viewing commit diffs harder). - And the worst, you need to hand-edit the .xml to fix up the icon-names stuff.
Is this summary correct or did I miss anything?
The following could solve/workaround our situation:
1) Find the version which works best (stable .xml generation) 2) Fork this and integrate it into the Geany tree. Since we don't follow upstream I expect it won't be a mantainance problem. 3) Fix the icon-names thing (assuming one of us is capable to do so) 4) Declare that only our glade copy can be used to change the UI. Also declare that this is strictly for use with Geany and we don't accept bug reports if people use it for other things. 5) Only change the code in our glade copy if we find it struggles with Geany's UI (we don't need to care about other projects) or to make it build on newer distros.
Basically I'm suggesting that we set a glade version in stone which is capable of handling our UI generation and make it mandatory for all contributors. By integrating into the Geany tree it's easy to find and we can make sure it keeps working.
Is there a problem with this approach?
Best regards.
On Wed, 02 Oct 2013 17:01:09 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
To sum the problem up:
- As long as we're still on GTK+ 2.x we won't be able to use upstream
Glade (Geany on GTK+3 is fine, btw, thanks for that work).
- Worse, only a few older versions work.
This would have been a problem if the new versions were better, which is questionable, to say the least.
- And even more worse, you can't practically interchange glade
versions because the generated .xml tends to be ordered differently (I, myself, don't care about that but I understand it makes viewing commit diffs harder).
Not only. Some versions emit some properties and/or element attributes even if they have the default or non-applicable values. For example, our Glade current version, whichever it may be, mass produces property can_focus, property use_action_appearance and signal attribute swapped.
- Fix the icon-names thing (assuming one of us is capable to do so)
The icon creation should be possible with ~15 gtk_icon_*() calls, or simply by including the icon factory xml fragment in the source and invoking gtk_builder_add_from_string(). The attachment shoudn't be a problem either.
- Declare that only our glade copy can be used to change the UI.
Basically I'm suggesting that we set a glade version in stone which is capable of handling our UI generation and make it mandatory for all contributors. By integrating into the Geany tree it's easy to find and we can make sure it keeps working.
Wait, we had this! A 2.x version which was stable, and even generated C code. So we didn't need to distribute an extra 625KB .xml file, load it on startup, and abort if it doesn't exist. And IIRC, the executable was only a few percent larger.
I know, I know, we won't revert to the old Glade, because the progress is such a progress, and whoever (Matthew?) wrote the builder code must be proud if it because it emulates Glade 2.x ui_lookup. So internally we use 2.x, except for some (find / fif) dialogs, which are constructed with code... Am I the only one which sees some other problems here?
Is there a problem with this approach?
Our Glade version will become outdated, and we'll replace it with the new best thing, because it's <strike>the best</strike> new and shining. That's the human nature. :)
Is there a problem with this approach?
That means when the minimum version of GTK is increased we will have to upgrade to version of Glade that supports the new widgets that come with the new GTK. And then apply the fixes. So along with lack of windows maintenance (please lets deprecate it) we now have Glade upgrade issues slowing the movement of GTK versions.
Cheers Lex
Best regards. ______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 03.10.2013 02:00, schrieb Lex Trotman:
Is there a problem with this approach?That means when the minimum version of GTK is increased we will have to upgrade to version of Glade that supports the new widgets that come with the new GTK. And then apply the fixes. So along with lack of windows maintenance (please lets deprecate it) we now have Glade upgrade issues slowing the movement of GTK versions.
Ok I see you try to avoid anything which could possible mean more maintenance work, even if only in theory :)
Anyway, the glade version needs only to be updated if we also make use of newer widgets _and_ don't implement them programmatically. This seems like a very rare event, and even then applying fixes is as easy as git rebase. For the vast majority of time our set-in-stone, fixed Glade can be used without extra effort.
But you need to see it from another POV: Doing this enables us, and more importantly new and fresh contributors, to use Glade for the Geany UI. This clearly outweighs the very little extra maintenance effort. And I would argue that this even reduces maintenance effort overall since we don't have to worry about geany.xml anymore.
Best regards.
On 6 October 2013 22:21, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 03.10.2013 02:00, schrieb Lex Trotman:
Is there a problem with this approach?That means when the minimum version of GTK is increased we will have to upgrade to version of Glade that supports the new widgets that come with the new GTK. And then apply the fixes. So along with lack of windows maintenance (please lets deprecate it) we now have Glade upgrade issues slowing the movement of GTK versions.
Ok I see you try to avoid anything which could possible mean more maintenance work, even if only in theory :)
Anyway, the glade version needs only to be updated if we also make use of newer widgets _and_ don't implement them programmatically. This seems like a very rare event, and even then applying fixes is as easy as git rebase. For the vast majority of time our set-in-stone, fixed Glade can be used without extra effort.
But you need to see it from another POV: Doing this enables us, and more importantly new and fresh contributors, to use Glade for the Geany UI. This clearly outweighs the very little extra maintenance effort. And I would argue that this even reduces maintenance effort overall since we don't have to worry about geany.xml anymore.
Well, I am wondering how much change is going to happen to the UI within the life of Geany on 2.x? But if you think there are major changes to be made then I understand the attraction of using Glade rather than editing XML (shudder).
Its not just using different versions either, some versions of Glade seem to delight in producing noise no matter how little you do :(
So I guess the first step would be for you to identify a Glade version that produces a file that both GTK2 and GTK3 Geany correctly read and that doesn't produce lots of noise each change. Then you need to make the modifications you mentioned.
Without knowing that such a Glade exists the whole question is theoretical :)
If it exists then its certainly a possible solution.
Cheers Lex
Best regards. ______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Lex Trotman elextr@gmail.com schrieb:
On 6 October 2013 22:21, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 03.10.2013 02:00, schrieb Lex Trotman:
Is there a problem with this approach?That means when the minimum version of GTK is increased we will have
to
upgrade to version of Glade that supports the new widgets that come
with
the new GTK. And then apply the fixes. So along with lack of
windows
maintenance (please lets deprecate it) we now have Glade upgrade
issues
slowing the movement of GTK versions.
Ok I see you try to avoid anything which could possible mean more maintenance work, even if only in theory :)
Anyway, the glade version needs only to be updated if we also make
use of
newer widgets _and_ don't implement them programmatically. This seems
like
a very rare event, and even then applying fixes is as easy as git
rebase.
For the vast majority of time our set-in-stone, fixed Glade can be
used
without extra effort.
But you need to see it from another POV: Doing this enables us, and
more
importantly new and fresh contributors, to use Glade for the Geany
UI. This
clearly outweighs the very little extra maintenance effort. And I
would
argue that this even reduces maintenance effort overall since we
don't have
to worry about geany.xml anymore.
Well, I am wondering how much change is going to happen to the UI within the life of Geany on 2.x? But if you think there are major changes to be made then I understand the attraction of using Glade rather than editing XML (shudder).
Its not just using different versions either, some versions of Glade seem to delight in producing noise no matter how little you do :(
So I guess the first step would be for you to identify a Glade version that produces a file that both GTK2 and GTK3 Geany correctly read and that doesn't produce lots of noise each change. Then you need to make the modifications you mentioned.
Without knowing that such a Glade exists the whole question is theoretical :)
If it exists then its certainly a possible solution.
Cheers Lex
Best regards. ______________________________**_________________ Devel mailing list Devel@lists.geany.org
https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I thought we already determined such a version (3.8.1?) which gets it almost right except for the icon-names issue?
Best regards
Am So, 6.10.2013, 15:39 schrieb Thomas Martitz:
Lex Trotman elextr@gmail.com schrieb:
On 6 October 2013 22:21, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 03.10.2013 02:00, schrieb Lex Trotman:
Is there a problem with this approach?That means when the minimum version of GTK is increased we will have
to
upgrade to version of Glade that supports the new widgets that come
with
the new GTK. And then apply the fixes. So along with lack of
windows
maintenance (please lets deprecate it) we now have Glade upgrade
issues
slowing the movement of GTK versions.
Ok I see you try to avoid anything which could possible mean more maintenance work, even if only in theory :)
Anyway, the glade version needs only to be updated if we also make
use of
newer widgets _and_ don't implement them programmatically. This seems
like
a very rare event, and even then applying fixes is as easy as git
rebase.
For the vast majority of time our set-in-stone, fixed Glade can be
used
without extra effort.
But you need to see it from another POV: Doing this enables us, and
more
importantly new and fresh contributors, to use Glade for the Geany
UI. This
clearly outweighs the very little extra maintenance effort. And I
would
argue that this even reduces maintenance effort overall since we
don't have
to worry about geany.xml anymore.
Well, I am wondering how much change is going to happen to the UI within the life of Geany on 2.x? But if you think there are major changes to be made then I understand the attraction of using Glade rather than editing XML (shudder).
Its not just using different versions either, some versions of Glade seem to delight in producing noise no matter how little you do :(
So I guess the first step would be for you to identify a Glade version that produces a file that both GTK2 and GTK3 Geany correctly read and that doesn't produce lots of noise each change. Then you need to make the modifications you mentioned.
Without knowing that such a Glade exists the whole question is theoretical :)
If it exists then its certainly a possible solution.
I forked glade at github and made two fixes to it: [1]
- fixed the unstable output (mostly) - fixed stripping of "icon-name" attribute of GtkIconFactory. It's still not editable in the GUI but it glade at least shouldn't remove it anymore from existing XML
Seeing that 3.8.x is maintained actively at upstream I will try to get the changes upstream. For the first fix I already opened [2].
Please see if it makes glade usable for us. It worked in my (limited) testing.
Best regards.
[1] https://github.com/kugel-/glade/tree/glade-3-8-fixes [2] https://bugzilla.gnome.org/show_bug.cgi?id=709609