Re: GTK and OSX: a call to sanity

[John Ralls <jralls ceridwen us>]

On Sep 7, 2011, at 2:10 AM, Milan Bouchet-Valat wrote:

> Le mardi 06 septembre 2011 à 16:34 -0700, John Ralls a écrit :
>> I'm not going to respond to most of that.
> I think you shouldn't take Emmanuele's tone so bad. ;-)
> He's always very direct, but his point is right, and his suggestions are
> actually the acknowledgment that your work is worth being part of core
> GTK - they are meant to help you. I'm going to try telling things in a
> slightly nicer fashion...
> 
>> Suffice it to say that building gtk-osx is largely automated, and
>> there are well-tested instructions at
>> http://sourceforge.net/apps/trac/gtk-osx/wiki/Build
> That's not the question. This page should be on live.gnome.org, because
> that's where we assume docs are, and people with an account there can
> give a hand.

Well, you know what they say about "assume", but OK. That's probably the easiest task on the list, though I think GnomeLive and Trac Wiki use some different notation so there would be some work reformatting unless someone knows of a ready-made translation program somewhere.

> 
>> I didn't get commit privs at Gnome.org until just under a year ago, 18
>> months after I took over from Richard. I still don't have privs on any
>> of the other facilities except Bugzilla, and there only because I'm a
>> Gnucash Dev. (That turns out to be sufficient for almost everything.)
> Maybe it took some time, but in my experience getting privileges is very
> fast. Anyway, now you have everything you need to work on gnome.org,
> don't you?

No.
I have commit privs on git.gnome.org, and dev privs on bugzilla (not through Gtk+, though). I would need to make binaries available on ftp.gnome.org and to have a support mailing list (which I haven't requested, so that's not anyone's fault. I did request privs for ftp.gnome.org at the same time I requested git commit privs, but that wasn't granted.)

> 
>> Gtk-OSX needs its own mailing list because it provides jhbuild
>> modules for over 100 separate projects, not all of which are even
>> Gnome. It's not feasible for me to monitor all of them for support,
>> nor is it reasonable for users of my build scripts to have to figure
>> out which one to use for any particular problem.
> So maybe you need a separate mailing list for helping building these
> programs, but it could live on gnome.org. For GTK+ development itself ,
> the present list is the natural place, like Emmanuele said.

And the fact that I'm here shows that I agree. Shawn was here (until Olaf kicked him off this morning) for the same reason. I'm quite aggressive about pushing problems about whatever module to the appropriate bug tracker or mailing list. (In most cases, that's gtk-app-devel rather than gtk-devel for gtk.)
> 
>> It's not a fork of Gtk+ (yet, though on days like this one I get
>> really tempted). I actually revived the gtk-osx project on SF; the
>> previous version was an actual fork of Gtk1.
> So let's improve things a step more, and completely merge the project.
> Sounds like the natural end of the story. :-)

Merge which project with what? The actual build project could be merged with jhbuild, but it's not a simple dropin and would need to be discussed. Where should that discussion take place? Here?

I could create projects for ige-mac-bundler and ige-mac-integration (though they should probably be renamed to gtk-mac-foo) on git.gnome.org, but unless I can upload the tarballs it doesn't do me much good. gtk-quartz-engine is already on git.gnome. 

On the other hand, bundling is part of building, so bundler could be folded into jhbuild. Ige-mac-integration is an add-on to Gtk that (rather tortuously) puts the menus on the mac menu bar and provides access to the Dock menu for Gtk applications. I think it could be integrated into Gtk+ (I haven't tried) but since some app devs like to keep the menus on the windows, it should probably be a runtime option.

Two other pieces, gtk-osx-docbook and gnome-doc-utils-fake, could be combined under a "mac support" directory of jhbuild. They don't need much maintenance (I haven't needed to touch either of them since I got them from Richard), but their tarballs need to be hosted somewhere.

Bugs are another issue. If the build portion gets merged with jhbuild, then I'd say there should be an "osx" component there to receive gtk-osx bugs. (There haven't been many.)

The webpage could be moved into gtk.org, though I don't think it should go under "downloads" as that conveys rather the wrong impression. Some assembly (no, not that kind ;-) ) definitely required. It would take a bit of cleanup to make it look like the rest of the Gtk website; more important, it would need to be converted to php, and I have zero knowledge about how to do that.

> 
>> As I explained earlier, the changes *are* patches, they *are* attached
>> to bugs in Bugzilla, and Kris Reitveld *has* promised to review them.
>> When he has had time to do so and they have been polished to his high
>> standards, they will be committed into mainline.
> If you need Kris to review your patches before committing them to
> mainline, then the usual way is to have a branch in the GTK git
> repository, and rebase it into master when it's accepted. That's much
> easier for everybody, much better than putting them on a different repo.

I've been doing that for a year, and those branches are part of what set Emmanuele off in the first place. He doesn't like the constant merges with mainline that are necessary to keep them current.

> 
>> In the meantime they're quite useful for a number of projects who want
>> a better Mac experience for their users than the Gtk core devs seem
>> motivated to provide.
> *This* is a different issue. If reviewers cannot keep up with your
> patches, and you need to release tarballs that include code not in
> mainline, that means gtk-osx isn't yet fully merged into GTK. But,
> disregarding the fact that it would probably be good that everything
> goes to mainline in time, putting your gtk-osx special branch on in the
> GTK repository instead of SF would be a good thing.

They are in the Gtk repository. Emmanuele just said that they shouldn't be, that it's a private fork misusing Gtk's good name. So which is it? Do I delete the branches from Gtk and move them to SF or Github like Emmanuele wants, or do I leave them in?


Getting all of this done is a fair amount of work, and I'm already spread rather thin. 

Regards,
John Ralls