GNOME NEWS
 post article
 search
 main


GNOME Developer's Interview Follow-up
General Posted by Ali Abdin on Monday December 27, @01:28AM
from 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?
[Miguel de Icaza (miguel@gnu.org)]

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?
[Owen Taylor (otaylor@redhat.com)]

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
speakers.

The only hard part of setting up Pango will be dealing with font installation problems. Until the font model in X is improved (something that is already happening some in XFree86 4.0, and I expect to see more of in the future), this is always going to be an annoying problem. I suspect most people are simply going to need to rely on their distribution vendors to get it right. It's too much of a systemwide problem for us to try and come up with a one-size-fits all solution within GTK+ or GNOME.

There is actually nothing GTK+ or GNOME specific about Pango. The basic set of libraries will include the layout engines and code for basic rendering with X fonts. GTK+ will build on top of this to provide widgets and simplified APIs for people who don't want to or need to deal with the full complexity. GNOME will add an additional renderer that works on top of libart and the anti-aliased canvas to provide the type of output quality you would need to write a desktop-publishing or illustration program.

I hope that Pango can become a standard, or at least commonly used library for handling these types of issues on open-source systems. There is a lot of activity now on enhancing internationalization support on Linux, often involving moving to using Unicode for representing text, but this has mostly centered on the "easy" languages ? things like Western European languages and East Asian languages. Not much attention has been paid yet to languages written right-to-left, such as Arabic and Hebrew, or the languages of South Asia, where rendering is a complex process without a one-to-one mapping between characters and glyphs. This is an area where commercial systems are currently considerably ahead of open-source systems; Pango
is meant to close this gap.

Eventually Pango will handle everything from Arabic to Japanese to Hindi. I'm pretty confident that somebody will contribute a module for Klingon. I see the modular nature of Pango as a key to it being successful. If I tried to code support for all the languages that I'd like to support myself, I wouldn't be done in 10 years, and what I did code wouldn't be useable anyways. So, the goal is to get a core out there and let people add onto it with modules for their own languages.

(See
http://www.labs.redhat.com/otaylor/gscript/ for more information)

[Note: I got a 404 Error ? try http://people.redhat.com/otaylor/gscript]

What are some features (besides Pango and Internationalization) that will be incorporated into Gtk+ 1.4? When can we expect to see releases, so the masses can start porting their applications?
[Owen Taylor (otaylor@redhat.com)]

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.

[Tim Janik (timj@gtk.org)]

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
principle acts like a normal GtkHBox, but if the given allocation isn't sufficient to fit all its children horizontally, it can open up a new row to fit the remaining children in. GtkVWrapBox works similarly for the vertical direction.

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).

[Owen Taylor (otaylor@redhat.com)]

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.

I've heard a rumor that gtk-engines might be recoded to take advantage of gdk-pixbuf's new features - Can you confirm, deny? How will the gtk-engines be changed for the GTK+ 1.2.4?
[Owen Taylor (otaylor@redhat.com)]

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.

What kind of things would you like to have seen worked into Gtk+ that will not be making it into the next release? What can you not implement due to a lack of developer resources?
[Tim Janik (timj@gtk.org)]

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 ;)

[Owen Taylor (otaylor@redhat.com)]

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
goal, we would like to have a nice consistent set of list/tree/sheet widgets to replace the current confusion of GtkList/GtkCList/GtkTree/GtkCTree. There is considerable opportunity there for making things both simpler to use and more flexible.

What is the 'Bedeviled Audio System' (I discovered it on CVS)? Could this play the role of esound in future GNOME development?
[Tim Janik (timj@gtk.org)]

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
other popular "tracker" programs.


BSE currently provides:

- its own dynamic type system similar to the one known from Gtk+
- an interface for truely dynamic plugins to implement new objects (e.g. synthesis filters) as shared libraries
- procedure types which allow for a procedure registration system somewhat similar to the GIMP's PDB interface
- a storage system that can serialize (write out and read in) complete object hierarchies and features binary appendices of ASCII files
- a loader and saver for a special .bse file type that can contain complete songs, synthesis networks and audio samples
- the necessary bits for generic object property exposure and state change notification
- the fundamental basics for multi-track block based time discrete signal processing
- a mixing engine for multiple instruments with various features, such as polyphony, interpolation, envelopes, fine tunes, etc... (somehow fundemental for a tracker ;)

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 ;)

BEAST/BSE is not meant to become an esound replacement, but certain BSE components could certainly be reused for a tentative replacement implementation.


What else are you working on? What projects/applications would you like to see emerge that nobody you find missing from GNOME/Gtk+?
[Tim Janik (timj@gtk.org)]

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.

[Owen Taylor (otaylor@redhat.com)]

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.



<  |  >

 

Related Links
  • Articles on General
  • Also by Ali Abdin
  • Contact author
  • The Fine Print: The following comments are owned by whoever posted them.
    ( Reply )

    Pango + win32 port
    by johnjones on Tuesday December 28, @05:46AM
    I am intrested in Tor Lillqvist's Win32 port of GTK+ has it been tested on win2000 ? I know that alot of work was done on NT and their was some problems with useing it for win9x (which where fixed as far as I can tell) I am intrested because if it works well and fits in with windows then I might have an arguement to make all dev work on GTK+ and stop useing MFC and then porting to Xwidgets also has anyone thought about a Mac OS 10 port ? Ive seen the shots of BeOS thanks to event loop ! pango sounds nice hope that the text model can be something good I have big problems with german text in X progs now cheers john ps oh and the IDE needs to be like delphi or VB sad but true
    [ Reply to this ]
    Python IDE & GtkClueHunter
    by Jaska Mäkynen on Tuesday December 28, @06:20AM
    I *really* hope the IDE would have an editor which used GtkClueHunter, so when one writes: os. and presses the 'hunt' button, it would pop out a list of os-module's available methods and attributes. And so on... -jim
    [ Reply to this ]
    The GTK Object system
    by Jonathan Bartlett on Tuesday December 28, @04:37PM
    I was wondering if there was any plan to move the GTK+ object system to GLIB. If it were moved there, many programs that don't want to be GUI-bound could make use of the type system, as well as its bindings to the many other languages. It seems silly to me to bind it so tightly with the windowing code. If you moved the base object classes (GTK_OBJECT GTK_ENUMERATION, etc.) to GLIB, you could then just extend them from GTK as you are currently doing. Very little code would have to be changed, but the advantages of having an nice C-language object system for CLI programs would be immense. That way, stuff like BSE wouldn't need to include it's own object system, just #include , making programs more interoperable. Am I missing some technical hurdle here? Jon
    [ Reply to this ]
    • Re: The GTK Object system
      by Iggy on Tuesday December 28, @05:57PM
      There's been a pretty heated discussion of this very point on the gtk-devel mailing list recently. Check the archives for more details. The general consensus is that GTK+/GLIB will have a more abstracted object system, like the one in BSE, in a future version, but whether or not it will be in 1.4 or 2.0 is still up for debate. I would suggest tralling through the gtk-devel mailing list archives for December/November for the current position. Iggy
      [ Reply to this ]
    Re: GNOME Developer's Interview Follow-up
    by Thomas MANGIN on Sunday January 02, @12:14PM
    Quoting Owen Taylor: 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. Where can we find more information about this project. It seems very interesting. Thank you Thomas
    [ Reply to this ]
    • Re: GNOME Developer's Interview Follow-up
      by Owen Taylor on Sunday January 02, @05:38PM
      At the current time, not much more information is available. The code is in GNOME CVS, along with some design docs.

      You can also browse these docs using LXR

      When (and if -- Eider is experimental) this project is more ready, we'll post about it on Gnotices.

      [ Reply to this ]

     
    The Fine Print: The following comments are owned by whoever posted them.
    ( Reply )

    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.
    [ home | post article | search | admin ]