Rough agenda for the GTK+ Hackfest 2008:
- Release planning for next stable release, currently scheduled for GUADEC, July 2008
- Integrating gio support in GTK+
- Integrated HTML widget/library
- GObject introspection: an automatable future for language bindings
- Future of D-BUS GLib integration and Gsettings
- Session management API
Which could/should lead to a GtkApplication class
- Canvas widget, and considering it as the base for widget rendering in the future (seems like we don't have the right people coming to discuss this item)
Other ideas accumulated on the wiki over time follow.
Theme drawing API
I agree our theming approach on GTK is a crappy hack; I've been begging for years for a real GTK theme-drawing API we could use, like Mac and Windows provide.
What could we do to improve things here? (See bug I filed two years ago, GTK needs to provide API for themes to draw directly on cairo context - John.) This would also need to solve the problem of, "I need to implement a custom widget that looks almost like GtkSomeStandardWidget, but the style API doesn't let me."
related issues: Default to RGBA colormap if available
Obviously, the timeline bug, but also: how do we integrate a GtkTimeline with the GtkStyle API so that theme engines developers can control the animations and/or change the drawing depending on the animation progress?
Desktop integration API
A Desktop abstraction (power state, screensaver, network state, session management, single instance applications, etc.) depending on the target platform.
What can we test today? Why are we not doing it? What would we need to do automated extensive testing of the whole toolkit?
Documentation for language bindings
How can we make it easier for language bindings author to have documentation. Is it possible to write the gtk-doc comments in a language neutral way?
Gtk+ on foreign OSes
Linux has good distribution today (tar.gz), Distributors takes care of preparing the binary releases.
- needs to be easier to build out of the box using native tools (Xcode,MSVC)
- needs an easy to use installer (dmg/msi) which ideally is using components for each part of the stack
- officially sanctioned packages, user/binary and developer/sdk
- Win32 and MacOSX efforts to use more natives APIs for pixbufs and look and feel
- DOM-like two pass event system.
- Putting event handling in its own thread? (or: non-blocking UIs, how to get them "automatically" without putting too much burden on the application developers).
- Or putting draw operations into a separate thread (I know: "threading is hard, let's go shopping")
- At least need an easy to use API for the pattern of multithreading with a single GTK+ thread. So we don't have to explain how to do a gtk+ management thread and timeout/idle callback pattern (or a socket/pipe/messaging passing pattern) every time someone's multithread GTK+ application gone crazy.
- Put your crazy ideas here.
Also GtkUniqueApplication which subclasses it
- Handles session management setup/teardown...
- Lets compromise with a document-per-window abstraction.... and
Integrate the session management stuff so the user can save and switch sessions at will --> Task based desktop!
- Once we have a base application class all apps use, we could use that to build things like Apples Automator - document based interfaces could be exposed over DBus to allow cross and inter application scripting and control (to a limited extent)
- The author of UFraw, Udi Fuchs says:
"The Berlin Hackfest attracted my attention since I live in Berlin. I'm a user of the GTK+ library and not a developer, so I don't belong in this Hackfest. Still, if you or someone else there is interested in discussing issues related to raw conversion (maybe support raw files in GtkPixbuf...) or color management (lcms), I could come visit you for a few hours."
Something about sound events and Gtk. i.e. remove libesd dependency from gtk, and what to do instead. With perspective on PA, of course -- LennartPoettering