Re: GNOME: lack of strategic roadmap

[Philip Van Hoof <pvanhoof gnome org>]

On Wed, 2010-02-24 at 09:03 +0000, Martyn Russell wrote:
> On 23/02/10 22:52, Philip Van Hoof wrote:
> > On Tue, 2010-02-23 at 16:53 +0000, Martyn Russell wrote:

Hi Martyn,

> > Don't be confused: most of this reply isn't directed at you personally.
> 
> Sure, but I will indulge all the same ;)

That's ok ;)

I'll be cutting the text a bit.

[CUT] (see?)

> We aren't waiting for anything :) But you can't refactor exposed public 
> struct pointers which are in common use since you break the API and any 
> application using that structure.

I think it's time for a few major API breaks in Gtk+, and why don't we
start doing more development of core components (like Gtk+) in Vala?

I bet it would make things a lot more easy for contributors. I remember
that at a hackfest in Berlin that it was proposed to have IDL files that
describe the API. 

Vala's VAPI files' syntax was proposed for this. With GIR (introspection
XMLs) much of this problem is also solved, of course.

Anyway, all this stuff is for the maintainers to decide. Of course.

> The GSEAL work is an initial step to make this refactoring process
> easier.

GSEAL is great, yes. (thank you Lanedo)

[CUT]

> > I don't believe that GTK+ needs more cleaning up. Its architecture isn't
> > that flawed at all.
> 
> But that's your opinion as someone who is not and has not been a 
> maintainer. Talking to the maintainers is actually how I formulated my 
> opinion.

Yes (Gtk+ isn't a very exciting project to join, which is I think part
of the problem here).

[CUT]

> I think NASA had a lot more people working for them than the GTK+ 
> project and the GSEAL work is quite comprehensive.

Now what if we'd make Gtk+ a more exciting project to join? :-)

psst. Vala (I'm not saying it's the holy grail, but it is exciting)

> At one point Imendio labs time (1/2 a day per week) was used by the
> whole company for some months to JUST do sealing and we are still
> not quite done.

Thank you Lanedo! (the new Imendio)

> > I think it's untrue to say that GTK+ needs more years of cleanups before
> > it can start receiving innovation.
> 
> Innovation can always be done, but if each time you want to do it you 
> really want to refactor the code base before you start, that dampens 
> your efforts and costs time to work around.
> 
> Tracker is no different here. It has had a lot of clean ups before it 
> started getting any innovation.

That's true, fair enough. We did, however, innovate Tracker in parallel
with the massive cleanups that we did. And we're still in that process.

I call Tracker 0.7 and upcoming 0.8 an entirely new product than 0.6

[CUT]

> At some point you have to clean up your code base, that's been the case 
> in every project I have worked on. I don't think it is a bad thing that 
> GTK+ is released just "more cleaned up", but others disagree and want 
> 3.0 to have x, y and z major new features.

Yeah, I guess I'm one of those guys ;)

Or, if 3.0 is going to be GSEAL and cleanups: to start with 4.0 and
drastically innovate, change and develop it (and don't fear API changes
anymore at all) and throw 3.0 in maintenance. Same for GLib & Gdk.

Kinda like how the 1.x -> 2.0 transition was. I think 2.0 was great for
Gtk+, and I think Gtk+ needs another one of those innovative periods.



Cheers,


Philip

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be