[Geany-devel] Glade 3 version?

[Matthew Brush]

On 12/19/2011 05:01 PM, Lex Trotman wrote:
> On Tue, Dec 20, 2011 at 9:19 AM, Matthew Brush<mbrush at codebrainz.ca>  wrote:
>> On 12/19/2011 09:37 AM, Nick Treleaven wrote:
>>>
>>> On 19/12/2011 14:40, Matthew Brush wrote:
>>>>
>>>> On 12/19/2011 05:54 AM, Nick Treleaven wrote:
>>>>>
>>>>> Hi,
>>>>> I tried opening data/geany.glade with the latest Glade, 3.8.1 on
>>>>> Windows. Pressing Save writes a lot of changes to the file, 260 Kb. It
>>>>> seems to be mostly reordering property tag lines for
>>>>> "use_action_appearance".
>>>>>
>>>>> Also, when I added 2 menu items it created duplicate image ids for
>>>>> image1, image2.
>>>>
>>>>
>>>> Not sure what this means.
>>>
>>>
>>> It stopped Geany from starting with an error message about image1 being
>>> defined twice.
>>>
>>
>> I'm not sure why it made duplicate IDs, but I guess we should try and start
>> naming things properly now, at least new stuff we add.  This is what I've
>> been doing since the conversion, but there's still lots of default/crazy
>> widget names in there :)
>>
>>>>> [...]
>>>
>>>
>>>> IMO, if you can't get the changes down to less, it doesn't really matter
>>>> if there's a bunch of noise in the commit, it's not like anyone really
>>>> needs to be able to read it, as long as the commit message describes
>>>
>>>
>>> I disagree no one needs to read it. glade diffs should be reviewed by
>>> the author the same as all other code checkins IMO.
>>>
>>
>> Meh, I tend to think of it as a binary blob.  We can't hand-edit it and
>> Glade is free to do whatever it wants outside of our control.  What's more,
>> the point of using Glade is to avoid having to hand code this 10,000 line
>> XML beast.  That being said (see below) if we can do something to make the
>> commits nicer, I agree we should.
>
> I agree with both of you.  We "shouldn't" have to review generated
> XML, but the GUI doesn't make it easy to tell what was changed in a
> particular commit.  Whilst it is a nice idea to reduce the noise,
> Glade is free to do whatever it wants.
>
> I don't agree with fixing versions of tools, we will get into the same
> situation we were in with Glade 2, using unsupported tools and forcing
> all develpers to use special installs instead of the standard ones.
>

It doesn't even need to be a "hard rule" about version, but we could 
recommend a specific version.  I think Colomban had problems with 3.6 
and obviously 3.10 won't work since it only supports GTK 2.24+, so that 
really only leaves us the 3.8.x versions, and since 3.8.1 is bug fix 
release  of 3.8.0, I guess it makes sense to recommend that.

In a perfect world though we could just open it in whatever Glade 3 
version is installed on the system and it would "Just Work", but I think 
we've all used Glade enough to know that will probably never happen.

>>
>>
>>> I'm hoping that we can standardise on 3.8.1 so we can review diffs and
>>> also avoid adding noise/bloat to the git repo each time someone uses a
>>> different version of Glade than the last commit.
>>>
>>
>> I'm all for this, I can easily remove 3.8.0 and switch to 3.8.1.  It does
>> seem like 3.8.1 is the last "stable" release before our version of GTK+ is
>> not supported anymore (3.10), so it makes sense and is convenient for use on
>> Windows with a binary available.  I guess we should/could note this in the
>> HACKING file or something?
>>
>> <rant>
>> Out of curiosity though, if we want to avoid noise/bloat in the Git
>> repository, why don't we untrack generated files like geany.html which are
>> already available online, in the source tarballs, and in all releases
>> (including win32 IIRC)?  The usefulness of this is pretty slim, one has to:
>>
>> - Be using development version of Geany from Git, and
>
> Which we continualy tell people to try if they have problems
>

Not sure it's the best idea to recommend the average user installs 
"experimental" code as their main Geany version though.

>> - Be unable to read a text file with the very same content, and
>
> The text file doesn't open from f1
>
>> - Have no internet access (for online manual), and
>
> Many people pay for downloads, forcing them to use the online version
> is poor form
>

I'd agree if they didn't already need an internet connection to get the 
source in the first place.  After the first view of the online manual, 
the browser should cache it (I think).

>> - Have no release install or tarball available, and
>
> So long as geany.html is in the daily tarballs, then we can tell
> people to try that instead of Git, but they have to keep getting the
> whole tarball as we make changes, not just git pull.
>

(see below)

>> - Be unable to install a simple Python package to generate the HTML
>
> It is fine to require developers to have the full tool suite, but only
> a small percent of git users are actually Geany developers.  Geany
> itself should not need anything other than what is in build-essential,
> plugins are another story.
>

If you're building from Git, you're a developer in my books (in the 
sense that you've figured out how to track down build-essential, 
libgtk2-dev, use autotools, install to an alt. prefix, etc).  I think we 
could assume they're competent enough to run `sudo python setup.py 
install` (or use their package manager) to install docutils.

>>
>> Just a thought, since I cringe just a little every time I see a commit with
>> this file in it :)
>> </rant>
>
> Filter your commit messages :)
>

You'll never convince me that checking in generated files is a good 
idea.  Best we can hope for is that I'll shut the hell up about it :)

P.S. I will shut up about it now.

Cheers,
Matthew Brush