Re: gdk threads ...

[Benjamin Otte <otte gnome org>]

Michael Meeks <michael.meeks <at> suse.com> writes:
> 
> The unfortunate thing about
> this design is that every toolkit user gets to re-write a bus-load of
> boiler plate stubs & skels and link them into every application. Why not
> do that, just in a better way, inside the toolkit ? 
> 
(Disclaimer: This is my personal opinion and is in no way related to the opinion
or future API design of GTK or GNOME - though I try to influence both.)

I've spent a bit of time thinking about the general "why doesn't the framework
give us the means to do X?" questions as well as the actual use case of
libreoffice. And I think the answer to your question is "the code should be
where the problem is" and as your threading model is the problem, the code
should be with you. You should be the one motivated to improve things and reduce
code, not GTK.

Libs in the general GNOME vicinity have historically taken the "let's export all
the features we have" approach. You can set everything everywhere. And if you
can't, there sure is a signal that you can hook into, capture things and do it
your way. On the opposite side, libraries like Cairo have taken a different
approach: A minimal API and very few ways to hook into the system and influence
what is actually happening.
I think we should move GNOME closer to the Cairo approach. Reduce the amount of
API. You can read http://ometer.com/free-software-ui.html for why that's a good
idea. Just replace UI with API and user with developer in that article.

Now what does that mean for applications that use these APIs that are going to
be removed? They're doing the same thing the users do when their preferences get
removed: They either change the way they do things, they stick to the old
version for as long as possible or they switch to something else. And in the end
I'm pretty sure everyone in GNOME-land will be happy to help LO become a great
GNOME application.
(What I'm not so sure about is GNOME people being happy to maintain hacks for
apps that want to use GNOME as a portability layer for a platform they define.
And that goes for LO in the same way as it does for Mozilla.)

Benjamin