praka123
left this forum longback
Reinventing GTK: envisioning the future of the toolkit
By Ryan Paul | Published: April 09, 2008 - 11:50PM CT
Planning the next generation of GTK
The developers of GTK are preparing for a major overhaul that aims to resolve many of the framework's most significant deficiencies and add next-generation features that will increase flexibility and simplify development. This effort is still in the earliest planning stage, but several intriguing proposals provide valuable insight into some of the changes envisioned by prominent developers.
GTK is an open-source widget toolkit for developing applications with graphical user interfaces. It is cross-platform compatible, distributed under the permissive LGPL license, and widely used on the Linux platform.
In addition to being used for popular cross-platform applications like GIMP, Abiword, and Pidgin, GTK also serves as the foundation of the GNOME desktop environment which comes with Ubuntu, Fedora, and numerous other Linux distributions. GTK is also increasingly being adopted in the mobile space, where it is used by Nokia's Internet Tablet operating system, OpenMoko, OLPC, and the Access Linux platform.
Imendio's vision
Kristian Rietveld of Imendio—a software company that does custom GTK development and is currently funding a native Mac OS X port of the toolkit—presented a proposal last month at the GTK HackFest in Berlin with a plan for moving forward and addressing many of the weaknesses that GTK developers have identified over the years. The proposal offers clear goals for a long-term roadmap and makes the case for breaking ABI compatibility. Topics discussed during the presentation were later clarified in a more detailed position document.
Imendio wants the next generation of GTK to enable development of better user interfaces with sophisticated visual effects, animations, physics, and stacking. Other desired improvements include stronger OS integration, improved back-end support, increased portability, easier custom widget creation, architecture that makes language bindings easier to maintain, and support for a data abstraction layer.
In order to reduce the maintenance burden placed on third-party developers, the GTK developers have adhered to a strict policy of ABI compatibility for the duration of the GTK 2 development cycle. This provides an extremely high level of backwards compatibility, but makes it difficult to undertake drastic rewrites or perform major architectural changes. This incremental approach to development has helped promote GTK adoption, but has also created what many developers believe is an evolutionary impasse.
Imendio's developers argue that the GTK 2 series is a dead end because of the ABI stability guarantees and they say that a clean break will likely be necessary to continue moving forward because the code base contains a lot of legacy cruft and refactoring poses too many obstacles. To facilitate the break without creating undue stress on third-party developers, they suggest performing scheduled API and ABI breaks at defined intervals (possibly every five years) and ensuring that multiple versions of the library can be installed in parallel. They also want clear policies for deprecating and removing legacy API.
The proposal has been well received by the GTK community and is gaining widespread support among GTK contributors outside of Imendio. Alberto Ruiz, an independent GTK developer who is contributing to the Windows and Mac OS X ports, attended the event and posted some posted some thoughts about Imendio's presentation in his blog.
"One of the issues discussed was to provide a predictable release that might break ABI and remove deprecated API," he wrote. "The intervals for this are not clear yet, but it sounds like a good idea to me. Being predictable will let ISVs anticipate this sort of issues, which is better than getting to the situation where Gtk+ cannot get any better. There wasn't any decisions taken whatsoever, but the general feeling of agreement is pretty promising."
Read Complete article here:
*arstechnica.com/articles/culture/reinventing-gtk.ars
By Ryan Paul | Published: April 09, 2008 - 11:50PM CT
Planning the next generation of GTK
The developers of GTK are preparing for a major overhaul that aims to resolve many of the framework's most significant deficiencies and add next-generation features that will increase flexibility and simplify development. This effort is still in the earliest planning stage, but several intriguing proposals provide valuable insight into some of the changes envisioned by prominent developers.
GTK is an open-source widget toolkit for developing applications with graphical user interfaces. It is cross-platform compatible, distributed under the permissive LGPL license, and widely used on the Linux platform.
In addition to being used for popular cross-platform applications like GIMP, Abiword, and Pidgin, GTK also serves as the foundation of the GNOME desktop environment which comes with Ubuntu, Fedora, and numerous other Linux distributions. GTK is also increasingly being adopted in the mobile space, where it is used by Nokia's Internet Tablet operating system, OpenMoko, OLPC, and the Access Linux platform.
Imendio's vision
Kristian Rietveld of Imendio—a software company that does custom GTK development and is currently funding a native Mac OS X port of the toolkit—presented a proposal last month at the GTK HackFest in Berlin with a plan for moving forward and addressing many of the weaknesses that GTK developers have identified over the years. The proposal offers clear goals for a long-term roadmap and makes the case for breaking ABI compatibility. Topics discussed during the presentation were later clarified in a more detailed position document.
Imendio wants the next generation of GTK to enable development of better user interfaces with sophisticated visual effects, animations, physics, and stacking. Other desired improvements include stronger OS integration, improved back-end support, increased portability, easier custom widget creation, architecture that makes language bindings easier to maintain, and support for a data abstraction layer.
In order to reduce the maintenance burden placed on third-party developers, the GTK developers have adhered to a strict policy of ABI compatibility for the duration of the GTK 2 development cycle. This provides an extremely high level of backwards compatibility, but makes it difficult to undertake drastic rewrites or perform major architectural changes. This incremental approach to development has helped promote GTK adoption, but has also created what many developers believe is an evolutionary impasse.
Imendio's developers argue that the GTK 2 series is a dead end because of the ABI stability guarantees and they say that a clean break will likely be necessary to continue moving forward because the code base contains a lot of legacy cruft and refactoring poses too many obstacles. To facilitate the break without creating undue stress on third-party developers, they suggest performing scheduled API and ABI breaks at defined intervals (possibly every five years) and ensuring that multiple versions of the library can be installed in parallel. They also want clear policies for deprecating and removing legacy API.
The proposal has been well received by the GTK community and is gaining widespread support among GTK contributors outside of Imendio. Alberto Ruiz, an independent GTK developer who is contributing to the Windows and Mac OS X ports, attended the event and posted some posted some thoughts about Imendio's presentation in his blog.
"One of the issues discussed was to provide a predictable release that might break ABI and remove deprecated API," he wrote. "The intervals for this are not clear yet, but it sounds like a good idea to me. Being predictable will let ISVs anticipate this sort of issues, which is better than getting to the situation where Gtk+ cannot get any better. There wasn't any decisions taken whatsoever, but the general feeling of agreement is pretty promising."
Read Complete article here:
*arstechnica.com/articles/culture/reinventing-gtk.ars
Last edited: