Questions from the community
gtk+-upstream hackers, please take a look over it and answer questions you feel touching your field of involvement.
- Q: Do you intend to ship GTK-Webkit as the standard html rendering engine in gtk, like QTWebkit is going to be shipped in QT 4.4?
Yes and no. The GTK+ team is working to integrate WebKit into the GTK+ toolchain, providing a capable and integrated default Web widget and related functionality for application developers.
Unlike Qt 4.4, the GTK+ WebKit module will be distributed as a separate package. This avoids the maintenance burden of forking WebKit and allows ISVs to deploy alternative Web content engines when necessary.
- Q: When will libraries like libsexy be integrated into gtk? Every single desktop distribution on the planet ships libsexy with it's gnome so this has to say something.
There are bugs open for that, and patches are open to review. (EmmanueleBassi)
- Q: Will there be native (or native looking) file dialogs in gtk in the future?
- Q: Why is a Mac-like global menu so strongly rejected by gtk-upstream?
- afaik it is not really possible to do in a compatible way, only possible to do with pretty outrageous hacks. Also, note that the OS X menubar differs from a Windows/GNOME style menubar in more than just its location, there are also differences in what's in the menus, and of course on OS X you can have a menubar (application) open even with no windows open. Keep in mind also, I think there has not really been a credible attempt to get a patch like this into GTK, so I think saying the idea was rejected is an overstatement. The only patches I've ever seen were pretty crazy hacks that were not reasonable just on basic sanity grounds. That said I think Imendio does have some solution in the OS X port, though I'm not sure it lets you enable global menubar in GNOME.
Q: Are we still talking about the same thing? The original global menu implementation was a Hack, but the current implementation is certainly a lot better
- I haven't looked at that implementation, but I just looked at the bug with it on there, and I don't see any strong rejection from gtk upstream either...
- Q: Are there any plans to allow a gtk+-window be repainted on a bigger screen or texture?
Q: The GtkTextView widget is based on TK's widget originally (in 2000). There have been some improvements in TK since then and I want to know if people are aware of them.
I don't think there's much awareness of this, though note GtkTextView already has pretty large changes from the 2000 version of the Tk widget. If you have specific changes in mind I would recommend posting a summary of what they are to gtk-devel-list, pointing people to what you think they should know.
- Q: Are there plans in GTK+ to allow more powerful toolbars? This would include multiple dockable toolbars, probably a toolbar editor, etc. Some work is in libegg but it would be nice if it could one become upstream.
- I haven't seen anyone posting patches for this to gtk-devel or in bugzilla, so it looks like there are no plans. (Remember, it's open source; the plans are "whatever people are working on." Nobody works on it, then no plans.)
The work in libegg has one big blocker, as far as I know, and that is the lack of accessibility; you have to use the mouse to edit a toolbar. Until somebody starts working on it and submits patches, then it's not going to be integrated. (EmmanueleBassi)
- Q: I'm wondering what the biggest bottleneck regarding application-startup-time is in current gtk+, and what can application-developers do to mitigate them?
- Last time I started up just a plain GTK app it was pretty much instant... I think long startup times are often in application code. Usually disk or network IO is a major culprit.
Q: When is gtk+ going to offer something like QT's GraphicView?
When it will be possible to embed GTK+ widgets into other canvases, like Clutter, Pigment or Silverlight. This is what the offscreen redirection work aims to provide. (EmmanueleBassi)
- Q: Will there be a widget painting functions for external integrators like wine, firefox, qt (like Mac OS X has)?
- Q: Are you going to add indicators (variables) to widgets so a button knows that it's really part of a combobox, so themes don't do hacks to find it out.
- Q: Why is there no freedesktop effort to make a library to build themes, so they work on both qt and gtk+?
1) nobody is working on it, so nobody is working on it. By pure chance, of the universe of stuff to do, much of it will be undone. The reason each person is doing something else instead probably varies by person 2) it's probably pretty hard, which may make people less likely to work on it.
Q: When is glade getting GtkBuilder support?
- Q: I am interested in writing widgets,that can be theoretically integrated into gtk, can I use gtkmm? Or they will need to be rewriten (in C) to be integrated?
- Yes, they will need to be rewritten. Otherwise there would be a circular dependency, since gtkmm requires gtk, gtk can't require gtkmm.
- Q: Can one use widgets written with gtkmm easily in a C-based gtk+-application?
- Not that I know of. There would not be a C API. Of course, you could switch to compile some of your C app with the C++ compiler, and use gtkmm directly for some parts of the app.
- Q: Is it or will it be possible to write new core features of gtk+ directly in C++?
No, the core library will stay in C. With the new GObject introspection support will be possible to use widgets written in other languages, like Vala, with other languages, like Perl or Python. So there will be fewer limitations on the language of choice. Widgets will just need to provide the introspection information and the various bindings will be able to create a bridge between them. (EmmanueleBassi)
- Q: Will a future version of gtk+ get direct support for a dedicated OpenGL-widget (in contrast to GtkGLExt)?
The idea is to be able to draw with OpenGL inside an expose-event handler, like it's been possible with Cairo since 2.8. No OpenGL widget, like GtkGLArea, but a more generic approach; and yet, a simpler API than GtkGLExt. (EmmanueleBassi)
- Q: How important will Mac- and Win-ports be in the future? Will they be first class abstractions on top of the specific platform or just an afterthought?
- Q: Are there any plans in gtk+ to develop a dynamic "theme engine" like used on e.g. Edje/evas?
- Can you explain more what this means?
- Q: Will there be an UI-animation-framework introduced in a future version of gtk+?
- If someone does the work!
- Q: What is gtk-upstreams opinion on client-side-decorations?
- I'm sure each individual has their own opinion, but I doubt many people would be in favor (on Linux, obviously on Windows this is how you have to do it and how GTK/win32 presumably does do it)
Q: Are there any plans to build on GtkAction & friends to add more general and pervasive MVC capabilities to gtk?
- I haven't seen anyone post such plans to gtk-devel or bugzilla, but of course people would be interested in a detailed proposal from anyone willing to work on it.
- Q: Would it be wise to have gtk+ provide the needed framework for handling global keybindings?
- Q: Can we make Gtk dialogs HIG-compliant in the 2.x series?
- Q: Does the team behind gtk+ consider adding garbage collection to the toolkit?
- This is probably not realistic, though GObject does have features designed to help integrate it with a garbage collected runtime such as the one in Python, Mono, Java, etc.
- Q: Is there going to be a specific focus on speed improvements some time soon?
- If someone decides to work on it, yes. Otherwise no. This kind of question in open source has to be rewritten to "will someone, somewhere in the world, decide to work on XYZ?" and the answer is pretty much always "nobody knows, unless they are the person or company who is deciding to work on it" That said, historically there seem to be plenty of speedups that people work on and submit, over time. If a particular thing that's slow bugs you, then profile it and see where the problem is - that's most of the work. Feel free to submit performance bugs if they come with a test case and profile showing the problem.