|
»
»
»
GUADEC 2008 GTK+ Meeting Minutes
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
GUADEC 2008 GTK+ Meeting Minutes
by Tim Janik
::
Rate this Message:
Hey All. Kris took meetings during the GTK+ developers meeting at this years GUADEC. It took some time to transform them into a proper writeup, and Kris had to leave for a vacation flight before he could finish them off. So here are the minutes from Kris with a few finishing touchups from me. Please keep in mind that these minutes are from our meeting 2 weeks ago, and thus don't reflect on recent community discussions and new tweaks to the 3.0 plans. For an update on our latest plans, please have a look at the summary of yesterdays IRC meeting: http://mail.gnome.org/archives/gtk-devel-list/2008-July/msg00187.html GTK+ Meeting, 8 July 2008, GUADEC 2008 -------------------------------------- Final agenda: 1. Opening 2. 2.14 release overview 3. Planning GTK+ 2.16 - Features - Schedule 4. 3.0 - Current status - Schedule 5. Technical discussions - 3.0 policy - Sealing GtkRcStyle - Offscreen rendering event processing - New GDK backend that renders into image buffers 6. Closing Notes: 1. The meeting was opened at 12:10. 2. Last year we have promised to get GTK+ 2.14 out of the door around GUADEC 2008. We are closely approaching this date and we seem to be mostly feature complete. The testing framework bits have landed in GTK+, as well has the first part of the offscreen rendering work. Furthermore, a lot of small API improvements, bug fixes and clean ups have been done. The remainder of the offscreen rendering work deals with event processing and is hard to get right (more on this later in the meeting). If we wait for this to land we will most definitely not make the GUADEC 2008 release date. Therefore the current plan amongst the core developers is to delay the second part of the offscreen rendering work to the next release and get GTK+ 2.14 released in its current shape. After asking whether people have more pending features that could make it into 2.14, nobody has something ready that could go in at this point. Mitch still wants to get new adjustment API (accessors for it) in 2.14 if possible. During the next IRC meeting the team would like to propose to API freeze the next development release and release the stable 2.14 after a few weeks of stabilization. 3. It was mentioned that Behdad has requested us to consider renaming to "GTK+ toolkit" and change the license to GPL3. The renaming to "GTK+ toolkit" issue has already been handled in bug #540529 and will not be done. Changing the license to GPL3 (in GTK+'s case LGPL3) is a long process and is not planned to be carried out immediately. In any case we do not want to block a possible GTK+ 3.0 on a license change. A recent discussion on the mailing list left the impression that some implications in mixing LGPL3 code with LGPL2 code still have to be figured out. Apart from offscreen rendering part 2, the following items are on the agenda for GTK+ 2.16: * Mathias Hasselmann's extended layout work. Plans are to start API review soon. * Mathias Hasselmann's tool palette. The tool palette is a "tool box" as found in for example the Glade UI builder and GIMP. It will undergo some more real world testing as it will be tried to replace Glade's toolbox with the tool palette. After that remaining kinks in the API will be ironed out and a proposal send to the mailing list for discussion. * Libsexy integration. This is something that has been on the list for a couple of years now. Libsexy certainly contains some nice features and there are no objections if these get merged at some point. The problem is that so far nobody has stepped up to actually cherry pick features from libsexy and get them in such a form so that inclusion in GTK+ can be considered. Lately Cody Russell has been working on getting an "icon entry" going for GTK+. If his work continues we hope to get a few libsexy improvements in GTK+ 2.16. * Simpler API to create a simple ListView, a wrapper around GtkTreeView to make simple list creation without MVC split easy. Kris has been discussing such an API with Johan Dahlin and Emmanuele Bassi as they are familiar with the Python and Perl variants of simple lists APIs respectively. The Python and Perl APIs seem nice and similar, we want to attempt to come up with something similar for C. Further ideas that were raised: * Add a new signal to GtkTreeModel that inserts a given number of rows in one go. Kris argues that this is only part of a bigger problem: we want to have a proper batch/transaction API in GtkTreeModel. We shouldn't just add this single signal for now, but sit down and properly design this transaction based API and try to get it right for most use cases. * How to do extend the print dialog? Tim advises to file patches implementing these extensions in bugzilla. * What is happening on the "GLib foundation library" front? This foundation library is supposed to become a general desktop support abstraction library. It would support things like screen saver/power management/configuration API. As with all larger projects; if somebody steps up with an API and implementation, we can consider this. Ryan Lortie says he is working on the configuration API part using GVariant. * GVariant status. All of the GVariant code is currently in git and it is working well. An application is needed to try this code out. In general, it seems to be ready for API review. * Introspection in 2.16? For introspection it will take at least a few more months before it is usable. One of the issues is source code annotation; there is a format for such annotation already, but no consensus has been reached on the final format for this. Schedule. The GTK+ team feels that the last few release cycles to try to aim for a release around GUADEC have been working out well. Therefore, and also seeing the list of suggested features, we want to try to aim to release GTK+ 2.16 around GUADEC 2009. This is probably also good for GNOME; they need a stable release a few months before theirs to be sure that GTK+ will actually be released on time. GtkTasks. Tim briefly describes the GtkTasks[1] page and goes over all slots. It appears that two slots are already filled by some of the attendees of the meeting, but not marked as such in the wiki. [As far as I know, the wiki has been updated now. ed.]. Of course we will continue adding items to the GtkTasks page as new, isolated tasks show up. One of the transient tasks was moderating the canvas evaluation thread on gtk-devel-list. This has been done by Carlos Garnacho; briefly summarized there is no clear consensus on where to go with the canvas. A new transient task is the migration of the remaining parts of the API documentation from the SGML templates to the source code. This is being done by Stefan Kost and has been very well received. 4. The basic plan that was proposed for 3.0: - Add features in 3.2 and 3.4, ship 3.0 without new features and without new deprecation so porting from 2.x is easy. - Put a new development policy into place for 3.x which allows clearly defined future removal of deprecated API (ABI break), to enable incremental and more community driven development of the toolkit. - Seal all public structure fields and provide accessor functions. The sealing work that started in an independent Git branch after the Hackfest has already been merged into SVN trunk 2 weeks before GUADEC. Mitch mentions that GDK has not been sealed yet; this is something that can be done in 2.16. He also wonders if we can deprecate and remove the non-multihead API in 3.0. These functions are already marked as non-multihead-safe. This could be looked into for 2.16. People wonder whether a GLib 3 is planned and whether the entire library stack must be parallel installable. A GLib 3 is most probably planned, as there are things in GLib that might make sense to seal as well. This more or less implies that the entire library stack will have to be parallel installable. Alternatives are: - Another toolkit: this gives you even more port trouble than between major GTK+ revisions. - Change the prefix (for example to gt3) and link against both: this won't really work, you end up with 2 main loops, 2 thread systems, 2 X11 connections, etc, etc. Another question is how people plan to fix API in GTK+. Two examples are raised: - Scrolling should be handled in an interface. - Tree model columns should be indicated by a string instead of a number. The basics of fixing API is by introducing a new function and deprecating the old. This could lead to "API fragmentation", as it becomes hard to find a good function name (though this is already so in 2.x). Though eventually deprecated functions will now be removed. GTK+ 2.16 is planned to be released in roughly a year. When do we expect a release of 3.0? Tim walks through the 3.0 tasks page[2] where things that need to be accomplished for the release are described. Tim also walks through the steps that have to be done for releasing 3.0, which are basically removing all deprecated code and move public structure fields to private headers. In addition to that also change compiler flags to disabled deprecated functions by default and enforcing single header includes. We settled on expecting 3.0 1-2 months after 2.16. More discussion is held: - Can we make GDK backends dynamically loadable? A possible use case for this is to be able to have a GTK+ with both the X11 and Quartz backends on OS X. This is probably technically possible, but will take several months of work to achieve. Also, you'll also hit several pieces of backend specific code in GTK+ instead of GDK. - What happens with applications that dynamically load two versions of GTK+ due to ELF dependencies, in particular 2.x and 3.x? As an example, XMMS is brought up which uses GTK+ 1.2 and could dynamically load a plugin that pulls in GTK+ 2.x and bad things happen. People argue that if the plugin would load Qt or something else you end up with the same problem. For distributors these are issue that are very hard to debug. There are several ideas to improve this situation. One is looking into the linker-mechanism to catch such problems. Eventually we can try to have GModule to walk the ELF dependency chain of the module to load to catch any issues before actually loading the module. It might also be possible to check for conflicting ELF symbols and provide explanatory error messages in functions like gtk_init. - How do other projects handle breaking ABI? Deprecation schemes only scale well if deprecated APIs are really removed from a code base at some point. Technically, this is an ABI break which is why GLib/Gtk+ have not been doing this since 2.0. However, lots of other vendors do this, e.g. Qt does break ABI between major releases, Python 3.0 will be incompatible with 2.5, Apple does remove long deprecated APIs in newer releases of Mac OS X, Symbian, Microsoft, and the list goes on... -- A break is held from 13:50 to 14:20. 5. For the remaining hour, a couple of technical discussions were planned. - 3.0 policy. Most of the 3.0 policy ideas have already been raised in the meeting. This involves breaking ABI/ABI with a mostly fixed interval, removing deprecated functions after a defined period of time, etc. The plan is to start a writeup and review phase of the policy on gtk-devel-list at some point to reach general agreement amongst the core developers. Another item that'll be useful to discuss is integrating the commit policy to the development policy document. The commit policy probably doesn't need to be much different than it is now, but writing it down will help current and future contributors: - Code must compile before you can commit. - Test suite must be run before commit. - Revert if a commit breaks the build. The idea of also using svn hooks for this is raised. We do not know off head, this would have to be checked with Olav Vitters. Also getting up dedicated build machines will help here if they run the full test suite after completing the build and provide notifications or reports. - GtkRcStyle sealing. We have been wondering whether or not to seal GtkRcStyle as we are not fully sure yet where we want to go with theming in 3.x. It is a hard object to seal, because a lot of fields are exposed here. There are voices to actually replace this object with a Cairo-based variant. Also, last year's theming BoF didn't really go anywhere [this years was much better, see the notes on gtk-devel-list. ed.]. However, according to Carlos sealing this and using accessors might be quite straightforward; he has not tried how hard it is to port an application to this and whether there is a possibility this could be done automatically. Are there plans to replace theming in 3.2? This is not clear yet, as there are no concrete ideas for its replacement at this point. We do know that during all of 3.x GtkStyle should continue to work, whether or not it is replaced. Basically this means that we have to seal it; the accessors can later be reworked to provide compatibility code. - Offscreen rendering event processing. For the second part of the offscreen rendering work, a lot of the event processing code in Gdk is duplicated in non-X11 backends and partly the offscreen code. We are looking at ways to constrain the events that are sent, some are very X11 specific. The suggestions are to: - drop the detail from GdkEventCrossing (it is only theoretically useful in the presence of subwindows, and cannot be relied on for non-X11 backends or offscreen windows anyway); - Confine motions to motion events, synthesize Enter/Leave events. Deliver new pointer motion information in motion events only. This may result in occasional reports of 0-distance motions, but is easy to program with, since motion logic does not need to be replicated across handlers of multiple event types. All other event types just repeat the last motion event coordinates. Synthesize 0-distance motions upon widget state changes to generate Enter/Leave events as needed (e.g. when a widget becomes insensitive or is hidden). We are wondering if anybody is using the X11 specific aspects of the events and has problems with the proposed suggestions. Other things that were brought up and still need polishing in the patch: - Implicit grabs; which are a separate issue from the event handling problems listed above. - Event coordinates transformation does not work for everybody. It looks like this depends on the version of cairo that is used. The plan is to get this second part of offscreen rendering finished during the Fall. Hopefully it will land in GTK+ around November. Another suggestion was to look into abstracting out the code that handles event processing. Then the same code engine could be re-used in GDK, several back-ends and for offscreen rendering. - New GDK backend. Hans Petter Jansson has recently been working on a new GDK backend that is not tied to any display system and is fully offscreen. Each window gets an image surface in which its contents are rendered. Then an application can do with that image surface what it wants. This is meant to be used in for example games, where you render the UI in a surface and then reuse this surface in for example an SDL application. It has event synthesis for mouse and keyboard events. This backend has been based on the linux-fb code. Hans would like to have this in a branch in subversion to continue development and eventually get this included in GTK+. As a conclusion, he showed an impressive demo of his work so far. 6. Closing. The meeting was closed around 15:30 as we have to leave the room to make space for another meeting. [1] http://live.gnome.org/GtkTasks [2] http://live.gnome.org/GTK+/3.0/Tasks --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
|
|
Re: GUADEC 2008 GTK+ Meeting Minutes
by Colin Walters
::
Rate this Message:
On Wed, Jul 23, 2008 at 11:55 AM, Tim Janik <timj@...> wrote:
GLib 3? What conceivable changes to GLib are outstanding that would merit API/ABI breakage? I just wanted to mention here again the alternate GTK+ 3.0 plan: 1) Integrate a canvas. Here's an example of real world program almost certainly on your desktop that needs it: http://blogs.gnome.org/dcbw/2008/06/11/great-taste-less-filling/ That mockup really needs a canvas that has features like painless GtkWidget embedding, powerful styling and layout. We could take the approach of having app authors pick one on their own (I know I would suggest hippo-canvas to Dan just because Owen's been doing such good work on it), but it certainly would be a lot better if the canvas was being driven forward the GTK+ core team. 2) Finish GObject introspection - People continue to write code in C, bindings authors continue to fall farther behind. One possible approach with the canvas would be to have parts of GTK+ that are not API/ABI stable - perhaps they require a Havoc-style "#define GTK_I_WANT_A_CANVAS 1". Once the canvas is stable we declare it GTK+ 3.0 from a marketing point of view (but don't change the soname), like what GNOME is doing with GNOME 3. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
|
|
Re: GUADEC 2008 GTK+ Meeting Minutes
by Paul Davis
::
Rate this Message:
On Wed, 2008-07-23 at 22:45 -0400, Colin Walters wrote: > On Wed, Jul 23, 2008 at 11:55 AM, Tim Janik <timj@...> wrote: > > People wonder whether a GLib 3 is planned and whether the > entire library > stack must be parallel installable. A GLib 3 is most probably > planned, as > there are things in GLib that might make sense to seal as > well. This more > or less implies that the entire library stack will have to be > parallel > installable. > > GLib 3? What conceivable changes to GLib are outstanding that would > merit API/ABI breakage? > > I just wanted to mention here again the alternate GTK+ 3.0 plan: > > 1) Integrate a canvas. great idea. > Here's an example of real world program almost certainly on your > desktop that needs it: > http://blogs.gnome.org/dcbw/2008/06/11/great-taste-less-filling/ > That mockup really needs a canvas that has features like painless > GtkWidget embedding, powerful > styling and layout. That mockup absolutely does NOT need a canvas. > We could take the approach of having app authors pick one on their own > (I know I would suggest hippo-canvas to Dan just because Owen's been > doing such good work on it), but it certainly would be a lot better if > the canvas was being driven forward the GTK+ core team. Not sure I agree with that. The core team seem to have a pretty great grasp of what a canvas *should* do, but they also have a huge reluctance to commit to anything that doesn't get really close to their ideal vision. Out in app-devel land, most of us have used canvases (Gnome, Goo, Hippo, ccc, Dia and more) that are not perfect but enable us to get stuff done reasonably, even if not ideally. > One possible approach with the canvas would be to have parts of GTK+ > that are not API/ABI stable - perhaps they require a Havoc-style > "#define GTK_I_WANT_A_CANVAS 1". Once the canvas is stable we declare > it GTK+ 3.0 from a marketing point of view (but don't change the > soname), like what GNOME is doing with GNOME 3. Not a bad idea, except that when an app is distributed that WANTS-A canvas to a system where GTK was built with FORGET-A canvas, what happens? > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
|
|
Re: GUADEC 2008 GTK+ Meeting Minutes
by Colin Walters
::
Rate this Message:
On Wed, Jul 23, 2008 at 10:59 PM, Paul Davis <paul@...> wrote:
Ok; how would you do it? If you're thinking WebKit or GtkMozembed or something - while I agree that's a possibility for this, it's a very heavyweight solution for a lot of things that just need a flexible layout system without dragging in HTTP and JavaScript for example - other reasons are outlined by Owen at the bottom of this mail: http://groups.google.com/group/mugshot/browse_thread/thread/73ba19bdd8f2f993# Not sure I agree with that. The core team seem to have a pretty great Sure; but we should be keeping in mind that in the end we need to choose.
The idea is that the canvas is not ABI stable for a while - applications depending on it that are shipped by distribution vendors would need to be carefully managed (possibly go the parallel install route). But it would still get the canvas feedback from some real world appplications. I admit I'm just thinking out loud here. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@... http://mail.gnome.org/mailman/listinfo/gtk-devel-list |
| Free Forum Powered by Nabble | Forum Help |