Re: gdk threads ...

On 05/22/2012 01:56 AM, Benjamin Otte wrote:
Michael Meeks<michael.meeks<at>>  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.

I believe this is quite illogical.

In short, LibreOffice is just one project being highlighted here (and rather a big one at that). I suspect there are many others that won't be writing to this list or know about such changes until it's too late.

I've always believed libraries should do the job that *many* projects would have to re-implement. It just doesn't make sense from a maintenance and bug fixing point of view to have many solutions to the same problem scattered around projects when the common denominator (the toolkit) could do it right for everyone.

This just causes work for everyone.

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

I actually believed we had the opposite approach in most cases, certainly in terms of the UIs for our applications.

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 for why that's a good
idea. Just replace UI with API and user with developer in that article.

I will concede there is usually a sweet spot between *libraries* becoming redundant because they suit all (and suffer performance or other degradation) vs providing enough support for projects using your library. Tracker is a great example of this. The 0.6 versions had APIs which were not powerful enough, so we came up with libtracker-sparql. But, as a result, we now have libraries/frameworks like folks and grilo to provide simpler APIs to get your data.

In the end, you could extrapolate from above that we should have a separate library to deal with LibreOffice's situation, but if you can't actually do that without a patched GTK+, it leaves no choice.

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.

LO is one case. I have written applications which have had to deal with custom even loops working with the GTK+/GLib event loop for their own in-house uses (IPCs, etc). There are just many cases you don't know about.

I advocate async, thread free approaches and think it's a mistake to use threads with any UI, but I think it's a bigger mistake to close the door on projects that have no choice.


Founder and CEO of Lanedo GmbH.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]