Minutes of the GTK+ meeting at GUADEC
- From: Kristian Rietveld <kris gtk org>
- To: gtk-devel-list gnome org
- Subject: Minutes of the GTK+ meeting at GUADEC
- Date: Tue, 27 Jun 2006 14:42:09 +0200
Hey,
We had a GTK+ meeting in person at GUADEC last Sunday. Below are the
minutes (or really just the notes I took).
-kris.
----
GTK+ Meeting, 25 June 2006, GUADEC7
-----------------------------------
* 2.10 is basically done, we are aiming for a release next week.
* Tommi asks whether the GTK+ development/maintainer team is big enough.
Matthias and Tim both answer that the team has been too small for the last
few years, everybody else seems to agree.
* Planning 2.12, possible new features:
- Canvas, and we need off-screen rendering for that.
# At least 3 different candidate canvases around.
# Some ideas from Soeren; immediate mode, callbacks. He will write up
his ideas and send it to the list for discussion.
# Defining the feature set for a canvas is really difficult, though
most people agreed that GnomeCanvas does cover most of the features
needed by general applications.
# Might want to look at the new canvas in Qt 4.1.
- Introspection
- GtkBuilder, the libglade integration into GTK+.
- The new tooltips API.
- Maemo.org patches
# Menu patches,
# Input method,
# Tap and hold.
- International calendar support
# GLib patch is about ready,
# After that the GTK+ widget (GtkCalendar) needs some fixing up.
- Support for editable multi-line labels, probably by extending GtkEntry.
- libsexy cherrypicking
# Support having an icon in the entry.
# Input masks.
- Recent file code updates
# GtkRecentAction.
# GtkFileChooser integration.
* Matthias continues on Tommi's previous question on maintenance, mentioning
the OS X backend. Micke and Richard explain that the backend is mostly
working, but does need some bug fixing. It's marked as still experimental.
* The file chooser API does have some issues. For example the backend API
is private, and getting the model from the file chooser dialog is impossible.
Also the code for supporting the pluggability of the UI does not work/has
not been tested at all.
* We decided to target the GTK+ 2.12 release on January '07. This should give
us enough time to put all new features in. If we decide to include a
canvas with GTK+ 2.12, we might have to depend on a new release of Cairo.
According to Carl Worth the next releases of Cairo are pretty much "open".
They will probably focus on performance for the next release. Making a new
release for supporting some special canvas features should be feasible.
* We get interrupted by some guys of the board. Jeff speaks about having the
GTK+ project join the GNOME foundation. The foundation can provide
help to the GTK+ project with financial and administrative tasks. It has
been doing this for the GIMP project already, which has been working fine
so far. The foundation does not get any influence on the technical
decisions made by the GTK+ team. Also, the plan is to get a press release
out on this.
* The board leaves and the core team pretty much decides that doing this
is not bad at all, and the only thing that needs work is the wording in the
press release. Nobody appears to be against.
* The topic of GTK+ 3.0 was brought up after this. 3.0 would be an API and
ABI breaking release. The team decided that we would like to avoid breaking
API since a lot of companies invested into GTK+ 2.x and expect that it'll
be supported for some more years.
Most of the team seems to agree that we want to get rid of the cruft in
the 2.x series, some of which is still sticking around from the 1.x series.
Matthias mentions that FC6 will not ship with GTK+ 1.x. (People cheered
and Tim complained about he won't be able to run xmms then).
The idea of introducing compiling subsets was brought up. We could set up
a make system where the full library or only a subset is built, for example
omitting all the old stuff and the printing support. The people using
GTK+ on embedded devices would be really happy if we implemented something
like this.
If we want the compiling subsets to work, we need to make sure that none
of the internal code is using deprecated widgets.
Breaking API is not really something we really want to do soon. If we ever
do it, we want to do it right so it can last for at least a couple of years.
Also, we would prefer the development on 3.0 to happen in parallel with
2.x development. Alex brought up the idea of creating a bug which we can
use to track all issues which require breaking the API, so we get a
formalized list of stuff which needs API breakage.
According to Tim breaking the ABI is not a real problem, since distributions
and also for example the Maemo.org platform can just be recompiled.
* Tim also mentioned that Michael Meeks has been working on optimizing
shared library loading optimization in OpenOffice.org. We wondered if
there's anything we can do to improve GTK+'s performance in this area. As
Michael was unable to attend Tim and/or Matthias will try to have a talk with
Michael about this.
As there was nothing left discuss, we decided to close the meeting.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]