| |
|
||
| post article search main |
 Posted by Ali Abdin on Monday December 27, @01:28AMfrom the 2nd-time-round dept. Here is an update to the interview that I did earlier. Owen Taylor and Tim Janik got around this time to answer my questions on Gtk+, so I felt it is only fair to post them. Also Miguel wanted to clarify a point riased by the old interview. Feel free to ask your own questions below, because many of the GNOME developers actually answer them. Miguel?s Awnser to a question Plotting and Gnumeric, what is the state? Helix Code (http://www.helixcode.com) has been developing the plotting component for Gnumeric. This is a from-scratch plotting component. The new plotting system is a Bonobo component and it is built around the Bonobo architecture (instead of adding a Bonobo layer on top of an existing plotting engine).
Gtk+ Questions What is Pango? Will it truly be able to handle everything from Arabic, to Japanese? Will it be able to support Klingon?(just a weird question I decided to throw in) How easy will it be to set-up? Will there be added complexity to programs if they want 'multi-lingual charset' support? Pango (which is the code name for a merger of my Gscript project and Raph Levien's GnomeText project) is a modular set of libraries for doing layout and rendering of international text. It's a bit similar to Microsoft's Uniscript or Apple's ATSUI. It also turns out that a lot of issues that are only important when doing fine typography in European languages (such as ligatures and glyph substitution) are essential when dealing with some other scripts. So, as a side benefit, Pango will also provide the foundation for supporting really nice typography for English [Note: I got a 404 Error ? try http://people.redhat.com/otaylor/gscript] The other big change that will be in GTK+ 1.4 is support multiple platforms. Tor Lillqvist's Win32 port is already integrated into the development tree, and we also expect to integrate the BeOS port that Shawn Amundson and James Mitchell have been working on at Eventloop, Inc. The fact that we already had the GDK layer as a wrapper around Xlib made this far easier than it would otherwise be, but we've had to do a fair bit of code reorganization to put all the platforms on an equal footing and a few places where GTK+ was using Xlib directly needed to be cleaned up. I'm not personally all that interested in using GTK+ on non-X platforms, but being forced to go through and rethink the GDK layer has already had a positive impact on the code base, and having a clean separation of layers will make it very easy for us to take advantage of future changes in X without breaking compatibility. I've also had a chance to go into GDK and enhance the way it handles drawing and exposures, and this has some very nice consequences for GTK+-1.4. Handling redraws is more efficient, the code in libgtk much simpler and cleaner, and it is now possible to double-buffer drawing to provide flicker-free operation with almost no extra effort for the widget writer. GTK+ 1.4 will come with some new widgets. Among them the horizontal and vertical wrap boxes that are already being used in GIMP's development tree. The GtkHWrapBox in Another interesting widget is also waiting for inclusion into GTK+'s development branch: it connects a popup window to an existing GtkEntry to handle shell style tab-completion, optionally using wildcards. Shortly after implementation of that widget, Zach Beane pointed me at http://doxpara.netpedia.net/cluehunting.html which provided the widget's current provisional name: GtkClueHunter. Multiple Interfaces for objects (similar to those in Java, or the C++ signatures as outlined in the gcc info files) are also planned (BSE's type system already contains a sample implementation of MIs that can be easily migrated). GTK+ 1.4 will also come with support for notification of changes in object state; this may be limited to changes made through the argument system. As an example of this, it will be possible to monitor a GNOME Canvas item for changes in size or position or other similar properties. At the GDK level, we will add support for the new window manager specification, once that has matured into its final state (the latest draft can be found at http://ferret.lmh.ox.ac.uk/~pdw/wm-spec). We can't give exact release schedules out at this point, since for one thing, we still need to decide exactly what will go into the next release, and what into the release after that. But I'll get myself in trouble and say we'll have "1.4" out sometime in the first half of 2000. Well, I've been working on a rewrite of the pixmap theme engine (which is just one of the theme engines in the gtk-engines module) to use gdk-pixbuf while remaining compatible with existing theme files. There won't be a lot of user-visible changes in this. The most obvious one is that when scaling pixmaps, there will be the ability to use filtered scaling, as opposed to the simple nearest-neighbour scaling that is currently used. But the main reason for the rewrite is to move to something that is more actively maintained than imlib1, and also to get a code base that I'm more confortable [comfortable] working with. The other big visual improvement for pixmap-based themes will come from the improved drawing code in the next version of GTK+. The new drawing code can make a heavy pixmap theme much more useable by reducing flashing and by being more efficient in what it draws. We are currently toying with ideas on a new, probably LibArt-based rendering model for GTK+, but this is definitely 2.0 stuff that can be covered more detailed at a later point ;) Another thing we'd like to do long-term is go in and rethink some of the widgets. GtkText is scheduled for replacement in the short-term to go along with Pango, but as a longer term BEAST (the BEdevilled Audio System) is a Gtk+/GNOME based front-end to BSE (the Bedevilled Sound Engine). BSE is a shared library that comes with the necessary framework to simulate audio synthesis (modular synthesis) and song composition as known from
- its own dynamic type system similar to the one known from Gtk+ BEAST implements the necessary GUI components to make use of BSE's functionality, so it comes with a pattern editors, generic GUI components to edit object properties and a GNOME Canvas based route editor to layout synthesis networks. An alpha-stage release of BEAST is already scheduled sometime before the end of this millenium ;) Besides GTK+ and some GNOME components, i'm spending a major portion of my time on BEAST/BSE development. I really want to see this project maturing so a well-founded audio composition tool is available for unix platforms. There's plenty with GTK+ and Pango to keep me busy for the forseeable future (and then some), but I have various side projects that I spend some time on as well. Memprof (a runtime memory profiler) and a set of Perl bindings for ORBit are at the top of that pile right now. One thing I'd like to see appear for GTK+ and GNOME are tools to lower the entry barrier to GTK+/GNOME programming. Along with some other people at RHAD labs I've been experimenting with using Glade and Python to create a IDE of a sort (called Eider) as a step in this direction. < | >
|
|
|||||||||||||||||||||
|
|||||||||||||||||||||||
 |
||
| All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest ©1999 The GNOME Project. | ||
GNOME Developer's Interview Follow-up
