Hey All,
Just like with GUADEC last year, I took notes again of the GTK+ meeting
we had in person at FOSDEM last weekend. You can find them below. As
always, corrections and additions are most welcome. Since we could not
finish the meeting in time, this would be a good location to continue
the discussions.
-kris.
----------
[Note from the editor: During the actual meeting we did not really stick
to the order found in the agenda. However, I've still tried to follow this
order in the notes below, so the summaries appear in a slightly different
order than actually discussed.
On another note, we were not able to finish the meeting in time. We decided
to continue the discussions on the mailing list, based on these notes.]
GTK+ Meeting, 24 February 2007, FOSDEM07
----------------------------------------
Final agenda:
1. Opening
2. Current state of trunk
3. Devising a new schedule
4. Post-2.12 features
5. GTK+ 3.0
6. General Discussions
7. Question Round
8. Closing
Notes:
1) Everybody agreed upon using the proposed agenda, no items were added.
2) Short recap of the current situation; GTK+ 2.12.0 was supposed to be
released in January 2007. We obviously did not manage to release in time.
During an IRC meeting of the GTK+ team early 2007, we came up with a new
schedule: try to become feature complete during mid-February 2007, release
around mid-March 2007.
The new deadline of being feature complete in mid-February 2007 has also
not been made. Right now trunk contains the following "big" new features:
- Key navigation improvements (notifications for failed keyboard navigation
actions and better support for devices with a restricted set of keys).
- New tooltips API.
- A good amount of small improvements and bug fixes.
Not in trunk at moment of writing:
- GtkBuilder. Most of the code is there. We estimated that getting this
reviewed will probably take 2 months.
- "libsexy cherrypicking". No work has yet been done in this area. It
might be nice to get some items in. Might be possible, since the patches
are probably not that big; but it is not vital to have.
- Recent manager updates. The improvements for integration with the UI
manager are coming along nicely and probably make it to trunk in a couple
of weeks.
People inquired about support for showing a preview of the item
in the recent files list. If we follow the thumbnailer-route, GLib will
need support for MD5 hashes, which is something nice to have anyway.
It might also include moving the thumbnailing code from libgnomeui to
GTK+, this code should be mostly okay for GTK+ already, but possibly
has some threading issues. The definitions for the thumbnailers will
have to be moved out of GConf; a proposal for registering thumbnailers
in .desktop files is already being discussed on xdg-list[1]. People
disputed whether this was a good idea, moving GConf to a lower level
is another option and might be better.
- "Sane" notebook DnD. The support which has been added in 2.10 does
work, but is broken in some respects. People have already been
complaining about this in several blog entries. It is much better to
bring such issues up on gtk-devel-list. This will happen soon, and
a solution is likely to be found in time for 2.12.
When talking about notebooks it was suggested to also add standard API
for adding close buttons on tabs. People seemed to like this idea in
general. It was mentioned that there already is a bug filed for adding
an action_area next to the tabs[2].
- Offscreen rendering. It was promised this would be reviewed real soon
now.
[After-meeting note: the following items were on the original 2.12 list
compiled during the GUADEC meeting, but not discussed during this meeting:
introspection, international calendar support, editable multi-line labels.]
3) Trunk will see some new small features from the Imendio team in the
coming 2 to 3 months. The other items mentioned under 2) are well
underway, but still need a couple of weeks before they are ready. Based
on this and the fact GtkBuilder review probably takes at least about 2 months,
it seems to be a nice plan to be feature complete during mid-May and release
mid-June after a stabilization phase of one month. All features which are
not in trunk at mid-May will be dropped, as we should really release no
later than mid-June. This will be worthy to do at that time anyway, as
trunk will have collected a lot of bug fixes already.
4) The biggest post-2.12 item is definitely the canvas. Because of the
big slip 2.12 has made already, having the canvas in 2.12 as originally
planned is clearly not feasible. The canvas depends on the offscreen
rendering patch, which will hopefully make it into 2.12.
A few different cairo-based canvases have been around for quite some time
now. All of them have a slightly different feature set. If we are really
about to "bless" one of them to become the canvas for GTK+, we should gather
a small introduction to all canvases and discuss those.
It was questioned that since different canvases have different feature sets,
does one really belong in GTK+? The canvas in GTK+ will become the
"defacto standard" and the most commonly used; this might kill any
competing canvases. We should take this into account during the selection
process, and make sure the most common needs will be provided by the
future GTK+ canvas.
For deciding on the most common needs, we need to make up our mind about
what the scope of the canvas should be (compare a canvas which provides
everything an application like Inkspace needs with something more basic).
It was suggested to look at things people are asking for, for example on
cairo-list.
Another post-2.12 item which was mentioned was the possible integration
of OpenGL support. There has been a bug open on integrating GtkGLExt
for a long time[3]; several ideas came up, for example making the API
similar to the current handling of cairo contexts.
5) Some of the GTK+ maintainers are of the opinion that there should be
a point where we should start thinking about getting rid of all the
cruft: deprecated widgets, bad APIs which can't be slightly modified,
etc. This would be one reason for starting GTK+ 3.0, which will break
ABI compatibility. Another reason for breaking ABI is that we are running
out of signal slots, and really need to add more at some point. Currently
there are no plans and there is no movement for GTK+ 3.0; similarly, there
is not much movement in GNOME 3.0 either. Maybe GLib/GTK+ 3.0 should be the
first to start thinking about a plan to move to 3.0.
The notable argument against this is that breaking ABI/API compatability
really sucks for ISVs. It was also argued that breaking ABI/API to just
clean up is bad for everybody except the library developers; in addition
to just a cleaned up library there should be a really big benefit which
application developers get when moving to 3.0. This benefit was certainly
there when moving from 1.2 to 2.0, as substantial areas were improved.
Other than that, a developer community might only accept an ABI break
in an emergency situation, where a quick decision has to be taken in order
to continue extending/improving the library. However with the shortage
of signal slots, this emergency might be really close. In summary: there
should be a good trade-off between benefits for both the library maintainers
and the application developers using the library.
Different ideas for avoiding ABI breakage were mentioned, for example
adding interfaces to objects instead of fields -- this also gives you the
benefit that extensions can be probed at run time.
We could also choose to seal all non-function APIs that GTK+ is currently
offering; this would mean that we get rid of all exposed structure fields
and macros. This does mean that the API breakage for 3.0 will be huge,
but it would greatly reduce the need for future API breakage. To make
the switch to 3.0 easier, it would be possible to start in the 2.x series
with adding new APIs and deprecating all macros and structure fields. It
was suggested to make the compiler warn about every deprecated feature (or
use run-time warnings if not possible).
6) We first discussed how implementing transparent widget windows would
work. Basically composite is used to redirect XWindows to a pixmap; these
are then alpha composited later on. For subwindows inside applications,
there are two options:
- Eliminate subwindows in GTK+. This is not really hard to do, and
most of GTK+ itself is already there, except for scrolling widgets
and third-party widgets using subwindows which are out of our
control.
- The toolkit takes care of redirecting the subwindows to pixmaps and
compositing those. (Also see [4] for some primarily work in this
direction).
The idea was brought up of "using" Google Summer Of Code students for writing
new features. It was immediately noted that this does need core maintenance,
there should be somebody to review those changes (and to mentor the students),
and we are short on resources already. Later on we reached consensus on the
point that SoC is really about teaching new developers, instead of getting
students to generate code. Also, getting 1 contributor out of 10 students
is considered a success. GTK+ taking part in SoC is probably a good idea
and should be seen as a long term "investment" in finding new and more
core maintainers. Finding resources to get this done, since we need mentors
for students, is still a problem however.
Also the already well-known problem of core maintaince was discussed. All
people who could do core maintaince right now are employed by different
companies and all assigned to specific tasks. There is little energy left
to get any (upstream) maintaince done after work. Becoming a core maintainer
is considered to take a lot of time, since those people need to be familiar
with most of the code base which takes several years. However, it was
argued that people with less experience can help out by running different
patches in bugzilla through test suites and use (the currently non-existing)
internal documentation explaining the inside machinery of complex widgets
to find problems. Another question was how the GNOME Foundation could hire
a core maintainer; this looks like a possibility, however there is nobody
left for hiring at this moment.
[Note from the editor: this discussion was cut off, since we had to
leave the room.]
7) 8) There was no time left for a proper question round and closing, since
we got escorted out of the building by the security people.
--
[1] http://lists.freedesktop.org/archives/xdg/2007-January/008978.html
[2] http://bugzilla.gnome.org/show_bug.cgi?id=116650
[3] http://bugzilla.gnome.org/show_bug.cgi?id=119189
[4] http://blogs.gnome.org/view/ryanl/2007/02/18/0
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
