Hi guys, GTK2 will (*must*, actually) be ready for the next release, especially if someone helps me out a little bit. You all know (or can read back through the archives) what main sticking points are left. A GNOME2 port, well, I'll need to find more free time I suppose, esp. since I'm not very interested in doing this work.
Cuenca - merge in your Xft stuff with HEAD and commit. I or Hub will merge the GTK2 work with HEAD shortly afterwords. Dom On Sat, 2002-06-22 at 05:22, Tomas Frydrych wrote: > I wonder in light of Joaquin's work (see my posting to the "more Xft > stuff" thread), and would like feedback from the whole team, whether > we might not need to have two development branches; one a > continuation of the 1.x line; this would contain Martin's table code, > Joaquin's xft code, footnotes and endnotes code and similar, and > lead toward and intermediate 1.2 release. The second developement > branch would lead to 2.0 release eventually, and would contain the > Pango/gtk2 stuff. > > My main reason for this suggestion is that it will take a while before > we have a 2.0 release with the Pango stuff; things are moving along > slower than I have been hoping. However, much work has been > done already that could eventually be released in an intermediate > release, and it would be pitty to hold it back for many months just > because other changes are not yet finished. So, I think the best way > would be to brach present head into 1.x and 2.x development > branches. The present stable would be left as is at present for > bugfixes only, and after the 1.2 release would be replaced with > stable 1.2 branch. The 2.x-dev would be Pango-enabled and gtk2 > dependant, so we could remove the #ifdef WITH_PANGO defines as > soon as the Pango code provides basic functionality, while 1.x-dev > would be Pango-less, gtk1 based, so that all the existing Pango code > would be removed from it. > > If we agreed this was a good idea, the question remains which > should be the head (I would prefer the Pango/gtk2 branch, as it > would be heading toward the next major release), and what > procedure would be used to for maintaining the non-head dev > branch. The easiest would probably be that each developer would be > responsible to commit all changes to both branches when > applicable, although, we might want to have a formal maintainer, who > would be sent patches. > > I am eager to hear you thoughts guys. > > Tomas -- Dom Lachowicz <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
