Hi all, We continued the trend of having GTK+ meetings in person at major conferences and I continued the trend of writing up notes ;) Please find below the notes I took during the GTK+ meeting at GUADEC in Birmingham. Corrections are most welcome, as always.
My apologies for sending out these minutes so late, being on vacation right after GUADEC didn't really help :) regards, -kris. ---------- GTK+ Meeting, 16 July 2007, GUADEC 2007 --------------------------------------- Final agenda: 1. Opening 2. Agenda 3. Current state of 2.12 4. 2.14 features and schedule 5. 2.x situation, 3.x road map 6. GNOME Foundation funding 7. Ruleset for compatibility issues 8. Question round 9. Closing Notes: 1. The meeting was opened at 10:32. 2. During the meeting point 6, "GNOME Foundation funding", was added to the agenda. 3. We've tried to get an API frozen release out on the Friday before GUADEC, unfortunately this didn't work out. We will release an API frozen 2.11.6 once the network at GUADEC will start working. When finalizing the release schedule a few weeks ago, we promised to release 2.12.0 during GUADEC or the week after. Since the last API bits only went in last week, we don't think it's a very good idea to put out 2.12.0 next week. Obviously it is good to have a few weeks of bug fixing between the first API frozen release and the final .0 release. The upcoming GNOME release is entering API freeze on August 30. We think that an API frozen release this week and a guaranteed final .0 release before August 30 should not be a problem for GNOME. Right now we will be targeting mid-August. The time between now and mid-August will be used for testing, more bug fixing and finishing the documentation for the new features. GLib 2.13 is basically feature complete and ready at this point, we decided to release GLib 2.14 as soon as possible, so earlier than GTK+ 2.14. Pango will be following the GNOME release schedule. 4. We asked the developers in the room to come up with possible features for 2.14, with the requirement that these features will be finalized and ready in the coming months. - GVFS, the API is there, Alex is not fully confident in the API yet and wants more testing and review first. If we start with this on time, this shouldn't be a problem to get into the 2.14 release. - XRandr SoC, work is being done on GTK+ support for the new version of the XRandr extension which allows for dynamic changes (like appearing and disappearing monitors, and changing their geometry). - Tap-n-hold, the patch is mostly ready but depends on the cursor animation API/API for creating animated X cursors. - Offscreen rendering. - Height-for-width, natural width and baseline sizing. There is code already, it just needs to be finalized. - Being able to implement file chooser dialogs outside GTK+, so basically making the GtkFileChooserIface public. The consensus was that a proposal will have to be sent out to the list saying which parts of the interface should be made public. - File type selector, for the "save" version of the file chooser. GUnique was brought up as a possible feature for 2.14, a small discussion about its usefulness as "stand-alone" feature emerged. It doesn't make all that much sense without an application window class, subsequently an application window class doesn't make much sense without session management. Basically, you start questioning whether you want to introduce a document based window/application model (like Cocoa has) -- getting this done requires a good amount of work and discussion because it possibly takes over a lot. In the end we concluded that all of this would be more useful as a higher level library including all these pieces. With regard to release schedules, we seem to have fallen into some kind of pattern. We start planning at GUADEC try to aim for January, and then slip until we get our act together for GUADEC ;). It seems reasonable to try to release 2.14.0 around the next GUADEC (however, we do not exactly know when that will take place). This is a period of about one major release every 12 months, which falls together nicely with one major GTK+ release every 2 major GNOME releases. Though we want to freeze the API a little earlier in the process and look at the GNOME release schedules to make this fit in nicely. 5. Up next was a discussion about the current state of 2.x and an attempt to come up why exactly we need 3.x. It has been said that GTK+ 2.x as it stands right now is a nice and capable toolkit, but continuing this way is a "dead-end". Which parts are exactly a "dead-end"? Which are not? What can we actually still integrate into the 2.x branch without breaking compatibility? Right now the complexity of the core is very high. If you keep on extending and replacing subsystems with another (eg. like we replaced GtkTooltips with GtkTooltip), it is not always going to make the toolkit easier to both use and maintain. GTK+ could end up looking like Motif: old and very big. It was noted that Qt breaks compatibility during every major release; though most of their customers ship the Qt libraries with their applications and they try to simplify the migration between two major releases with some compatibility layer. So, at some point, you basically want to more or less start over, maybe redefine the target (only target the desktop, or only target specific use cases on the desktop, etc). One approach to this might be to have a "prototype" application with new technologies, which would end up driving development of a "new GTK+". It doesn't even have to use GTK+, but can use the core libraries. At some point a kind of stack will be built on existing libraries, like GObject, Pango, etc; this stack could be a starting point for a new GTK+. This process can happen completely in parallel with the current development on the 2.x series, but does need a good organizational effort. What do people actually want to experiment with for a new GTK+? - No subwindows in GDK. - No C structures exposed in the interface. - Why do we have a distinction between canvases and widgets? Could we "merge" this? What will be possible if we do? - Start by looking at the tools to create applications, design the framework of the toolkit after that. - Start looking from an application perspective; how do we want to control our application and how should it appear/behave? Look into supporting things like multitouch, nicely animated user interfaces. Think about for example "what will evolution want to do in 5 years from now?". People who are interesting in new things like this will experiment and try it out. It is clear that there are enough ideas and enough people who would love to do some experimenting. Now, how do we get serious? - Get people to experiment, don't feel threatened by "other" people doing these new things. - Don't point at a GTK+ 3 branch and say that this is going to become to "next big thing". Because experiments can fail, the entire branch could turn out to be some failed experiment. - Hopefully those experiments will end up being libraries being used throughout the stack by applications that need it. At some point the GTK+ team can start "picking" such libraries and design to start maintaining and releasing it next to the GTK+ 2.x releases. - As said earlier, pick an application to "drive" these developments, use all new technologies, make it form an example of "future applications". 6. The GNOME Foundation has offered to raise awareness of the current maintenance problems among companies. Multiple companies seem to be interested and would probably contribute money. How could GTK+ use this money? - Have the foundation hire a core hacker -- but hard because all core hackers are already employed by companies. - Pour money into a GTK+ supporting company. - Use the money to setup a small meeting like GIMPCon. This could possibly be a hack week or weekend where just the core hackers come together to discuss problems, work on new API, fix bugs, in general get things done. Apparently weeks like this have proved to be very useful for the GIMP. - Put money into people developing these "new and cool" technologies. This probably not a good idea, since it will most probably make people doing the "boring" maintenance job quit. See Debian for related experience. - Sponsoring conference travel for people who can't afford themselves. 7. Right now we are really hitting the limits as to what we can change without breaking compatibility. The rules on what kind of changes are acceptable and which are not with regards to compatibility are not very clear, would it be good to set up an official "ruleset" for this? An issue with this is, if you do the change which is allowed by the rules and some application (doing valid things) breaks, is this okay? People agreed that such breaks would still have to be fixed and defining a proper ruleset will be hard. Most decisions are currently being made by looking at impact, valid use cases for the code, experience, etc. It makes sense to publish some kind of "contract" which clarifies what kind of measures we are currently using the make these decisions. 8. Question round There was a informal meeting on theming yesterday. What was the outcome? Apparently there are really two points of view: - The artistic point of view: lots of ideas, don't know whether things are possible at all. Some of those ideas are indeed not possible with the current GTK+. - Core developers point of view: we don't know the full wish lists of the theme developers. The solution here is to improve communication between both camps. Yesterday a start was made on working on a wish list, this will be published as a GtkTask and there are several people who want to work on this already. Hopefully this will result in a wiki page with the wish list. Has there been any progress on the OpenGL integration? Somebody has brought GtkGLDrawingArea back to life, but the consensus among the core developers is that a "cairo-like" approach using contexts would be better. There hasn't been any (visible) progress on the latter. How is Webkit doing? There are a few people working on the GTK+ WebKit port. It was suggested to maybe bringing the versioning and release schedule of this port and GTK+ inline, and "bless" the WebKit port as GTK+'s official HTML widget. 9. The meeting was closed at 12:17. 9. Closing _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list